 | | | | | |
Hi gang,
playing around with colors I was floored by the fact that we do not have a LDraw
color number or RGBs for quite a lot of LEGO colors. In addition our RGBs
sometimes differ a lot from the official colors:
http://www.peeron.com/inv/colors
http://www.peeron.com/cgi-bin/invcgis/colorguide.cgi
I remember the time when we were graving for those figures and now that we have
them I simply ignore them. Can anyone put some light on this? LSC?
Thx, w.
| | | | | | | | | | | | | | | | |
| |
|
"Willy Tschager" <willy.tschager@tin.it> wrote in message
news:K6D96D.Ews@lugnet.com...
> Hi gang,
>
> playing around with colors I was floored by the fact that we do not have a
> LDraw
> color number or RGBs for quite a lot of LEGO colors. In addition our RGBs
> sometimes differ a lot from the official colors:
>
> http://www.peeron.com/inv/colors
> http://www.peeron.com/cgi-bin/invcgis/colorguide.cgi
>
> I remember the time when we were graving for those figures and now that we
> have
> them I simply ignore them. Can anyone put some light on this? LSC?
I don't know about the whole color thing but your post makes me think of an
interesting point. Just how exactly is LDRAW supposed to handle displaying
the Glitter Trans Clear color, and similar ones like it? I believe even
handling the Pearl color variations would be difficult, requiring a rewrite
of how LDRAW itself handles these colors, especially since it was never
intended to display complex color variations in the first place.
It was originally written when the basic colors were pretty basic, and
doesn't really have programming designed to access the screen resolutions it
would need to handle very hard to display colors.
If LDRAW has to handle the new color variations, this would mean a color
numeration enhancement to the basic LDRAW specification would have to be
drawn up.
I can see this would entail having to majorly reengineer the original LDRAW
program, which, I think from memory wasn't possible due to issues with the
distribution rights to the LDRAW source code and having to get permission
from James Jessiman's family to make needed changes.
One could, of course, make a whole new LDRAW-like main program, the issue
then would be that no money could be charged, since it might be seen as a
derivative works if it had to understand the original LDRAW specification.
However, if the LDRAW community is used to giving free stuff without charge,
then this might not be the obstacle it seems.
Cheers ...
Geoffrey Hyde
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Geoffrey Hyde wrote:
> I don't know about the whole color thing but your post makes me think of an
> interesting point. Just how exactly is LDRAW supposed to handle displaying
> the Glitter Trans Clear color, and similar ones like it? I believe even
> handling the Pearl color variations would be difficult, requiring a rewrite
> of how LDRAW itself handles these colors, especially since it was never
> intended to display complex color variations in the first place.
Take a look at the !COLOUR spec here:
http://www.ldraw.org/Article299.html
Pearlescent is covered, along with rubber, chrome, matte metallic, and metal.
Glitter transparency isn't, and probably should be. Of course, just because
official LDraw colors can be defined with these attributes doesn't mean that any
programs actually display them. LDView pays attention to rubber and maybe
chrome and metal. It ignores the other material definitions. (With chrome and
metal, I know that when I'm not parsing ldconfig.ldr, I have special behavior
for chrome silver, chrome gold, and metallic silver; I can't remember if I have
special behavior when I see those tags, though.)
--Travis
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
> In lugnet.cad.dev.org.ldraw, Geoffrey Hyde wrote:
>
> > I don't know about the whole color thing but your post makes me think of an
> > interesting point. Just how exactly is LDRAW supposed to handle displaying
> > the Glitter Trans Clear color, and similar ones like it? I believe even
> > handling the Pearl color variations would be difficult, requiring a rewrite
> > of how LDRAW itself handles these colors, especially since it was never
> > intended to display complex color variations in the first place.
>
> Take a look at the !COLOUR spec here:
>
> http://www.ldraw.org/Article299.html
>
> Pearlescent is covered, along with rubber, chrome, matte metallic, and metal.
> Glitter transparency isn't, and probably should be. Of course, just because
> official LDraw colors can be defined with these attributes doesn't mean that any
> programs actually display them. LDView pays attention to rubber and maybe
> chrome and metal. It ignores the other material definitions. (With chrome and
> metal, I know that when I'm not parsing ldconfig.ldr, I have special behavior
> for chrome silver, chrome gold, and metallic silver; I can't remember if I have
> special behavior when I see those tags, though.)
>
> --Travis
POVray can, of course, do all these colours and is likely to be the most
frequent user of the colour definitions file. Some of us have fiddled around
with pearl before (http://news.lugnet.com/cad/ray/?n=2551).
Tim
| | | | | | | | | | | | | | | | | | |
In lugnet.cad, Willy Tschager wrote:
> I remember the time when we were graving for those figures and now that we have
> them I simply ignore them. Can anyone put some light on this? LSC?
I'm pretty sure that the (2006-2007?) LSC agreed to leave the contents of
ldconfig.ldr up to the LDraw part admins. We saw it as our job to specify the
format of the !COLOUR meta-command, but not to have anything to do with the
actual list of colors.
--Travis
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
> In lugnet.cad, Willy Tschager wrote:
> > I remember the time when we were graving for those figures and now that we have
> > them I simply ignore them. Can anyone put some light on this? LSC?
>
> I'm pretty sure that the (2006-2007?) LSC agreed to leave the contents of
> ldconfig.ldr up to the LDraw part admins. We saw it as our job to specify the
> format of the !COLOUR meta-command, but not to have anything to do with the
> actual list of colors.
Hmm ... I found some sources how the colors are defined:
http://news.lugnet.com/cad/?n=11937
and it looks like LDraw colors http://www.ldraw.org/Article93.html still refer
to a color chart which was defined long before we got our hands on the official
LEGO colors at http://www.peeron.com/inv/colors and are the reason why our
values differ. Question is: Do we still define the colors the way we do because
of compatibility with LDraw 0.27?
Could Joshua's file http://news.lugnet.com/cad/?n=14408 hop in - taking for
granted that a year is enough time to write it ;-)
As for the PT admins maintaining the color list I guess right now they have
other things to do.
w.
| | | | | | | | | | | | | | | | | | | | | | |
(canceled)
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Joshua Delahunty wrote:
> In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> > In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
> > > In lugnet.cad, Willy Tschager wrote:
> > > > I remember the time when we were graving for those figures and now that we have
> > > > them I simply ignore them. Can anyone put some light on this? LSC?
> > >
> > > I'm pretty sure that the (2006-2007?) LSC agreed to leave the contents of
> > > ldconfig.ldr up to the LDraw part admins. We saw it as our job to specify the
> > > format of the !COLOUR meta-command, but not to have anything to do with the
> > > actual list of colors.
> >
> > Hmm ... I found some sources how the colors are defined:
> >
> > http://news.lugnet.com/cad/?n=11937
> >
> > and it looks like LDraw colors http://www.ldraw.org/Article93.html still refer
> > to a color chart which was defined long before we got our hands on the official
> > LEGO colors at http://www.peeron.com/inv/colors and are the reason why our
> > values differ. Question is: Do we still define the colors the way we do because
> > of compatibility with LDraw 0.27?
> >
> > Could Joshua's file http://news.lugnet.com/cad/?n=14408 hop in - taking for
> > granted that a year is enough time to write it ;-)
>
> I wrote it, finished it about a month ago.
>
> But I had a great deal of trouble trying to work in the official numbers into
> the LDRAW numbering system. Since there would be no consensus on how to add the
> "missing" color values (and that number of colors outnumbers what's currently
> included), I didn't want to try to open a can of worms by defining them myself.
>
> For the time being, I've used all the official numbers, plus 30000 (so 30001 is
> TLG white, 30002 is TLG grey, etc.) in the ldconfig.ldr that I use; plus I
> upgraded the RGB of the existing colors to use the TLG values.
>
> If anyone wants that file, I can put it up on the web for sharing.
>
> -- joshua
Hi Joshua,
please post. Could you be a bit more specific about the problems with the LDRAW
numbering system?
If guess the bit-mapping http://news.lugnet.com/cad/?n=11937 was a requirement
for backwards compatibility with LDraw which is obsolete now giving room to new
solutions. Read: www.ldraw.org/Article299.html
***************
CODE x - The LDraw color code. For LDraw compatibility, x is an integer 0-511.
If strict LDraw compatibility is not required, x is any identifier recognized by
a rendering program as a color code. Code is a required element.
***************
w.
| | | | | | | | | | | | | | | | | | | | | | |
(canceled)
| | | | | | | | | | | | | | | | | | | |
| |
|
This is an area that I took interest in several months back. Most of the Peeron
or Bricklink color values do not display well when they are rendered on the
screen. Most of the LDRAW colors are a different value, so that the rendered
color looks like the real color.
Is the rendering process altering the color value, or are the light sources
altering the rendered appearance of the color?
In either case, I think that LDRAW needs to somehow match the color properties
from those of Bricklink. The Bricklink database is almost always the first to
be updated with new parts / colors, and is usually very accurate.
This is an area that I still have interest in, and I would like to help in any
way. I have already written a program to convert a text based color file (like
the ldconfig.ldr) to the MLCAD.cfg binary format, so that I can test different
color values and edge values. I have also written a program to retrieve the
Bricklink color properties and save them in a formatted text file.
I'll probably think more about this latter on in the week, but please let me
know if there is anything that I can do to help.
Scott
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Scott Wardlaw wrote:
SNIP
> I have already written a program to convert a text based color file (like
> the ldconfig.ldr) to the MLCAD.cfg binary format, so that I can test different
> color values and edge values.
SNIP
Are you able to give that cool tool to the community. I thought about the color
handling in MLCad for a while and now I read this! Awaresome!
cu
mikeheide
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Sorry for the late response. I have placed the program and source code in a zip
file here:
http://www.scottwardlaw.com/lego/converter.zip
The colors.txt file contains an up to date list of all of the colors from
Peeron, Bricklink, and LDRAW. I think there are 119 total.
Some notes about the colors.txt file:
1) It is formatted in fixed column widths for human and computer readablity.
2) Ignore the last column. I had hoped to consolodate the color properties, but
some colors have multiple properties; ie (translucent and glow-in-the-dark)
3) The edge is a full color value, so that it can be any color and reduces the
dependency on the color code.
4) The color values are from mixed sources and are not what LDRAW should use.
The program was built to use these values as a starting point to getting
well-rendered color values.
5) The color codes are not all correct. I used the LDRAW color codes whenever
possible, but had to create my own codes for colors that LDRAW did not have.
6) The order these colors are in will be the order they are placed in MLCAD.cfg.
Some notes on the converter.exe:
1) It must be in the same folder as the colors.txt file
2) It will ask you the color code for the color that you are working on and will
place this color first in the MLCAD.cfg file for your convienence.
3) It will create the MLCAD.cfg file with the first 119 colors according to the
colors.txt file. Colors 128 to 247 are the edge colors from the colors.txt
file. The remaining colors are not used.
Lastly, if you change the order of colors or change color values, you will only
see that change in MLCAD. When you create a model, the model is only created
with color codes; not your color values. MLCAD writes the model with the color
code associated with the order of the colors. It does not keep record of the
color code read from the colors.txt file.
I would love to see all LDRAW programs use a new version of the LDconfig.ldr, so
that it would be the only location of color codes to color values.
Does anyone have a list of programs that do / do not use LDconfig.ldr?
I know that BrickStore and MLCAD use their own internal representation of this
file, but do not read LDconfig.ldr.
Thanks,
Scott
| | | | | | | | | | | | | | | | | |
In lugnet.cad, Willy Tschager wrote:
> Hi gang,
>
> playing around with colors I was floored by the fact that we do not have a LDraw
> color number or RGBs for quite a lot of LEGO colors. In addition our RGBs
> sometimes differ a lot from the official colors:
>
> http://www.peeron.com/inv/colors
> http://www.peeron.com/cgi-bin/invcgis/colorguide.cgi
>
> I remember the time when we were graving for those figures and now that we have
> them I simply ignore them. Can anyone put some light on this? LSC?
>
> Thx, w.
Joshua, Scott,
are there news on the new LDConfig.ldr? Sorry, I didn't have the time to keep
updated on the process. Did you syncronize your efforts? PLMK,
w.
| | | | | | | | | | | | | | | | |
> Joshua, Scott,
>
> are there news on the new LDConfig.ldr? Sorry, I didn't have the time to keep
> updated on the process. Did you syncronize your efforts? PLMK,
>
> w.
I have been waiting to hear from someone on this. The issues left to be worked
(as I remember them anyway):
1) compile all of the colors into one file (LDConfig.ldr)
2) work out the LDRAW color IDs as best as possible and get the steer co to
approve them?
3) either fix the color values, so that they render a color that is close to
real life, or find out why the real color values don't render the color
correctly
You are welcome to use my file (http://www.scottwardlaw.com/lego/converter.zip),
or start from scratch using Peeron, Bricklink, and the existing LDRAW colors.
Scott
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Scott Wardlaw wrote:
> > Joshua, Scott,
> >
> > are there news on the new LDConfig.ldr? Sorry, I didn't have the time to keep
> > updated on the process. Did you syncronize your efforts? PLMK,
> >
> > w.
>
> I have been waiting to hear from someone on this. The issues left to be worked
> (as I remember them anyway):
>
> 1) compile all of the colors into one file (LDConfig.ldr)
> 2) work out the LDRAW color IDs as best as possible and get the steer co to
> approve them?
> 3) either fix the color values, so that they render a color that is close to
> real life, or find out why the real color values don't render the color
> correctly
>
> You are welcome to use my file (http://www.scottwardlaw.com/lego/converter.zip),
> or start from scratch using Peeron, Bricklink, and the existing LDRAW colors.
>
> Scott
Why did you not use the values from LDConfig.ldr for the Edge Colors??
For example:
LDConfig.ldr
0 !COLOUR Black CODE 0 VALUE #212121 EDGE 8
This references to Color number 8 and that is
0 !COLOUR Dark_Gray CODE 8 VALUE #635F52 EDGE 0
But you use:
Name Code Value1 Alpha1 Value2
Alpha2 Edge Type
Black 0 212121 FF 212121 FF
6B5A5A Solid
But 6B5A5A is not the same as #635F52!
cu
mikeheide
| | | | | | | | | | | | | | | | |
> Why did you not use the values from LDConfig.ldr for the Edge Colors??
> For example:
> LDConfig.ldr
> 0 !COLOUR Black CODE 0 VALUE #212121 EDGE 8
> This references to Color number 8 and that is
> 0 !COLOUR Dark_Gray CODE 8 VALUE #635F52 EDGE 0
>
> But you use:
> Name Code Value1 Alpha1 Value2
> Alpha2 Edge Type
> Black 0 212121 FF 212121 FF
> 6B5A5A Solid
>
> But 6B5A5A is not the same as #635F52!
>
> cu
> mikeheide
Possibly because I wasn't paying close attention to the edge values at that
time. However, over the last two weeks, I have had a lot of time to look at
edge values. I was surprised to see how much of a difference that they make.
Please look for my next post with updated color and edge values, as well as an
explaination of what's going on.
Thanks,
Scott
| | | | | | |
