LDConfig.ldr problem with colour 11019 Trans_Tan?

[Jens Brühl]

I have a problem with LPub3D rendering LDView with Enable Highlight Steps.


Parts with tan colour now appear transparent instead of just highlighting the edge colour.
https://photos.app.goo.gl/JfhVyvE7CVQzUPqE7

The root cause seems to be in LDConfig.ldr with this change:

0 !LDRAW_ORG Configuration UPDATE 2025-09-18
0 // Last update: Added 11015 Trans_White and 11019 Trans_Tan


LPub3D uses the prefix 110 to show the highlighted parts with a defined edge colour:

# File: LEGOFadeStepColorParts.lst  Generated on: 11-07-2025 19:53:40

# This space-delimited list captures the LDraw static color parts (and their subfiles) to support
# step fade and step highlight. Parts on this list are identified in the LDraw library and copied to
# their respective custom directory. Copied files are modified as described in the following
# lines. If fade step is enabled, color codes are replaced with a custom code using the standard
# color code prefixed with [100].

# If using a single fade step color, color codes are replaced with main material color
# code 16 using the fade color set in Preferences. If part highlight is enabled, edge
# color values are replaced with the color value set in Preferences. If part highlight is
# enabled, color codes are replaced with a custom code using the standard color code
# prefixed with [110].

# When fade step is enabled, custom generated files are appended with '-fade',
# for example, ...\custom\parts\99499-fade.dat                 

# When highlight step is enabled, custom generated files are appended with '-highlight',
# for example, ...\custom\parts\99499-highlight.dat                 


So LDView now finds the new colour 11019 in LDConfig.ldr to be Trans_Tan, instead of the local definition of LPub3D in the temporary file 42143 - 1.1.1.1-highlight.ldr:

0 !COLOUR LPub3D_Orange CODE 11025 VALUE #D67923 EDGE #C000FF00 ALPHA 255
0 !COLOUR LPub3D_Dark_Azure CODE 110321 VALUE #469BC3 EDGE #C000FF00 ALPHA 255
0 !COLOUR LPub3D_Yellow CODE 11014 VALUE #FAC80A EDGE #C000FF00 ALPHA 255
0 !COLOUR LPub3D_Tan CODE 11019 VALUE #D7BA8C EDGE #C000FF00 ALPHA 255
0 !COLOUR LPub3D_Light_Bluish_Grey CODE 11071 VALUE #969696 EDGE #C000FF00 ALPHA 255
0 !SILHOUETTE 1 #C000FF00
1 11071 0 0 0 -1 0 0 0 -1 0 0 0 1 64179.dat
1 11019 0 0 50 0 0 1 0 1 0 -1 0 0 3749.dat
1 11014 0 0 40 1 0 0 0 1 0 0 0 1 69762.dat
1 11014 0 0 -40 1 0 0 0 -1 0 0 0 -1 69762.dat
1 11019 0 0 -70 0 0 -1 0 1 0 1 0 0 99008.dat
1 110321 0 0 -80 1 0 0 0 -1 0 0 0 -1 69779.dat
1 11014 0 0 0 0 0 -1 0 1 0 1 0 0 42143 - 1.1.1.1.1-highlight.ldr
1 11014 -40 0 0 1 0 0 0 1 0 0 0 1 4519.dat
1 11014 -70 0 0 0 0 1 0 1 0 -1 0 0 59443.dat
1 11014 40 0 0 -1 0 0 0 1 0 0 0 -1 4519.dat
1 11014 70 0 0 0 0 -1 0 1 0 1 0 0 59443.dat
1 11025 40 0 -60 0 0 -1 1 0 0 0 -1 0 65304.dat
1 11025 -40 0 -60 0 0 -1 1 0 0 0 -1 0 65304.dat
0 !SILHOUETTE

How to solve this conflict?
Why has the colour 11019 been included in LDConfig.ldr ?
If I remove it there, the problem is solved.

[Hageta]

Maybe the current funtcionality can be replaced with a metacommand or other colour code prefixes should be used.
I would suggest something like [hl-] and [fd-] as letters should not come into conflict with new colour codes. I am not sure if this can be done, as I do not know if LPub3D handles colour codes as a strings or numbers. Also is there other software, that depends on LPub3Ds output?

[Orion Pobursky]

I would expect the local definition to override the LDConfig definition.

That said, even if Travis fixes this, the 110 prefix will still cause problems if tan and trans tan appear in the same assembly.

Think this is an issue with both programs.

[Jens Brühl]

Why has the colour code 11019 for Trans_Tan been included in LDConfig.ldr?

I can't find this colour on rebrickable or bricklink.

[Magnus Forsberg]

Why has the colour code 11019 for Trans_Tan been included in LDConfig.ldr?

Some stickers are printed with a transparent white and tan colour.
https://library.ldraw.org/parts/25915

[Chris Böhnke]

The colour code 11019 (and 11015 for the Trans White) was picked to 1) clearly mark them as a specific use colour and 2) to avoid further overlap issues with other existing colour ranges (like 100xx for new colours with their official ID already blocked or 20xxx for Canvas).

Usage of specific prefixes in 3rd party programs is currently not covered in the spec.

Maybe a special range should be reserved for such programs?

Are there any other programs which use their own internal colour codes?

[Travis Cobbs]

I would expect the local definition to override the LDConfig definition.

That said, even if Travis fixes this, the 110 prefix will still cause problems if tan and trans tan appear in the same assembly.

Think this is an issue with both programs.

This seems to be an LPub3D problem, not an LDView problem. I'm guessing it was assumed that adding a 110 prefix to a standard color would never result in an overlap with some other standard color. Having said that, is there a reason that certain colors (like Trans_Black, Trans_White, and Trans_Tan) were given 5-digit color codes?

[Chris Böhnke]

This seems to be an LPub3D problem, not an LDView problem. I'm guessing it was assumed that adding a 110 prefix to a standard color would never result in an overlap with some other standard color. Having said that, is there a reason that certain colors (like Trans_Black, Trans_White, and Trans_Tan) were given 5-digit color codes?

The current standard is to assign newly released colours their official Lego ID.

In the past these numbers were for the most part unknown, so different numbers were picked (example: LDraw 19 Tan = Lego's 5 "Brick Yellow"). Unfortunately this caused many official IDs being occupied by the wrong colour in LDraw (some of the Fabuland colours might become a problem in the coming years, when Lego reaches the 500 range).

To avoid accumulation of these problems, it was decided, that all newly added colours for which an official ID is either unknown, already blocked or likely does not exist (rubber, canvas, thosetransparent sticker colours) gets a 5-digit ID.

Further for some ranges the idea was

variant_colour_ID = base_colour_ID + x

where x is a 5 digit number specific to that use, like 20000 for Canvas, 30000 for Modulex.

[Travis Cobbs]

The current standard is to assign newly released colours their official Lego ID.

OK, thanks. That all makes sense. Unfortunately, the 32-bit space allowed for color numbers doesn't really allow for a prefix that is big enough to avoid collisions with actual color numbers (especially when you take into account the various direct color ranges). LPub3D could probably update to use negative numbers. I think that LDView would allow that, although I'm not 100% sure.

[Orion Pobursky]

Per the spec, CODE can be pretty much anything:

x is any identifier recognized by a rendering program as a color code

By convention LDConfig uses numeric codes (and the library's parsing code enforces numeric only). Does LDView recognize non-numeric codes? If so, LPub3D is free to use an alpha-numeric code that doesn't clash with the LDConfig.