Slope Meta Command

[Orion Pobursky]

I'd like to propose a META for slope texture. Something like:

0 !SLOPE_TEXTURE BEGIN
<faces that have slope texture>
0 !SLOPE TEXTURE END

or if there's only one line:

0 !SLOPE_TEXTURE
<face that has slope texture>

[Travis Cobbs]

Unless I'm having false memories, there are at least two different slope textures, and I think that should be accounted for. There is the standard rough slope texture and the less frequent not so rough (but not shiny) slope texture.

[Gerald Lasser]

I think there should be a BEGIN and END statement as there are pieces which have a print on those textured faces and those will consist of many triangles.

[Roland Melkert]

If this is about texture mapping why not just extend !TEXMAP ? Or I'm I missing something?

Code:

0 !TEXMAP <START | NEXT> SLOPE <parameters> <pngfile>
0 !TEXMAP FALLBACK
0 !TEXMAP END

[Travis Cobbs]

It's more about bump mapping than texture mapping. That doesn't necessarily mean that it shouldn't be added as an extension to !TEXMAP. Also, I don't think Orion expects there to be an image file; he just wants the textured (rough) parts of slopes to be called out as such in the LDraw library itself.

[Orion Pobursky]

Yup. This way parsers can insert the appropriate bumps during rendering or exporting to ray-tracers

[Gerald Lasser]

Do I understand you correctly that you just want to give one (or more in case of wedges) surfaces that need bumps.

Now if there is a pattern, it is then the task of the renderer to look for the right triangles and quads that are on that surface to apply the bumps to them.

Wouldn't it be easier if the renderer can rely on the part syntax that all surfaces that require bumps to be in the "SLOPE" bracket?

[Roland Melkert]

It's more about bump mapping than texture mapping. That doesn't necessarily mean that it shouldn't be added as an extension to !TEXMAP. Also, I don't think Orion expects there to be an image file; he just wants the textured (rough) parts of slopes to be called out as such in the LDraw library itself.

We could use some static indicaters instead of the png filename. a renderer will have to load an image at some point anyway, so why not let it use the same meta structures so it only has to substitute the static name for some local image.

We could allow it for all texture kinds (planar, cylindrical, sphere) and just distribute the default textures (using those static names) with the library.

edit: we would need to add the indication to use it as bump mapping somehow though.

[Michael Horvath]

POV-Ray can do normals/bumps without bitmap images.

Another option would be to create new line types for bumpy triangles and quads.

That would break a lot of software though.

[Orion Pobursky]

This over complicates things. I want a simple, clear way to distinguish the rough texture on the appropriate slope brick faces. I think a meta is the best way to go about this.

[Max Martin Richter]

I fully agree with Orion. A Meta('bracket') with some faces should work and it's quite simple.
We just need to distinguish between the surface types. For example:
Type1 -> Standard (smooth) -> no Meta is needed
Type2 -> Slope (low perforation) -> Meta 'SLOPE TEXTURE_LOW"
Type3 -> Slope (high perforation) -> Meta 'SLOPE TEXTURE_HIGH"

I'm sure there are better combinations to describe these things.

/Max

[Philippe Hurbain]

I too think the meta is the way to go. Could be useful too to define shinyness of a part, some of them are not shiny at all (I guess depending on plastic material), or only (similar to slopes) on a portion of the part. Examples of such parts: the Friends slide is shiny everywhere but on the inner of the ramp, the Technic flat panels are shiny inside ribs but not elsewhere.

[Roland Melkert]

If i understand correctly, we are talking material properties here. Which in modern rendering basically equals textures. So I'm still thinking this should be done by extending the texture meta.

Mainly for one reason, if you want to apply bump mapping on a single quad (which I suspect is what Orion initially wants) using a simple new meta is fine. But it's just a matter of time before you need it on some more complicated non smooth surface. In such a case you will need texture coordinates (normal mapping) so instead of adding a new meta for single triangle/quad bump mapping it would be far more efficient (also implementation wise) to use the existing texmap mechanics.

