Special:
|
[DAT] (requires LDraw-compatible viewer)
|
Subject:
|
Re: Crazy, OK Heretical Idea ...
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Sat, 10 May 2003 16:49:06 GMT
|
Viewed:
|
1012 times
|
| |
|
|
In lugnet.cad, Don Heyse wrote:
> 0 Put the standard materials in P\MATERIAL.DAT
> 0 MATERIAL DEFINE bumpy ......
> 0 MATERIAL DEFINE smooth ......
> 0 MATERIAL DEFINE rubber ......
> 0 MATERIAL DEFINE metal ......
> 0 MATERIAL DEFINE cloth ......
> 0 MATERIAL DEFINE pearlescent ......
> 0 MATERIAL DEFINE studLogoBumpMap ?????
> 0 MATERIAL DEFINE printed ?????
Yes, I think it would be good to not encode the materials in the
rendering programs. There are always going to be new materials, just
like LEGO keeps coming up with new colors.
> 1 0 0 0 0 1 0 0 0 1 0 0 0 1 material.dat
> 0 MATERIAL BEGIN bumpy
> 0
> 0 ordinary ldraw commands to draw a sloped face.
> 0
> 0 MATERIAL END bumpy
That would work for some things, like bumpy surfaces on slopes, or
rubber wheels. But for other things, like pearlescent materials, it
wouldn't really be practical.
The bumpy surface on a slope brick is always there -- it's an element of
the part (or part of the element, either way).[2] But I don't think we
want to support pearlescent finishes by defining a second copy of all
the parts, where each copied file starts with MATERIAL BEGIN
pearlescent, and ends with MATERIAL END. The same goes for
chrome-plated versions parts, such as we've seen in the Creator sets.
Pearlescent 'colors' *could* be handled in the model file, like:
0 MATERIAL BEGIN pearlescent
1 19 0 0 0 1 0 0 0 1 0 0 0 1 970c00.dat
0 MATERIAL END pearlescent
But this approach gives something of a disconnect between the part and
the matrial. I think users would tend to think of the pearlescence as
part of the 'color' attribute. So, in this case, I would think it would
be more natural to specify pearlescent as part of the 'color' code.
> Are printed textures a property of a MATERIAL, or should they be done
> with a separate but similar set of meta-commands?
If they're accomplished with the same code, they should probably use the
same meta-command.
One thing to keep in mind - bumpy slope surfaces could be considered an
optional feature of a renderer. Printed decorations have to be
supported by all renderers. So if we decide to enable a new way of
coding patterns, it should be something that is relatively
straightforward to implement.
> > > My question is really on the technical side: I'm somewhat aware of the
> > > technique of texture-mapping, but I don't know if that can be achieved
> > > in renderers like LDLite (without major changes to the rendering
> > > engine).
> >
> > This is a case by case issue, each program would need different changes to
> > support it.
>
> If we implement it via meta-command hints then they can add the support
> (or not) whenever they get around to it.
Right. But is it something that can be done in a
software-only-no-graphic-library program?
Steve
|
|
Message has 1 Reply:
 | | Re: Crazy, OK Heretical Idea ...
|
| (...) I see what you mean. We've actually started doing this for certain materials such as gold, silver, chrome, and rubber. Ldview and ldglite already tinker with the specular properties for some of these materials based on the predefined color (...) (22 years ago, 12-May-03, to lugnet.cad)
|
Message is in Reply To:
| | Re: Crazy, OK Heretical Idea ... [DAT]
|
| (...) I like this. It would allow you to define a bunch of materials up front and then apply them to some of the surfaces. Could we use this for printed textures as well, or would that be better with a different meta-command? How would you apply the (...) (22 years ago, 2-May-03, to lugnet.cad)
|
41 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
