Updated LDConfig.ldr file


Updated LDConfig.ldr file
#1
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:


.ldr   LDConfig.ldr (Size: 30.94 KB / Downloads: 69)

Have a look and let me know.

w.
LEGO ergo sum
Reply
RE: Updated LDConfig.ldr file
#2
(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!
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Updated LDConfig.ldr file
#3
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


Attached Files Thumbnail(s)
   
Reply
RE: Updated LDConfig.ldr file
#4
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)
Reply
RE: Updated LDConfig.ldr file
#5
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...
Reply
Pastel Green
#6
(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...


.jpg   lime.jpg (Size: 34.47 KB / Downloads: 762)
Scan of pastel green Duplo part next to lime tiles. Bottom lime is ldconfig lime color. Measured color: #ace35e
Reply
RE: Pastel Green
#7
(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.
Reply
RE: Updated LDConfig.ldr file
#8
(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?
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Pastel Green
#9
(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.
LEGO ergo sum
Reply
RE: Updated LDConfig.ldr file
#10
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).

w.
LEGO ergo sum
Reply
RE: Pastel Green
#11
(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...
Reply
RE: Updated LDConfig.ldr file
#12
(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:


Attached Files Thumbnail(s)
   
Reply
RE: Updated LDConfig.ldr file
#13
Here's the new file:


.ldr   LDConfig.ldr (Size: 31.24 KB / Downloads: 14)

Changes are:

Added Fabuland_Pastel_Green
Added Rubber_Medium_Lavender

Hopefully it comes with a working <CR>

w.
LEGO ergo sum
Reply
RE: Updated LDConfig.ldr file
#14
(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.
LEGO ergo sum
Reply
RE: Updated LDConfig.ldr file
#15
Do the new colors in the 10000 range work well with MLCad? It provides a big scrollable page with the colors for selection.
Reply
RE: Updated LDConfig.ldr file
#16
(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.
Reply
RE: Updated LDConfig.ldr file
#17
(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.
Reply
RE: Updated LDConfig.ldr file
#18
(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+
Reply
RE: Updated LDConfig.ldr file
#19
(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.
Reply
RE: Updated LDConfig.ldr file
#20
(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.
Reply
RE: Updated LDConfig.ldr file
#21
(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.
Reply
RE: Updated LDConfig.ldr file
#22
(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)
Reply
RE: Updated LDConfig.ldr file
#23
(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!
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Updated LDConfig.ldr file
#24
(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
Reply
RE: Updated LDConfig.ldr file
#25
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?
Reply
RE: Updated LDConfig.ldr file
#26
(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.
Reply
RE: Updated LDConfig.ldr file
#27
(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.
Reply
RE: Updated LDConfig.ldr file
#28
(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)


Attached Files Thumbnail(s)
   
Reply
RE: Updated LDConfig.ldr file
#29
(2019-06-11, 15:01)Philippe Hurbain Wrote: LeoCAD and LDView work fine.

LeoCAD has some issue
Reply
RE: Updated LDConfig.ldr file
#30
(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):


Attached Files Thumbnail(s)
   
Reply
RE: Updated LDConfig.ldr file
#31
(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).
Reply
RE: Updated LDConfig.ldr file
#32
(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.
Reply
RE: Updated LDConfig.ldr file
#33
(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
Reply
RE: Updated LDConfig.ldr file
#34
(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.
Reply
RE: Updated LDConfig.ldr file
#35
(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
Reply
RE: Updated LDConfig.ldr file
#36
(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
Reply
RE: Updated LDConfig.ldr file
#37
(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.
Reply
RE: Updated LDConfig.ldr file
#38
(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...
Reply
RE: Updated LDConfig.ldr file
#39
(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:
Reply
all Fabuland colors in 1 image
#40
Hej guys,

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

   

It shows all Fabuland colors in 1 image.
Are all of them in our ldconfig.ldr correctly?
Reply
RE: all Fabuland colors in 1 image
#41
(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.
LEGO ergo sum
Reply
RE: all Fabuland colors in 1 image
#42
ah, good. I missed that somehow.
Reply
RE: Updated LDConfig.ldr file
#43
(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.
LEGO ergo sum
Reply
RE: Updated LDConfig.ldr file
#44
(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 .
Reply
RE: Updated LDConfig.ldr file
#45
(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.
Reply
RE: Updated LDConfig.ldr file
#46
(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.
Reply
RE: Updated LDConfig.ldr file
#47
(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.
Reply
RE: Updated LDConfig.ldr file
#48
Is there any way we could tag the MILKY colors? In the future they could benefit from sub-surface sampling.
Reply
RE: Updated LDConfig.ldr file
#49
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?
Reply
RE: Updated LDConfig.ldr file
#50
(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.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 2 Guest(s)