Extension for material properties?

[N. W. Perry]

I had this topic in mind, when I stumbled on this very old thread. With the vastly increased use of photo-realistic rendering since then, I'm wondering if the subject has been given any more thought?

In particular, I've found that there's a fair number of parts that are made of a softer plastic than the typical ABS brick, and/or have a rougher, matte finish (like the slope texture that kicked off that thread). While there are already color categories for rubber, various metals, etc., there seems to be a lack of options for describing different solid plastic properties within LDraw.

---

As a more general note, this seems like another in a family of physical part characteristics that I could envision being described by a series of metadata extensions, possibly as part of a hypothetical LDraw 2.0. Others in the family could include snapping/connectivity info, physical part dimensions (for accurately rendering seams, or calculating part collisions), and kinematic info (for describing technical functions like gear meshes).

[Gerald Lasser]

Yes, I agree, it is about time to pick this topic up again after 9 years.

Especially when I did now the Technic Panels of the Lamborghini I noticed this with the test renders again they are too shiny when rendered with Stud.io

concerning Studio, they do have a small shadow library, e.g. for some slopes, where they add the typical pattern. I think they take the LGEO data for that.

[Magnus Forsberg]

Yes, I agree, it is about time to pick this topic up again after 9 years.

But I think we all agreed on that no added info should be forced into the dat-files.
We don't want to recycle any file to add any metadata info.

[N. W. Perry]

But I think we all agreed on that no added info should be forced into the dat-files.
We don't want to recycle any file to add any metadata info.

