Value of colours in LDconfig.ldr

[Manfred Schaefer]

Hello,

I would like to know how the values for the colors were determined.
I have noticed differences between the values in the LDConfig.ldr file and the values on Ryan Howerter's page.

The value for black is different

Value for black: Ryan Howerter's $000000,     LDConfig $1B2A34

Also the values of the milky colors
  
                                                           LDConfig                      Ryan Howerter

Lego-ID       Lego name            LDraw ID     Value               LDraw ID        Value

50           Phosphorent White         294         $BDC6AD             50             $E5DFD3
294         Phosphorent Green        21           $E0FFB0               294           $D5DC8A
329         White Glow                     329         $F5F307                329           $F5F307

There are also discrepancies in the mapping of the LDraw ID to the Lego color numbers in both sources.


Regards

Manfred

[Willy Tschager]

Hello,

I would like to know how the values for the colors were determined.
I have noticed differences between the values in the LDConfig.ldr file and the values on Ryan Howerter's page.

The value for black is different

Value for black: Ryan Howerter's $000000,     LDConfig $1B2A34

Also the values of the milky colors
  
                                                           LDConfig                      Ryan Howerter

Lego-ID       Lego name            LDraw ID     Value               LDraw ID        Value

50           Phosphorent White         294         $BDC6AD             50             $E5DFD3
294         Phosphorent Green        21           $E0FFB0               294           $D5DC8A
329         White Glow                     329         $F5F307                329           $F5F307

There are also discrepancies in the mapping of the LDraw ID to the Lego color numbers in both sources.


Regards

Manfred

* RGBs are copied from the current only available official source: LDD
* Trans colors are optimized for rendering
* Numbering is not consistent due to the fact that LDraw assign color numbers long before LEGO started sharing their internal number (I think around 2003). So all LEGO numbers where a LDraw number was already in place had to me relocated. You'll surely have seen that we started using numbers in the 10000 range. This is due to unknown LEGO color numbers and avoiding that the same mishap happens again.

w.

[Eugen]

Also the values of the milky colors

Just discovered an issue with "Milky White (79)" colour — it looks more than a halftransparent (which also results in variuous glitches).

These appears on Part Tracker's generated previews (is it LDView-based?) and also the same is in LeoCAD.

Take a look on "t1212.dat" (and "t1213.dat") in "t1210.dat" and "t1210p01.dat" shortcuts previews:

• https://library.ldraw.org/tracker/31095
  
• https://library.ldraw.org/tracker/32111
  
  
    t1210p01.png (Size: 15.82 KB / Downloads: 78)
    t1210.png (Size: 15.62 KB / Downloads: 78)
  

So, it looks like a bug of "Milky White (79)" colour, which probably should not has such a high level of transparency, see photo of real bricks:

• https://www.flickr.com/photos/kamo05/17270646971/
  
• https://www.flickr.com/photos/[email protected]/
  
• https://www.flickr.com/photos/[email protected]/
  

Note: for the "t1210.dat"/"t1210p01.dat" shortcuts, part "t1212.dat" should be in "White (15)", and part "t1213.dat" in "Milky White (79)", according to how these parts appears in plastic:

• https://www.flickr.com/photos/hitmit/alb...4357364248
  

[Travis Cobbs]

Just discovered an issue with "Milky White (79)" colour — it looks more than a halftransparent (which also results in variuous glitches).

The problem isn't with the color, but a limitation in how LDView draws transparent geometry that affects all transparent colors, but is much more visible in ones that are mostly opaque like Milky White.

When LDView draws transparent geometry, it only works right if the triangles are drawn back to front. Unfortunately, "back to front" isn't a trivial thing to figure out with arbitrary triangles, and LDView's sorting algorithm often results in triangles being drawn in the wrong order. When this happens, it produces the bad result you see.

I don't see myself being able to fix this.

Side note: LDraw "transparency" is achieved via something called an alpha channel. The numeric value of this ranges from 0 to 255, where 0 is completely invisible, and 255 is completely opaque. However, "transparency" is generally considered to be the inverse of this. So, "high transparency" means something like glass, which would then have a very low alpha value. Colors like "Milky White" would be very "low transparency", but have a correspondingly high alpha value (240, as it happens).

