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.

[Trevor Sandy]

Beginning with LPub3D version 2.4.10, the fade previous steps and highlight current step colour ID 3-digit prefix will be user configurable.

Also, to circumvent the current conflict with 11019 for Trans_Tan, the default fade colour prefix will change to from 100 to 108 and the highlight prefix from 110 to 107.

Users will be able to set their desired prefix in the Globals Setup:



...or using the meta command

Code:

0 !LPUB FADE_STEPS COLOR_PREFIX 999

 
and 

Code:

0 !LPUB HIGHLIGHT_STEP COLOR_PREFIX 998

Cheers,

[Orion Pobursky]

I would just make the default 999 since we're unlikely to ever go that high, and now we know about it as well.

[Trevor Sandy]

Very well. I can also add that this configurable behaviour is passed to the LPub3D renderer distributions of LDView (-HighlightColorPrefix=999) and LDGLite (-laP999) when the highlight current step is enabled.

Cheers,

[Orion Pobursky]

Awesome. Thanks for the quick response.

[Hageta]

Does the new prefix work on the colours that are avoided by it?
For example 10046 (Metallic_Pink) -highlight-> 10710046
Just to be sure the new solution does not introduce a different bug.

[Trevor Sandy]

Does the new prefix work on the colours that are avoided by it?
For example 10046 (Metallic_Pink) -highlight-> 10710046
Just to be sure the new solution does not introduce a different bug.

If 10710046 is an existing colour ID, there is now the behavior allowing you to set your desired prefix from 107 to whatever you wish. 

The purpose of this behaviour change is to accommodate the situation where using a specified prefix (e.g. 110) and a pre-defined colour ID (e.g. 19) will result is a duplicate colour ID (e.g. 110 + 19 = 11019). In such scenario you can change the colour prefix so that a duplicate colour ID is avoided (e.g. 999 + 19 = 99919).

Cheers,

[Travis Cobbs]

Per the spec, CODE can be pretty much anything:

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.

The base LDraw file format requires colors to be numbers. So if some document somewhere says that CODE can be anything that's not a number, then I would strongly argue that that document is wrong. LDView definitely requires numbers (specifically integers), and furthermore only allows 32-bit numbers, not 64-bit ones.

Edit: it looks like LDView probably supports 64-bit color codes on 64-bit Linux and 64-bit macOS. However, due to MS being MS, it's limited to 32 bits on Windows. If anyone really wants it to support 64-bit color codes, I believe that updating it to do so would be fairly simple.

[Orion Pobursky]

So if some document somewhere says that CODE can be anything that's not a number, then I would strongly argue that that document is wrong.

While I don't disagree with you, I just pulled the text from the ratified spec here:
https://www.ldraw.org/article/299.html

The library 100% enforces a numeric code for all LDConfig definitions and that will never change. In fact, I highly doubt we'll ever define anything above 19999.  The 10000 colors were born of an offhand comment of mine as a convenience to avoid collisions. It turns out it's caused at least 2 problems so far. So, oops.

As far a going beyond 32 bit (2147483647) I can confidently say we never will.

[Hageta]

Wait a minute if alphanumeric colour codes are unsuported how are direct colours handled?

For example 0x2BA1CD3

[Hageta]

Wait a minute if alphanumeric colour codes are unsuported how are direct colours handled?

For example 0x2BA1CD3

In the preview and in the editor I see the code in the colour code has the colour I gave it, but it is not displayed in the thread.

[Hageta]

In the preview and in the editor I see the code in the colour code has the colour I gave it, but it is not displayed in the thread.

Here is what I see in the editor/preview:
   

[Sylvain Sauvage]

Wait a minute if alphanumeric colour codes are unsuported how are direct colours handled?

For example 0x2BA1CD3

0x2BA1CD3 is a number… the program that reads it just needs to be aware that the C hexadecimal notation (0x…) is acceptable.