Yeah. By "metadata" (and perhaps I'm misusing the term), I mean something separate and apart from the "data"—just as shadow libraries are now used. A user could add the info to any part, either in a joined file or by appending the .dat file itself, but no .dat would be made non-compliant by not having it.

[Willy Tschager]

But I think we all agreed on that no added info should be forced into the dat-files.
We don't want to recycle any file to add any metadata info.

We never agreed if information should be stored in a parallel library or just one file:

https://news.lugnet.com/cad/?n=11226

and we never will. I gave up on the topic and you should do the same.

w.

[Orion Pobursky]

We never agreed if information should be stored in a parallel library or just one file:

https://news.lugnet.com/cad/?n=11226

and we never will. I gave up on the topic and you should do the same.

w.

I really think we should pull in and officialize (or, at least, officially bless) all the common meta commands (snapping, flexible parts, and instructions) and Roland's shadow library.

[Gerald Lasser]

I actually like the proposal in the "very old" thread, i.e. having a material start meta and end meta.

I got now the Trolls container, which is opaque on the outside, i.e. slightly rough, but on the inside it is shiny ABS. That's not a simple material property that can be applied to the part in general.

Some materials are covered by assigning a special color, like Rubber or metal

[Roland Melkert]

I actually like the proposal in the "very old" thread, i.e. having a material start meta and end meta.

I got now the Trolls container, which is opaque on the outside, i.e. slightly rough, but on the inside it is shiny ABS. That's not a simple material property that can be applied to the part in general.

Some materials are covered by assigning a special color, like Rubber or metal

We already have a material start/end meta (sort of), it's called the texture extension.

It just needs some changes to make it work with in a different mode.

Maybe introduce a new meta name which is backwards compatible with the texture one. So parsers don't need to support jet another begin/end/next mechanism.  They would only need to disable part of it's parameter handling etc when the meta is called texture instead of e.g. 'material'

[Philippe Hurbain]

We already have a material start/end meta (sort of), it's called the texture extension.
It just needs some changes to make it work with in a different mode.
Maybe introduce a new meta name which is backwards compatible with the texture one. So parsers don't need to support jet another begin/end/next mechanism.  They would only need to disable part of it's parameter handling etc when the meta is called texture instead of e.g. 'material'

Then there is a need for some nesting, which is currently excluded from texmap specification: eg. we need to be able to apply texmap pattern on grainy slopes (BTW, what happens in various implementations if we try to apply texmap on something containing a subpart itself texmapped?)

Speaking of materials, we still don't have satisfying way to use texmap patterns containing metallic inks...

[Magnus Forsberg]

Some materials are covered by assigning a special color, like Rubber or metal

How many of these properties could be placed in ldconfig?
IMO we are missing colour codes and properties on textile materials.

[Philippe Hurbain]

How many of these properties could be placed in ldconfig?
IMO we are missing colour codes and properties on textile materials.

IMHO linking material (eg. rubber) to color was a kludge and it would be better to find another way...

[Orion Pobursky]

Speaking of materials, we still don't have satisfying way to use texmap patterns containing metallic inks...

Well actually we do: Gloss Map. But I don't know if any of the editors support it.

[N. W. Perry]

IMHO linking material (eg. rubber) to color was a kludge and it would be better to find another way...

Is there anything saying LDconfig is only for colors? Or could it contain one section for colors, and another for materials/finishes?

[Philippe Hurbain]

Is there anything saying LDconfig is only for colors? Or could it contain one section for colors, and another for materials/finishes?

Problem is not so much defining material than to use it. Basic LDraw syntax has a color property, but no material one...

[N. W. Perry]

Problem is not so much defining material than to use it. Basic LDraw syntax has a color property, but no material one...

I guess materials would be called by the syntax of the !MATERIAL (or !TEXTURE) meta.

Or maybe they could be called by the existing color property, using some kind of prefix system. E.g., color code 16 would be main color with no material specified, but 1600101 could be main color with a rubber finish, 1600201 would be main color in a slope texture, etc.  (Or use letters for material codes, or a character separator.)

[Roland Melkert]

Or maybe they could be called by the existing color property, using some kind of prefix system. E.g., color code 16 would be main color with no material specified, but 1600101 could be main color with a rubber finish, 1600201 would be main color in a slope texture, etc.  (Or use letters for material codes, or a character separator.)

I like this idea.

We could reuse one of the 'useless' color ranges (like the invisible ones).

[Lasse Deleuran]

I like this idea.

We could reuse one of the 'useless' color ranges (like the invisible ones).

I like this since it allows legacy software to be able to use a new ldconfig.ldr and default to still show colors correctly.

You and me might like this because it is neat because we see masks with the possibility of describing surfaces. However. I fear that we might make it too difficult for less technically inclined users.

For this reason I also want us to consider META statements, such as something like this impacting the next line:

0 !SURFACE [ROUGHNESS=0.8] [OTHER_FEATURE=VALUE] ...
1 2 0 0 0 1 0 0 0 1 0 0 0 1 subfile.dat

[N. W. Perry]

I like this since it allows legacy software to be able to use a new ldconfig.ldr and default to still show colors correctly.

You and me might like this because it is neat because we see masks with the possibility of describing surfaces. However. I fear that we might make it too difficult for less technically inclined users.

For this reason I also want us to consider META statements, such as something like this impacting the next line:

0 !SURFACE [ROUGHNESS=0.8] [OTHER_FEATURE=VALUE] ...
1 2 0 0 0 1 0 0 0 1 0 0 0 1 subfile.dat

My sense is that the technical difficulty of using a meta command vs. editing the config to include a new color/finish/material is approximately equal. So whatever solution gets the job done while meeting all the needs of an LDraw specification is probably best.

(And of course, the ldconfig is really just a bunch of meta commands anyway…)

[Travis Cobbs]

I like this idea.

We could reuse one of the 'useless' color ranges (like the invisible ones).

One problem with this is that the material is then tied to a specific color. So, you then need to have a separate entry for every combination of color and non-standard material.

[N. W. Perry]

One problem with this is that the material is then tied to a specific color. So, you then need to have a separate entry for every combination of color and non-standard material.

It should work the opposite way. If "1600101" refers to main color with a rubber finish, all you'd need to do is create the entry for rubber finish under 00101. The prefix would always be an existing color code, so the only entries you'd need to create are the materials.

[N. W. Perry]

I like this idea.

We could reuse one of the 'useless' color ranges (like the invisible ones).

What needs to happen next, if we want to go forward? (Just to keep the idea alive.) 

[N. W. Perry]

(Since the topic has come up once more…)

Question:
Would it make sense to use the existing MATERIAL tag, but:

1. detach it from the !COLOUR meta into its own !MATERIAL meta, and
   
2. use it to define additional material categories within ldconfig, separate from colors so that each individual combination needn't be defined explicitly?
   

[Orion Pobursky]

(Since the topic has come up once more…)

Question:
Would it make sense to use the existing MATERIAL tag, but:

1. detach it from the !COLOUR meta into its own !MATERIAL meta, and
   
2. use it to define additional material categories within ldconfig, separate from colors so that each individual combination needn't be defined explicitly?
   

The problem is that they are very much intertwined. Yellow rubber is not the same yellow as yellow plastic. I'm not convinced there is a good solution to this.

Surface finish, on the other hand, could be specified with some sort of material tag.

[N. W. Perry]

The problem is that they are very much intertwined. Yellow rubber is not the same yellow as yellow plastic. I'm not convinced there is a good solution to this.

Surface finish, on the other hand, could be specified with some sort of material tag.

Yellow slope surface is, however, the same yellow. And yellow rubber is already defined by the !COLOUR meta, so if that is indeed the necessary way to do it, then we can consider rubber to already be solved.

[Orion Pobursky]

Yellow slope surface is, however, the same yellow. And yellow rubber is already defined by the !COLOUR meta, so if that is indeed the necessary way to do it, then we can consider rubber to already be solved.

I was just using rubber as an example. Red cloth (which isn't defined) is also a different red from both red rubber and red plastic. My point is that material properties and color are (mostly) inseparable so the solution in place is fine.

As far as surface finish, the only real need for for slope bumps and I support a new META for that.

[N. W. Perry]

I was just using rubber as an example. Red cloth (which isn't defined) is also a different red from both red rubber and red plastic. My point is that material properties and color are (mostly) inseparable so the solution in place is fine.

As far as surface finish, the only real need for for slope bumps and I support a new META for that.

Well, even better, then—existing material tag for those cases which require it, and new META for those which require it. The concern was that the new proposal would create the intertwining of color and material—but if it exists already, then that is not a concern. And anything defined by the new META would not be intertwined. The only drawback is that it does not undo the intertwining (but would probably be capable of doing so, if it later became desirable).

Some next questions would be:

• what new materials/textures need to be defined this way (vs. by the original method)?
  
• what parameters would the new META need to have?
  
• how are new materials coded? is the numerical prefix system adequate?
  

[Orion Pobursky]

[*]what new materials/textures need to be defined this way (vs. by the original method)?

The only appropriate thing I can think of would be slope bumps

[*]what parameters would the new META need to have?

Keep it simple. Something like:
0 !SURFACE SLOPE|(Other surface finishes here)

[*]how are new materials coded? is the numerical prefix system adequate?

How those surfaces are rendered would be up to the author of the program that implements the META.

[Max Murtazin]

I was just using rubber as an example. Red cloth (which isn't defined) is also a different red from both red rubber and red plastic. My point is that material properties and color are (mostly) inseparable so the solution in place is fine.

As far as surface finish, the only real need for for slope bumps and I support a new META for that.

Doing that tho creates flood of same color in different finish. It creates at least solid, rubber, cloth, ink and soft finishes for the one Lego Color, multiplying possible count of colors by 5. I think that adding some sort of the META that defines the finish for those materials would make things easier for defining the standard. If also trying to keep backwards compatibility, extra RGB values can be defined through, for example, new config files specifically those finishes, and also leaving for software designers to also have procedurally-generated values for various finishes if there are no pre-defined ones

[Orion Pobursky]

Doing that tho creates flood of same color in different finish. It creates at least solid, rubber, cloth, ink and soft finishes for the one Lego Color, multiplying possible count of colors by 5. I think that adding some sort of the META that defines the finish for those materials would make things easier for defining the standard. If also trying to keep backwards compatibility, extra RGB values can be defined through, for example, new config files specifically those finishes, and also leaving for software designers to also have procedurally-generated values for various finishes if there are no pre-defined ones

This is exactly what I'm saying. The yellow RGB values for rubber, cloth, plastic, and string are different. So we'll have to define different colors for them anyway. In other words the way we do things now. This means that a material tag separate from color only make sense for different surface finishes for like materials. The only use case I can come up with off the top of my head is slope "roughness".

[N. W. Perry]

The only appropriate thing I can think of would be slope bumps

There are a couple of other plastic finishes, most notably the less glossy finish found on the softer plastics used for pointed parts. Maybe some other "frosted" surfaces, and I believe there are a few different grades of roughness for the slopes as well. These might well all fall under the same set of parameters as the slope surface.

Otherwise, printed/sticker/ink surfaces also tend to have a duller finish. But these also have their own peculiar colors, so maybe those are kept within the !COLOUR meta.

Keep it simple. Something like:
0 !SURFACE SLOPE|(Other surface finishes here)

I guess the specific parameters would be defined by the individual materials—in other words, just the same way as the MATERIAL tag is now.

How those surfaces are rendered would be up to the author of the program that implements the META.

By coding I meant the numerical code. In other words, if the code for the slope material is 00100, then a yellow slope would get color code 1400100. But maybe it should be 14-100, or 14.100, or not use numerals at all…

[Orion Pobursky]

By coding I meant the numerical code. In other words, if the code for the slope material is 00100, then a yellow slope would get color code 1400100. But maybe it should be 14-100, or 14.100, or not use numerals at all…

Oh. Ok. I meant something like:
0 !SURFACE SLOPE
<one or more type 1,3, or 4 lines>
0 !SURFACE END

[N. W. Perry]

Yes to both. If RGB values are indeed different for each material version of a color, then you will have the flood of combinations either way, because the existing color definition spec would be retained. The new material definitions wouldn't change that, but they wouldn't be the cause of it, either. And at least, they would provide the option to reduce the flood, if a way can be found to programmatically relate the difference in RGB between a base color and its material variant. This could be part of the supplied parameters to a material definition.