LDraw.org Discussion Forums

Full Version: Updated LDConfig.ldr file
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Guys,

as a follow up to:

https://forums.ldraw.org/thread-23341.html
https://forums.ldraw.org/thread-22739.html

here is an update of the color file with a rearrangement of some RGBs, LEGO ID as well as new rubber colors in the 10000 range:

[attachment=3657]

Have a look and let me know.

w.
(2019-05-24, 10:34)Willy Tschager Wrote: [ -> ]Guys,

as a follow up to:

https://forums.ldraw.org/thread-23341.html
https://forums.ldraw.org/thread-22739.html

here is an update of the color file with a rearrangement of some RGBs, LEGO ID as well as new rubber colors in the 10000 range:

Have a look and let me know.

w.

Thanks. Some colors indeed look better!
Hi, thanks!
I have some questions:

(1)
why is now LDRAW color "0 !COLOUR Fabuland_Brown" associated with LEGO color "4 - Brick Red"? - this seems wrong to me
[Image: attachment.php?aid=3677]

(2)
Philo/Willy, can you give an example part where the new color "Fabuland_Orange" applies to?
I would like to update the required Fabuland figure assemblies accordingly using the new color

(3)
the CR/LF is missing in the last line of the ldconfig.ldr file posted here
here is a summary of the differences:

changed RGB codes for the following LDRAW colors:
- Tan (19)
- Magenta (26)
- Flesh (92)
- Earth_Orange (366)
- Fabuland_Brown (450)

newly added LDRAW colors:
- Coral (353)
- Light_Orange_Brown (507)
- Fabuland_Red (508)
- Fabuland_Orange (509)
- Rubber_Green (10002)
- Rubber_Magenta (10026)
- Rubber_Lavender (10031)
- Rubber_Reddish_Brown (10070)
- Rubber_Bright_Light_Yellow (10226)
- Rubber_Dark_Brown (10308)
- Rubber_Dark_Red (10320)
- Rubber_Dark_Azure (10321)
- Rubber_Medium_Azure (10322)
- Rubber_Light_Aqua (10323)
- Rubber_Dark_Orange (10484)

modified associated LEGO Color ID of
- Salmon (12)
- Fabuland_Brown (450) -----------> THIS IS PROBABLY AN ERROR, SEE SEPARTE POST
- Chrome_Gold (334)
- Chrome_Silver (383)
- Metallic_Silver (80)
- Metallic_Green (81)
- Metallic_Gold (82)
- Metallic_Dark_Grey (87)
This post on New Elementary was the reference when we reordered some of the values.

http://www.newelementary.com/2019/05/col...theme.html

I'll take a closer, and more focused, look at the difference at the end of this week. Don't have the time now...
(2019-05-27, 20:22)Magnus Forsberg Wrote: [ -> ]This post on New Elementary was the reference when we reordered some of the values.
http://www.newelementary.com/2019/05/col...theme.html
I'll take a closer, and more focused, look at the difference at the end of this week. Don't have the time now...
A color we are still missing from this chart is 14/Pastel Green (used in Fabuland crocodile, and also several Duplo parts such as a "famous" shower head). Bricklink mixes this colour with lime, though the colour itself is significantly less yellowish. If we don't create a new colour, I propose at least to change "// LEGOID 119 - Bright Yellowish Green" to "// LEGOID 119 / 14 - Bright Yellowish Green / Pastel Green". But the crocodile would clearly benefit from a better color hue...

[attachment=3678]
Scan of pastel green Duplo part next to lime tiles. Bottom lime is ldconfig lime color. Measured color: #ace35e
(2019-05-28, 6:45)Philippe Hurbain Wrote: [ -> ]But the crocodile would clearly benefit from a better color hue...

Scan of pastel green Duplo part next to lime tiles. Bottom lime is ldconfig lime color. Measured color: #ace35e

Yes, I agree, we should add Pastell Green to the chart. I don't like the yellowish croc....

@Steffen.
Any more comments on the change for Fabuland brown?

Could you create a list of all the shortcuts/files using code 366 and 450 ?
I want to understand how "big" this isuue is.
(2019-05-24, 10:34)Willy Tschager Wrote: [ -> ]Guys,

as a follow up to:

https://forums.ldraw.org/thread-23341.html
https://forums.ldraw.org/thread-22739.html

here is an update of the color file with a rearrangement of some RGBs, LEGO ID as well as new rubber colors in the 10000 range:

Have a look and let me know.

w.