[Travis Cobbs]

I don't see myself being able to fix this.

I could update LDView so that any alpha values over a certain threshold would be drawn as opaque. This would be trivial to do, and would probably improve the results. I'm not sure what the appropriate threshold would be, but it seems like 240 should count.

[Rene Rechthaler]

i have exact that motor (in blue) and i can confirm that all parts are milky...
the propeller just looks more transparent because its very thin.
the front is the same material, but due to the thickness it looks almost solid (but it isnt)
the problem in the digital world is that the thickness of a material doesnt count, just the number of surfaces.
a 1000 LDU wall has the same opacity as a 1 LDU thick wall...
but 1000 walls each 1LDU are much more opaque (at least in the preview, the final render may differ)
do you have some of the very old Lego roof bricks? they are somewhat translucent...
this part is the same, even the body and the rudder are opaque at thin areas.
(do we need some kind of red/blue/yellow milky colors?)

René

[Travis Cobbs]

i have exact that motor (in blue) and i can confirm that all parts are milky...
the propeller just looks more transparent because its very thin.
the front is the same material, but due to the thickness it looks almost solid (but it isnt)
the problem in the digital world is that the thickness of a material doesnt count, just the number of surfaces.
a 1000 LDU wall has the same opacity as a 1 LDU thick wall...
but 1000 walls each 1LDU are much more opaque (at least in the preview, the final render may differ)
do you have some of the very old Lego roof bricks? they are somewhat translucent...
this part is the same, even the body and the rudder are opaque at thin areas.
(do we need some kind of red/blue/yellow milky colors?)

René

While it is true that thickness isn't taken into account, this specific problem is due to the way that LDView renders transparent shapes, as I mention above, and has nothing to due with the lack of accounting for thickness.

[Eugen]

i have exact that motor (in blue) and i can confirm that all parts are milky...
the propeller just looks more transparent because its very thin.
the front is the same material, but due to the thickness it looks almost solid (but it isnt)

Its not the same, and I already described why. Look on proppeller hub (not blade) and nose stiffeners

Photos shows it more than words.

   

[Orion Pobursky]

Here's the problem I see right now: you're comparing 2 different parts in 2 different photos taken under very different lighting conditions. There are far too many variables to make a determination. 

Rene has this part so maybe he can post a better pic under a bit brighter light.

[Eugen]

you're comparing 2 different parts in 2 different photos taken under very different lighting conditions.

And in all of the light conditions both parts materials looks differently. There are much more photos of this engine and its always the same: propeller (even in its taller hub part) always is a half transparent white, where the nose (even in its thin stiffeners part) is always opeaque white.
So, I'm 99.9% sure that nose and propeller are made of different materials: one from Polypropylene, and another from Nylon.

• https://www.findtop.com/the-best-uv-resi...ene-nylon/
  

Anyway, talking about LDconfig.ldr and colours in LDraw: I just tried the same parts (see attached LDR file, bricks on plate are placed for reference).

Test MPD-file: 
  MabuchiS1-colour-test.ldr (Size: 485 bytes / Downloads: 4)


Issues:

In LeoCAD (same for LPub3D as well) there are next issues appearing (parts colours IDs in round brackets are assigned manually, parts colors IDs in angle brackets are hardcoded in shortcuts):

1. Shortcut parts has Black edges for all the parts linked — if assemble it manually from, edges for each part are shown correctly per each part colour;
   
2. In a shortcut with main colour assigned to any transparent colour there is "full transparent Propeller part" glitch (there no such for the "Front" aka nose part) — there is no such glitch in a shortcut with main colour assigned to opaque colour, and if assemble all the parts manually and set transparent colour for "" part
   
3. Pin part of the "Front" (nose) part is visible throw "Base" part if view it from the front — there is no such glitch if view from the rear/back.
   

(I will adress LeoCAD issues to its developer, but it would be good if the sample LDR file would be tested in other software, including in LDraw official software too)

   

In LDView (and probably the same for Parts Tracker's render, which based on headless LDview build) there is only "Issue 3" applicable

   

In LDCad there only one issue: shortcut has has extra transparency in Nose/Base connection zone

       

In Online LDraw Model Viewer:

• https://forums.ldraw.org/thread-24106-po...l#pid55331