That said if you are only talking about non patterned surface changes (shininess etc) using the LDConfig color parameters could also be used by introducing new colors. Problem is you would need two different colors for simple sloped bricks etc.

So maybe we could use the LDraw state machine approach to define an alternative active finish, e.g.

0 !COLOUR_FINISH <color number>

On render start it's set to inherited (#16) and all is like it used to be. But whenever you need a supporting color you change it before the affected geometry and change it back to inherited afterwards.

So let's assume 1234 is a new color in LDConfig.ldr using the properties of a slope brick's rough surface using the fallowing:

0 !COLOUR_FINISH 1234
4 16 ..............
0 !COLOUR_FINISH 16

When the part is used with color 4 it will render everything like normal but the one line will be rendered using the RGB of color 4 but the finish of color 1234 giving you two current colors without having to make numerous static color part variants.

do note the the existing texture meta also in essence supplies you with a second current 'color'.

Alternatively we could also use this meta to define the shininess without referring to the normal colors but I'm not sure if that better/easier or not.

It could also be used with bumps but I'm not sure where the needed texture coordinates should come from in such a case, maybe some one more experienced with graphics could shine a light on that.

Hope this rambling is somewhat understandable.

[Ben Supnik]

Hi Y'all,

Sorry, I'm really late to the party here...(and I'll try to jump in on connectivity when I can), but I have a few strong opinions about this.

HIGH VS LOW LEVEL ABSTRACTION

First, we have to decide if this extension is meant to be a high level or low level abstraction.

Low level: Saying "the bump map comes from slopybumps.png" is a low level abstraction - the behavior is completely determined by the spec - a compliant renderer is going to go use a bump map. If the renderer substitutes something else for slopybumps.png, that's a hack, it's not going to be portable to all uses of the meta directive, and it risks being broken in the future. The flexibility is on the part developer's side.

High level: Saying "the surface properties of this face should be the rough texture of a real-world slope brick 45 2x2." The renderer has to cope with this somehow, perhaps using bump maps, perhaps using a BDRF, perhaps using povray directives. The flexibility is in the renderer; part creators get to pick this surface or not.

We have already gone with low level for part shape and texturing and this is clearly the sane decision. But I would argue that for material roughness, a high level approach is actually correct! Here's why.
- There are a lot of ways to render a material - and there is no one right way. I am -cringing- when I hear people go "bump maps"...bump maps are not a great fit for this problem. (We can have a separate discussion on that, but suffice it to say, not all rendering code developers are going to agree on how to show this rough surface.)
- There are not -that- many unique materials in the particular real world part set we are simulating. The fact that we don't have this feature at all right now is because most parts share the same uniform smooth glossy ABS plastic finish.

So to me this is a good candidate to simply enumerate the small number of real world material surfaces and let programs then implement this - whether it's by changing the OpenGL lighting parameters, providing custom BDRFs, using bump maps, or creating some kind of directives for Povray. The small axis here is the real world phenomenon, the wide axis is the client code.

ORTHOGONALITY

We have to decide which properties can be present on a surface -at the same time-. For example, if there are two types of bumpiness for slope bricks (I'm not enough of an expert, and my son's legos are in his room while he sleeps) then one quad or triangle can't be both of those bumpinesses at the same time. A face that has this bumpy slope surface also no longer has the "default" surface, which is an implicit surface that all parts have until tagged otherwise.