I am not happy with color LDraw color 29 Bright Pink - LEGO color 222 Light Purple.
Medium Dark Pink comes visually closer to this IMHO.
Perhaps we can look into this by taking some measurements with a real brick?
(2019-05-28, 6:45)Philippe Hurbain Wrote: [ -> ]A color we are still missing from this chart is 14/Pastel Green (used in Fabuland crocodile, and also several Duplo parts such as a "famous" shower head). Bricklink mixes this colour with lime, though the colour itself is significantly less yellowish. If we don't create a new colour, I propose at least to change "// LEGOID 119 - Bright Yellowish Green" to "// LEGOID 119 / 14 - Bright Yellowish Green / Pastel Green". But the crocodile would clearly benefit from a better color hue...


Scan of pastel green Duplo part next to lime tiles. Bottom lime is ldconfig lime color. Measured color: #ace35e

So this would become?

0                              // LEGOID  14 - Pastel Green

0 !COLOUR Fabuland_Pastel_Green                                       CODE 510   VALUE #ACE35E   EDGE #333333

w.
Here's also the picture I took in Billund of all the rubber parts I got my hands on:

[attachment=3715]

Please compare with the 10000 range we added (not considering the shades of dark brown as they are to subtle).

w.
(2019-06-04, 13:15)Willy Tschager Wrote: [ -> ]So this would become?

0                              // LEGOID  14 - Pastel Green

0 !COLOUR Fabuland_Pastel_Green                                       CODE 510   VALUE #ACE35E   EDGE #333333

w.
Seems fine...
(2019-06-04, 13:26)Willy Tschager Wrote: [ -> ]Here's also the picture I took in Billund of all the rubber parts I got my hands on:
Please compare with the 10000 range we added (not considering the shades of dark brown as they are to subtle).
I tried to match every part with existing color. The only that doesn't match is this one, missing a medium lavender rubber color:
Here's the new file:

[attachment=3740]

Changes are:

Added Fabuland_Pastel_Green
Added Rubber_Medium_Lavender

Hopefully it comes with a working <CR>

w.
(2019-05-31, 20:02)Jaco van der Molen Wrote: [ -> ]I am not happy with color LDraw color 29 Bright Pink - LEGO color 222 Light Purple.
Medium Dark Pink comes visually closer to this IMHO.
Perhaps we can look into this by taking some measurements with a real brick?

This is not negotiable as it is tight to BL's color name. What I can do for you is using Ryan Howerter's RGB

w.
Do the new colors in the 10000 range work well with MLCad? It provides a big scrollable page with the colors for selection.
(2019-06-11, 13:55)Lasse Deleuran Wrote: [ -> ]Do the new colors in the 10000 range work well with MLCad? It provides a big scrollable page with the colors for selection.

You can manually type in the color if that’s what you’re asking.
(2019-06-11, 13:55)Lasse Deleuran Wrote: [ -> ]Do the new colors in the 10000 range work well with MLCad? It provides a big scrollable page with the colors for selection.
MLCad? what's that??? Big Grin

More seriously, no, it doesn't work with MLCad. Any color > 511 is supposed to be a custom color and appears grey.
LeoCAD and LDView work fine.

There is also a little issue with LDCad: on the color wheel, colors > 1023 are displayed in hex.
(2019-06-11, 15:01)Philippe Hurbain Wrote: [ -> ]MLCad? what's that??? Big Grin

More seriously, no, it doesn't work with MLCad. Any color > 511 is supposed to be a custom color and appears grey.
LeoCAD and LDView work fine.

There is also a little issue with LDCad: on the color wheel, colors > 1023 are displayed in hex.

I pulled 10000 out of thin air and Willy used it. We could just as easily use 900+
(2019-06-11, 15:12)Orion Pobursky Wrote: [ -> ]I pulled 10000 out of thin air and Willy used it.
...and it seemed fine to me too. But...

Quote:We could just as easily use 900+
Anything >511 causes problems with MLCad.
Now the question is: is this that important? these rubber colors are fairly uncommon, and we could easily decide that they are not supported in MLCad.
(2019-06-11, 15:33)Philippe Hurbain Wrote: [ -> ]Anything >511 causes problems with MLCad.
Now the question is: is this that important? these rubber colors are fairly uncommon, and we could easily decide that they are not supported in MLCad.

I think we should softly, but firmly, nudge the users into using modern software.
But, if there's a problem in LDCad, we should pick another number.
(2019-06-11, 15:33)Philippe Hurbain Wrote: [ -> ]...and it seemed fine to me too. But...

Anything >511 causes problems with MLCad.
Now the question is: is this that important? these rubber colors are fairly uncommon, and we could easily decide that they are not supported in MLCad.

Supporting MLCad quirks is not important to me personally. If Micheal wants his program to continue to be used (and endorsed by LDraw) then he needs to either update it or open source it.
(2019-06-11, 15:55)Magnus Forsberg Wrote: [ -> ]But, if there's a problem in LDCad, we should pick another number.
This is just a minor display problem, that occurs only in color wheel. Displayed color and generated LDraw code are correct, and you can key in decimal color code, so imho it's not really an issue (and it could probably be fixed in 1.6c)
(2019-06-11, 15:55)Magnus Forsberg Wrote: [ -> ]I think we should softly, but firmly, nudge the users into using modern software.

