LDraw.org Discussion Forums
Extension for material properties? - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: General (https://forums.ldraw.org/forum-12.html)
+--- Forum: Official File Specifications/Standards (https://forums.ldraw.org/forum-32.html)
+--- Thread: Extension for material properties? (/thread-24221.html)

Pages: 1 2 3 4


RE: Extension for material properties? - N. W. Perry - 2020-10-24

(2020-10-05, 18:02)Roland Melkert Wrote: 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.)  Wink


RE: Extension for material properties? - N. W. Perry - 2022-04-04

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



RE: Extension for material properties? - Orion Pobursky - 2022-04-04

(2022-04-04, 19:55)N. W. Perry Wrote: (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.


RE: Extension for material properties? - N. W. Perry - 2022-04-04

(2022-04-04, 20:22)Orion Pobursky Wrote: 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.


RE: Extension for material properties? - Orion Pobursky - 2022-04-04

(2022-04-04, 21:00)N. W. Perry Wrote: 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.


RE: Extension for material properties? - N. W. Perry - 2022-04-04

(2022-04-04, 21:24)Orion Pobursky Wrote: 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?



RE: Extension for material properties? - Orion Pobursky - 2022-04-04

(2022-04-04, 21:40)N. W. Perry Wrote: [*]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

(2022-04-04, 21:40)N. W. Perry Wrote: [*]what parameters would the new META need to have?

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

(2022-04-04, 21:40)N. W. Perry Wrote: [*]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.


RE: Extension for material properties? - Max Murtazin - 2022-04-04

(2022-04-04, 21:24)Orion Pobursky Wrote: 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


RE: Extension for material properties? - Orion Pobursky - 2022-04-05

(2022-04-04, 23:37)Max Murtazin Wrote: 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".


RE: Extension for material properties? - N. W. Perry - 2022-04-05

(2022-04-04, 22:05)Orion Pobursky Wrote: 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.

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

Quote: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…