Roland Melkert Wrote:If we go the non TEXMAP route I would prefer 'd', but if we somehow merge it into the texmap spec I would go for a/b or a separeate surface definition meta, all this so the texmap meta can reference a surface finish to use instead of a png file.
But please note I wrote those ideas/suggestions while trying to convince people to extend the texmap meta / mechanics, If we decide to go the separate route I agree on using a simple enum approach instead.
Okay. I am definitely in favor of -not- using the texmap spec. The 3-d physical material and finish of a physical part is not something you can describe with texturing - there are lots of equally legitimate ways to represent the effect when doing 3-d graphics for which texturing isn't necessary.
Quote:Where did you read the nesting limitations for texmap? Because as far I know it isn't limited at all. Subparts can have textures of their own it will just override any inherited active one. It say so in the spec:
Quote:The texture will remain active when processing an included file unless overridden within that file.I implemented this in LDCad using a simple stack push/pop approach.
I read this:
Maybe I'm misinterpreting what they mean? I see the language about popping the state now, so ... I guess this means nesting is allowed -only- by sub-parts.
Anyway, for the sake of discussion, we can treat texmap as being nested via a stack. I think I am proposing that:
- Surface finish meta be a different state variable than texturing.
- Surface finish meta support push/pop semantics and be allowed to be in sub-parts.
So - same rules as texmap, but orthogonal to texmap, and not texture based.
Quote:This is why I wanted to prevent adding another on/off mechanism. But like I wrote if we go the separate state route, it is better to keep it simple like Orion indicated, I'm just a bit concerned about adding things which can also be done by extending existing things.
A valid concer - I would strenuously argue though that part finish cannot be done by texture mapping alone, and a high level enum is much more reasonable than a low level material property system.
cheers
Ben