Totally agreed on this!
(2019-06-11, 15:01)Philippe Hurbain Wrote: [ -> ]There is also a little issue with LDCad: on the color wheel, colors > 1023 are displayed in hex.

I could change it to be >=0x02000000  (rgb coded colors)

Not sure why I chose 1024, maybe to be forwards compatible or something. Guess that backfired Smile
Sorry, but I disagree.

If there was some fact that forces us to break MLCad
then I would agree.

But here we could easily choose numbers that still work.

So we should choose them.

Is there any reason we cannot?
(2019-06-12, 22:35)Steffen Wrote: [ -> ]Sorry, but I disagree.

If there was some fact that forces us to break MLCad
then I would agree.

But here we could easily choose numbers that still work.

So we should choose them.

Is there any reason we cannot?

Aside from my feeling expressed in my other post, LEGO already has numbers in the 3-400s. Restricting to 512 increases the chance of overlap.
(2019-06-11, 13:55)Lasse Deleuran Wrote: [ -> ]Do the new colors in the 10000 range work well with MLCad? It provides a big scrollable page with the colors for selection.

LeoCAD also can't handle LDConfig 2019 colours with ID larger than CODE 512. UPD: Seems like LeoCAD could import new "LDConfig.ldr" placed in "Custom parts library" folder, where LDraw parts stored in un-zipped form.
[Image: yTqWAG0.png]

But LeoCAD CAN'T import "ldconfig.ldr" placed in same folder where ZIP of "Custom parts library" stored. [Image: FBPAhWN.png]

Hope, Leonardo Zide could fix it soon.
(2019-06-16, 12:04)Eugen Wrote: [ -> ]LeoCAD also can't handle LDConfig 2019 colours with ID larger than CODE 512. Hope, Leonardo Zide could fix it soon.
Mmhhh.... seems to work perfectly here (Windows version 17.07)
(2019-06-11, 15:01)Philippe Hurbain Wrote: [ -> ]LeoCAD and LDView work fine.

LeoCAD has some issue
(2019-06-16, 12:29)Philippe Hurbain Wrote: [ -> ]Mmhhh.... seems to work perfectly here (Windows version 17.07)

Well, could you describe how you add 2019 version of LDConfig.ldr to LeoCAD 17.07 on Windows?

Also, could you reproduce it with latest nightly build of LeoCAD? FTR, I tested it with LeoCAD nightly build under Linux — and it CAN'T import colors from 2019 version of LDConfig.ldr (I renamed it to ldconfig.ldr according LeoCAD behavior for import 3rd-party LDConfig files):
(2019-06-16, 13:28)Eugen Wrote: [ -> ]Well, could you describe how you add 2019 version of LDConfig.ldr to LeoCAD 17.07 on Windows?
I did nothing, just updated the ldconfig.ldr in my LDraw folder (I use a plain LDraw library, not the zipped one provided with LeoCAD (view -> preference -> custom library)).
Quote:Also, could you reproduce it with latest nightly build of LeoCAD?
No I can't install it. It uses a DLL missing from my ageing system (tried to install it in the past, but failed, known problem).
(2019-06-16, 13:54)Philippe Hurbain Wrote: [ -> ]No I can't install it. It uses a DLL missing from my ageing system (tried to install it in the past, but failed, known problem).

Could you link related issue? Or if this not reported yet, please, create one.
(2019-06-16, 14:28)Eugen Wrote: [ -> ]Could you link related issue? Or if this not reported yet, please, create one.
Well, technically it's not a problem with LeoCAD but with my system (I do have the same problem when I try to install other programs). The DLL is api-ms-win-crt-runtime-l1-1-0.dll
(2019-06-16, 14:33)Philippe Hurbain Wrote: [ -> ]Well, technically it's not a problem with LeoCAD but with my system (I do have the same problem when I try to install other programs). The DLL is api-ms-win-crt-runtime-l1-1-0.dll

That's a visual c runtime dll, the leocad installer should include the version that comes with the compiler used.
(2019-06-16, 18:56)Roland Melkert Wrote: [ -> ]That's a visual c runtime dll, the leocad installer should include the version that comes with the compiler used.

Thanks for details! I just reported it LeoCAD devs
(2019-06-16, 19:45)Eugen Wrote: [ -> ]Thanks for details! I just reported it LeoCAD devs
Thanks guys. Nonetheless, I should be able to install this DLL through Windows update, but I cant Sad
(2019-06-17, 5:26)Philippe Hurbain Wrote: [ -> ]Thanks guys. Nonetheless, I should be able to install this DLL through Windows update, but I cant Sad

