 | | Re: Why LDraw.org doesn't use ldconfig.ldr ???
|
|
(...) I'm pretty sure the ldconfig.ldr colors are designed to match the brick colors when no lighting is used (as in the second LDView picture above. If the ambient and diffuse terms add up to more than 1.0, the original colors end up getting washed (...) (17 years ago, 4-Oct-07, to lugnet.cad, FTX)
|
| |
| | Re: Why LDraw.org doesn't use ldconfig.ldr ???
|
|
(...) I'm open to improving the unofficial ldliterc.dat colors, but I don't expect we want to use all the default ldlite colors -- unless they were tuned away from the original LDraw (ie, 4-bit VGA) colors. The other issue is if we the built-in (...) (17 years ago, 4-Oct-07, to lugnet.cad, FTX)
|
| |
| | Re: Why LDraw.org doesn't use ldconfig.ldr ???
|
|
(...) The actual truth may be lost to the sands of time, but I believe the ldlite colors were possibly copied from the original LDRAW colors, and the ldlite Windows lighting code was matched to that? I know I did a good amount of twiddling in the (...) (17 years ago, 4-Oct-07, to lugnet.cad, FTX)
|
| |
| | Re: Why LDraw.org doesn't use ldconfig.ldr ???
|
|
(...) looked at the ldliterc.dat above, and color 7 has the same setting as what is in ldconfig.ldr. However, the actual color being rendered seems too light. For example, here is an image from the part tracker: (URL) Here is the same part rendered (...) (17 years ago, 4-Oct-07, to lugnet.cad, FTX)
|
| |
| | Re: Preparing a L(EGO)Draw part for the Parts Tracker – A review
|
|
Thanks, Willy, for this very informative article... I discovered many things (among them, Syncedit that looks VERY interesting - how did I miss its announcement???). (...) Here you had a favorable situation with mostly flat surfaces. Similarly I (...) (17 years ago, 4-Oct-07, to lugnet.cad.dat.parts)
|
