Slope Meta Command

[Roland Melkert]

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.

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.

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.

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:

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.

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 :-).

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.