You probably need to install the vs redistributable from https://support.microsoft.com/en-us/help...-downloads

I'll add the missing dlls to the installer.
(2019-06-17, 5:39)Leonardo Zide Wrote: [ -> ]You probably need to install the vs redistributable from https://support.microsoft.com/en-us/help...-downloads
Yes, that's the one that doesn't install (remains forever at "initialization" state) Sad Something broken here...
(2019-06-16, 13:54)Philippe Hurbain Wrote: [ -> ]I did nothing, just updated the ldconfig.ldr in my LDraw folder (I use a plain LDraw library, not the zipped one provided with LeoCAD (view -> preference -> custom library)).

Thanks for details! Just updated my comment above: Think, I found a way to reproduce issue with loading "ldconfig.ldr" placed in same folder where ZIP of "Custom parts library" stored. Here is issue report:
Hej guys,

did you see this?
https://www.newelementary.com/2019/05/co...theme.html

[attachment=3774]

It shows all Fabuland colors in 1 image.
Are all of them in our ldconfig.ldr correctly?
(2019-06-20, 2:00)Steffen Wrote: [ -> ]Hej guys,

did you see this?
https://www.newelementary.com/2019/05/co...theme.html

Sure here:

https://forums.ldraw.org/thread-23434-po...l#pid32160

w.
ah, good. I missed that somehow.
(2019-06-11, 13:20)Willy Tschager Wrote: [ -> ]Here's the new file:



Changes are:

Added Fabuland_Pastel_Green
Added Rubber_Medium_Lavender

Hopefully it comes with a working <CR>

w.

Two things:
  • As there are no request for further additions I'm gonna pack this version in the new AIOI
  • You won't believe it but I newer considered the line break at the end a major problem. What Is the simplest way to check if it is there or not - preferably in a WYSIWYG.
w.
(2019-07-01, 15:44)Willy Tschager Wrote: [ -> ]Two things:
  • As there are no request for further additions I'm gonna pack this version in the new AIOI
  • You won't believe it but I newer considered the line break at the end a major problem. What Is the simplest way to check if it is there or not - preferably in a WYSIWYG.
w.

I don't want you to hold back he AIOI, but there is an issue here, that we need to solve.

Ldraw dark flesh colours

I haven't had time to dig into it yet, but I agree with Vincent, some of the flesh colours are off .
(2019-06-13, 0:10)Orion Pobursky Wrote: [ -> ]Aside from my feeling expressed in my other post, LEGO already has numbers in the 3-400s. Restricting to 512 increases the chance of overlap.

well, then we still have numbers 401...512 for our purposes.
that should be plenty.
I still see no necessity to break MLCad when we can avoid that.
I just checked the currently official ldconfig.ldr, and there is plenty of free number space in it.
(2019-07-01, 21:28)Steffen Wrote: [ -> ]well, then we still have numbers 401...512 for our purposes.
that should be plenty.
I still see no necessity to break MLCad when we can avoid that.
I just checked the currently official ldconfig.ldr, and there is plenty of free number space in it.

I disagree. If Micheal wants to release a new version of MLCad or open source his program I'll reconsider. Until then, I'm not really interested in further official support/promotion of MLCad.
(2019-07-01, 15:44)Willy Tschager Wrote: [ -> ]Two things:
  • As there are no request for further additions I'm gonna pack this version in the new AIOI
  • You won't believe it but I newer considered the line break at the end a major problem. What Is the simplest way to check if it is there or not - preferably in a WYSIWYG.
w.

In most (all?) WYSIWYG text editors, if the very last line in the file is completely empty, it means that there is a line break at the end of the previous line. In other words, it allows the cursor to go down one line below the last line in the file.
Is there any way we could tag the MILKY colors? In the future they could benefit from sub-surface sampling.
we already have the following keywords in ldconfig.ldr:

MATERIAL SPECKLE
MATERIAL GLITTER
RUBBER
METAL
CHROME
PEARLESCENT

and for the glow in the dark
LUMINANCE

and additionally for GLITTER and SPECKLE colors the syntax elements
FRACTION
VFRACTION
SIZE
MINSIZE
MAXSIZE

so I see no reason why we should not add
MILKY

to this syntax. on the other hand: isn't MILKY just a partially transparent part,
i.e., wouldn't using ALPHA do what you want?
(2019-07-09, 6:40)Steffen Wrote: [ -> ]to this syntax. on the other hand: isn't MILKY just a partially transparent part,
i.e., wouldn't using ALPHA do what you want?

MILKY should be gradually transparent, no? I mean, thicker and harder to see through in the middle, but more transparent around the edges, like jade stone. That is what subsurface scattering is designed to mimic. And the normal transparent parts are *not* like this.
Pages: 1 2