So I think we need to define the -scope- of the data we are adding - it has nothing to do with sloped bricks - it has to do with whatever it is we want to define. (I would call it "surface texture" - if texture wasn't such an overloaded word in computer graphics.)

I think we want to define a new meta that specifies a subsequent 'surface' and can either set it to one or more newly defined and enumerated surfaces, or set it back to the default, e.g. instead of

0 !SLOPE_TEXTURE BEGIN
<faces that have slope texture>
0 !SLOPE TEXTURE END

We'd have

0 !SURFACE BUMPY_SLOPE
<faces that have bumpy slope texture>
0 !SURFACE DEFAULT
<faces that have normal "glossy and smooth" texture>

This leaves the possibility of adding more mutually exclusive surface textures as we find a need for them.

CHILD RULES

Assuming that this meta directive affects sub-parts/sub-files (which pretty much all of the modern extensions do), I would like to see an extension where it is _not_ possible to _override_ the surface decision of a child part once it is made. This would be different from some of our other extensions, but this is a direction I'd like to consider for new extensions.

The problem with overriding is that it makes it impossible for a program that processes LDraw files to fully process a sub-part without knowing its -complete- inclusion in a super-part.

In a scheme where the child cannot be overruled (the child's rule is the final rule) a sub-part is in one of two categories:
- It contains _no_ surface information and surface information will come from the thing including it or
- It contains surface information and that is final.
This is a scheme where a sub-part can be fully optimized. For example, if a sub-part contains no surface changes within the part (and is thus completely uniform in surface) it can be optimized as such.

In a scheme where the child can be overruled, the sub-part has to be kept around in a representation equivalent to the LDraw file format itself, pre-transformation-for-rendering-tech, until the LDraw directives can be fully resolved using their complete inclusion and context. This means that part assembly from sub-parts (e.g. inserting 2304 studs into a 48x48 baseplate) has to be done in terms of LDraw file directives (creating a soup of who-knows-how many tris and lines) rather than working on the level of finished fully optimized sub-objects.

This restriction would limit what part authors can do - I think we need to think a bit about whether it's good practice or bad practice to author parts by overriding the surfaces of the sub-part. (My gut feeling is that if you have to override the surface, the library is "badly factored" and new primitives should be identified, but I don't make parts...others who actually are in the trenches should be trusted with this!)

cheers
Ben

[Roland Melkert]

Welcome back Ben,

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 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?

[Orion Pobursky]

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.

This is what I want to avoid since the bumpiness, roughness, etc. is independent of color. We'd have to define a new default color that had bumpiness, roughness, etc. That would break every current LDraw program. A !SURFACE meta would just be ignored by renderers that don't support it.

[Magnus Forsberg]

What will happen when the same pattern subfile is used in many different bricks?

Take the file s\2513p05s01 for instance.
It is used in Brick 3010p70 (without any textured/bumpy surface),
and in many different Slope Brick 2513(p02, p03, p14, p05) and 3037p05. Different slopes with (maybe) different textures.
Many of these bricks also use other pattern subfiles.

And what will happen if I place a Sticker on top of the textured surface?
Some of the textured surface is "hidden", and unnecessary to render in an image, below the flat surface of the sticker.

And sometimes the sticker is printed on transparent plastic sheet. How do you handle that?

[Roland Melkert]

That would break every current LDraw program.

I don't see how, as the state machine thing I'm talking about is the new meta. This meta instructs to apply only the surface specs of a LDraw color number to the followeling polygons untill something else is selected or a return to default is indicated. This is exactly the same as Ben's proposed !SURFACE meta. The only difference being instead of new ENUMS it will use data defined in the !COLOUR meta's of LDConfig.ldr.

[Roland Melkert]

What will happen when the same pattern subfile is used in many different bricks?

It would need to be split in a identical manner we now split for smart color 16 usage as you effectively have two working colors using this new approach.

And what will happen if I place a Sticker on top of the textured surface?

I think this depends on how it's modeled, if you model the sticker as a special standalone part variant you can (re)optimize the mesh if the sticker is put on top of the part while building the model it will just render on top of it like anything else. And you can also still use the texture extension for details etc.

Speaking of textures. The combination of changing surfaces, colors and textures will immensely complicate rendering implementations. This is the main reason I was hoping to make this new extension part of the existing texture mechanics in the first place.

[Ben Supnik]

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

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

[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.

[Ben Supnik]

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.

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.

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.

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