[LSC] New surface meta command

[Steve Bliss]

Going way back...

Lars and Kevin wrote:
> >>   CLOTH  (or ...)
> >
> >I prefer that we actually create an LDraw primitive
> >for this.  In this way, all renderers, not just
> >POV-Ray, can benefit.
>
> Why shouldn't a renderer be able to support a TEXTURE meta command ?
> What makes a primitives better/easier to support ?
> Primitives are used to define the shape, not the appearance/look.
> Renderes can substitute primitives with more accurate shapes,
> e.g. more rounded.

I agree that implementing textures in primitives is not the way to go.  Most 
textures are going to be too fine to model LDraw.

> >>The specified parameter is in effect until another
> >>meta command appears,
> >>or until END or no parameter is specified.
> >
> >Can we have BEGIN/END pairs?
> >
> >0 TEXTURE BEGIN ROOF
> >0 TEXTURE END
>
> Well, I don't mind, it just seemed enough with
> 0 TEXTURE ROOF
> 0 TEXTURE END
> or
> 0 TEXTURE ROOF
> 0 TEXTURE

LDLite had the original bracketed meta-commands, and they were like:

0 TRANSFORM 10 0 0 0 10 0 0 0 20
<lines>
0 TRANSFORM END

and they seem to work quite well.  However, they are strictly paired.  This 
is legal:

0 TRANSFORM <params>
0 TRANSFORM <params>
0 TRANSFORM END
0 TRANSFORM END

This is not legal:

0 TRANSFORM <params>
0 TRANSFORM <params>
0 TRANSFORM END

I'm tempted by the shorthand of allowing a new texture to end an old 
texture, but I think we'd be better off to keep things 
rigid/formal/orthagonal and require each TEXTURE statement to have a 
matching TEXTURE END.  This also allows textures to be nested (if anyone can 
think of a use for that).

> >Is this new keyword concept really renderer independent?
>
> Yes, I think so.
> (and so does Tore: http://news.lugnet.com/cad/dat/parts/?n=2145)
> Renderers can choose whether they support the feature or not.

I agree.  And renderers can choose *how* they implement the feature.

> >>We should even have SHINY_RUBBER and MATTE_RUBBER.
> >
> >I wondered if you wanted to allow SHINY and MATTE as
> >separate adjectives that go with RUBBER (e.g. "SHINY
> >RUBBER" vs. "SHINY_RUBBER").  How would you render
> >SHINY_RUBBER differently than hard plastic?

I would say not.  The actual rendering of SHINY RUBBER might have nothing to 
do with the way SHINY PLASTIC is rendered.  So I don't think there's any 
real power to leverage in allowing separate adjectives.

Since it's been awhile since we discussed this, I'm going to restate the 
proposal, in my own words and with probably some of my own thoughts.  If 
this statement wraps badly, I'll repost it.

---------------------------------------------------------------------------
!TEXTURE meta-command

Description:
   A meta-command specifying that the renderer should apply a specific type
   of 'texture' to the commands between the initial !TEXTURE statement and
   the !TEXTURE END statement.

   The observance and implementation of the !TEXTURE meta-statement is
   at the discretion of the renderer.  Some renderers may ignore the
   statement, other renderers may implement some textures but not others.

Syntax:
   0 !TEXTURE <texture name>
   <ldraw commands>
   0 !TEXTURE END

Rules:
1. Every !TEXTURE command must be paired with a !TEXTURE END command.
2. Textures apply to subfiles referenced within the scope of the texture.
3. !TEXTURE statements may be nested.  The innermost texture overrides
   the outer texture(s).
4. A list of texture names will be determined as the 'standard' textures.
   Standard textures will be allowed in official part files.

!TEXTURE and !COLOUR:
The !COLOUR meta-statement allows the specification of a 'material' as
part of a color definition.  The material keywords (CHROME, PEARLESCENT,
RUBBER, MATTE_METALLIC, and METAL) will be considered synonyms for
textures.
---------------------------------------------------------------------------

A couple of points:

I think it might be a good idea to have an alternate form of !TEXTURE that 
is not limited (ie, has no !TEXTURE END).  This form of the statement would 
only appear in headers of (part) files and would apply to the entire file.

The last bit in the statement above, the part about !TEXTURE and !COLOUR, is 
written really poorly.  I'm open to suggestions for improvements.

Finally, do we need a statement for defining textures in ldconfig.ldr? 
Something like
0 !TEXTURE DEF <name> <custom definition params>
?

Steve