Roland Melkert Wrote:The high level approach you describe is basically what I meant with the "0 !COLOUR_FINISH" stuff in my earlier post. The problem with this still remains the same though... We will be introducing a second color like parameter which only applies a subset of the normal LDraw color material (bumpiness etc can be defined using the !COLOUR meta) in a machine state way.
I'm a little bit confused here. Are you saying:
(a) things like the bumpiness of slope _can_ be defined using the existing !COLOUR meta or
(b) things like the bumpiness of slope _should_ be defined using the existing !COLOUR meta or
© we should extend the existing !COLOUR meta to include bumpiness or
(d) you'd rather have an independent new meta for bumpiness, but are concerned that we clarify how it interacts with the existing !COLOUR meta.
I'm definitely in bucket D - the bumpiness of slopes, I think, is a property of the mold, not the plastic they pour into it, so it's logical that colour finish be in a separate meta with separate machine state. I'd never seen this but...
https://www.bricklink.com/myImg/232636.jpg
a trans-yellow slope brick! Who knew? :-)
I'm okay with things like "metallic" and "rubber" staying on the colour definition because the colour of the part is fundamentally affected by the material - e.g. the black of a rubber wheel isn't the same black as the black of ABS plastic.
I think that keeping a "bumpiness/roughness/finish" meta fully separate from the existing colour state meets Orion's intended goals in getting better high level meta-data for renderers in place.
In terms of the state machine....
Quote:I'm not sure about the child limitations you are proposing though. imho it is basically implementation vs part design issue, how do part editors see this?
I see two basic options, regarding sub-parts:
- State machine approach - child parts inherit the "current" colour finish from parents, at least until they change it. In this approach, there probably needs to be a "reset" colour finish that puts us back to what the parent was using.
- Disallow nesting. This is what the texmap spec does - I just caught the language now. It's illegal to "re-tex-map" a texmapped sub-part. In this scheme, you could only (while a specialized colour finish is in effect) include a sub-part that has no colour finish.
My original proposal was to disallow nesting, a la textures. The state machine approach is more flexible, but it does have a cost: a fully loaded part file's rendering can change based on every meta command where nesting is allowed. That is, a renderer has to allow that a part may change its appearance now based on the current color or a BFC winding change. But a renderer doesn't have to handle the case of a _partly_ textured part getting turned into a _fully_ textured part just because someone wrapped it in a texmap directive. The part is either untextured (and may be fully textured later - it's raw material) or has texturing information (and is "done" - an outer texmap directive is illegal.
Honestly, it's TEXMAP that makes a mess of things - supporting nested color finish isn't that bad as long as we define a small number of enumerated finishes (as opposed to some crazy "colour finish description language" with a gajillion parameters :-).
cheers
Ben