 | | | | | |
This isn't a problem or anything, it just struck me as odd. I
was browsing through the peeron inventories of the new Designer
sets when I noticed that while the edge lines on most of the CAD
rendered part pictures were black, some were rendered with what
looked like the default ldraw or ldlite edge colors. What's up
with that? :)
| | | | | | | | | | | | | | |
In lugnet.admin.database, Don Heyse wrote:
> This isn't a problem or anything, it just struck me as odd. I
> was browsing through the peeron inventories of the new Designer
> sets when I noticed that while the edge lines on most of the CAD
> rendered part pictures were black, some were rendered with what
> looked like the default ldraw or ldlite edge colors. What's up
> with that? :)
Well, it's like this -- some of the images are generated with black
edges, and some of them are generated with colored edges. In most
cases, I made deliberate choices about the color combinations. For
example, the trans-colors mostly have colored edges, rather than black.
It's also possible that some images were rendered incorrectly.
Steve
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.database, Steve Bliss writes:
> In lugnet.admin.database, Don Heyse wrote:
>
> > This isn't a problem or anything, it just struck me as odd. I
> > was browsing through the peeron inventories of the new Designer
> > sets when I noticed that while the edge lines on most of the CAD
> > rendered part pictures were black, some were rendered with what
> > looked like the default ldraw or ldlite edge colors. What's up
> > with that? :)
>
> Well, it's like this -- some of the images are generated with black
> edges, and some of them are generated with colored edges. In most
> cases, I made deliberate choices about the color combinations. For
> example, the trans-colors mostly have colored edges, rather than black.
> It's also possible that some images were rendered incorrectly.
Whoa! Caught me off guard with an actual reply. So then this one
http://img.lugnet.com/ld/4/3794.gif
should probably have been done up with black edges like most of the
other non-transparent parts? For example:
http://img.lugnet.com/ld/4/3023.gif
Any chance this issue will be fixed up someday? It hurts my eyes.
;^)
Don
| | | | | | | | | | | | | | | | |
In lugnet.admin.database, Don Heyse wrote:
> Whoa! Caught me off guard with an actual reply.
Always gotta keep ya guessing. :)
> So then this one
>
> http://img.lugnet.com/ld/4/3794.gif
>
> should probably have been done up with black edges like most of the
> other non-transparent parts?
Yes.
> For example:
>
> http://img.lugnet.com/ld/4/3023.gif
>
> Any chance this issue will be fixed up someday?
Umm, probably? The current issue is the sheer size of all the image
files. Partsref isn't too bright -- it can't generate images on the fly
(although there have been discussions in that direction).
> It hurts my eyes.
I feel your pain. ;)
BTW, the *intended* colors are all at this page:
http://guide.lugnet.com/partsref/colors/
Steve
| | | | | | | | | | | | | | | | | |
| |
|
Hi Steve,
Are all of the color numbers on this page correct? I saw the image for Sand
Green (http://img.lugnet.com/ld/378/3001.gif ) and realized that I have been
using a custom color in one of my current cad projects. I changed the
needed parts from my color to 378, and got very strange results, so I
decided to do a quick test. Here are the images I came up with...
In MLcad: http://www.brickshelf.com/gallery/ClassicSmiley/Temp/greens_mlcad.jpg
Left to right - Green, Lime Green, Sand Green.
From POV-ray 3.1:
http://www.brickshelf.com/gallery/ClassicSmiley/Temp/greens_pov.jpg
Same order.
The brick that is supposed to be Sand Green doesn't seem to be anywhere
close to the color shown in the Partsref image listed above. I've also
posted my .ldr and .pov files. Post moderation they can be found at
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=43065.
If you have any suggestions on how to get Sand Green to render correctly,
I'd like to hear them.
Thanks.
-Joel
<snip>
>
> BTW, the *intended* colors are all at this page:
> http://guide.lugnet.com/partsref/colors/
>
> Steve
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Joel Hoornbeek wrote:
> Are all of the color numbers on this page correct?
Yes, basically. The LDraw color codes are generally assigned by finding
an existing, dithered, color that somewhat resembles the desired color.
For Partsref, I really wanted to get as close the actual LEGO colors as
possible.
The scripts that generate images for Partsref do some fairly specialized
processing. LDLite is used to generate all the images. Customized
color values are created with LDLite's COLOR meta-statement. At the
time I was developing Partsref, LDLite would allow redefinition of
colors only for codes in the range 0-255. So for the color codes above
256, the scripts actually use another color code in place of the
specified color. I believe LDLite has been updated to correct this
limitation.
> If you have any suggestions on how to get Sand Green to render correctly,
> I'd like to hear them.
At this time, there isn't a standard way to handle newer colors across
all programs. I believe LDLite, Ldglite, and L3P will all recognize
LDLite's COLOR metastatement; I'm sure MLCAD won't. I'm not sure which
programs will recognize MLCAD's custom colors. So your solution will
have to depend on which programs you want to use to render your models.
Steve
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Steve Bliss writes:
>
> At this time, there isn't a standard way to handle newer colors across
> all programs. I believe LDLite, Ldglite, and L3P will all recognize
> LDLite's COLOR metastatement; I'm sure MLCAD won't. I'm not sure which
> programs will recognize MLCAD's custom colors. So your solution will
> have to depend on which programs you want to use to render your models.
>
> Steve
I've been thinking about this a little bit, and I'd like to propose a solution.
I think that with the next parts update, we should include a "colors.lst"
file. The format could either be a modified version of the ldlite color
command [1] or a more detailed format, such as an xml doc, as was mentioned in
this thread: http://news.lugnet.com/cad/?n=9830. [2]
Obviously no program would support this yet, but at least by including the file
in the standard parts package, there would be a common list for users to
consult. And in future software versions, the file would be used instead of
colors being hard-coded. If someone didn't like the name for a color, or
thought that it was off by a shade, they could edit the file themselves. And
it would be easy to add new colors as they are created.
Andy
[1. I say a modified version, because I don't like including a second color for
dithering. IMO, the whole point of specifing the color would be to escape the
need for using dithered colors. I think that the simplest format would be:
0 COLOR <color-number> <color-name> <red> <green> <blue> [optional-alpha]
[<red2> <green2> <blue2> [optional-alpha2]]
So an example (incomplete) colors list might be:
0 COLOR 0 Black 51 51 51
0 COLOR 1 Blue 0 51 178
0 COLOR 2 Green 0 127 51
0 COLOR 3 Dark-cyan
0 COLOR 4 Red 204 0 0
0 COLOR 5 Magenta 255 51 153
0 COLOR 6 Brown 102 51 0
0 COLOR 7 Gray 153 153 153
0 COLOR 8 Dark-Grey 102 102 88
0 COLOR 9 Light blue 0 128 255
0 COLOR 10 Light-green 51 255 102
0 COLOR 11 Cyan
0 COLOR 12 Light-red 255 201 196
0 COLOR 13 Pink 255 176 204
0 COLOR 14 Yellow 255 229 0
0 COLOR 15 White 255 255 255
0 COLOR 17 Pastel-green 102 240 153
0 18 Light Yellow
0 19 Tan
0 COLOR 20 Light-purple 224 204 240
0 COLOR 21 Glow-in-the-dark 224 255 176
0 COLOR 22 Purple 153 51 153
0 COLOR 23 Purple-blue 76 0 204
0 25 Orange (see 462)
0 26 Dark Pink
0 COLOR 27 Light-yellowish-green 229 255 168
0 COLOR 28 Flesh 250 163 157
0 COLOR 32 Trans-black 102 102 102 230
0 COLOR 33 Trans-dark-blue 0 0 153 230
0 COLOR 34 Trans-green 0 80 24 230
0 35 Trans-Dark-Cyan
0 COLOR 36 Trans-red 204 0 0 230
0 37 Trans-Magenta
0 38 Trans-Brown
0 39 Trans-Gray
0 40 Trans-Dark-Gray
0 COLOR 41 Trans-light-blue 153 192 240 243
0 COLOR 42 Trans-green-yellow 204 255 0 230
0 43 Trans-cyan
0 44 Trans-light-red
0 45 Trans-pink
0 COLOR 46 Trans-yellow 240 196 0 230
0 COLOR 47 Trans-white 255 255 255 230
0 57 Trans-orange 255 102 0 205
0 COLOR 256 Black-Rubber
0 COLOR 320 Dark-Red
0 COLOR 334 Gold 240 176 51
0 COLOR 335 Sand-red 212 163 157
0 COLOR 373 Sand-violet 175 150 180
0 COLOR 378 Sand-green 159 204 180
0 COLOR 379 Sand-blue 159 178 191
0 COLOR 382 Tan 204 170 102
0 COLOR 383 Chrome-Silver 204 204 204
0 COLOR 418 Bright-Green 0 191 89
0 COLOR 431 Belville-Mint-green
0 COLOR 462 Orange
0 COLOR 494 Electrical-Contact-yellow 204 204 204
0 COLOR 495 Belville-Light-yellow 255 255 128
0 COLOR 503 Light-gray 230 227 218
0 Lime-green 173 221 80
]
[2. Personally, I think XML is the better way to go, because it would provide
more options for different materials, edge colors, and so on. But it would be
harder to agree on the actual format.]
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Andrew Westrate wrote:
> I think that with the next parts update, we should include a "colors.lst"
> file.
That's a great idea! I've got an ldliterc.dat I could easily add to the
update. I think you're on the right track, using a more generic name.
How about colors.ldr?
> The format could either be a modified version of the ldlite color
> command [1] or a more detailed format, such as an xml doc, as was mentioned in
> this thread: http://news.lugnet.com/cad/?n=9830. [2]
Or the format could be the current LDLite COLOR command, since it's
already out there, and supported by a number of programs.
> Obviously no program would support this yet, but at least by including the file
> in the standard parts package, there would be a common list for users to
> consult. And in future software versions, the file would be used instead of
> colors being hard-coded. If someone didn't like the name for a color, or
> thought that it was off by a shade, they could edit the file themselves. And
> it would be easy to add new colors as they are created.
Exactly.
> [1. I say a modified version, because I don't like including a second color for
> dithering. IMO, the whole point of specifing the color would be to escape the
> need for using dithered colors.
I agree that dithering probably isn't that important, but it's not
exactly a challenge to continue allowing it. Maybe someone likes the
subtle texture it provides?
> [2. Personally, I think XML is the better way to go, because it would provide
> more options for different materials, edge colors, and so on. But it would be
> harder to agree on the actual format.]
I'd rather stick with an LDraw-compatible format, for two reasons:
1. It can be treated as a simple include file when rendering models
2. It's simpler to parse without the use of an add-on library.
Steve
| | | | | | | | | | | | | | | | | | |
| |
|
[XPFUT lugnet.cad.dev.org.ldraw]
In lugnet.cad, Andrew Westrate wrote:
> I've been thinking about this a little bit, and I'd like to propose a
> solution. I think that with the next parts update, we should include
> a "colors.lst" file.
A little more has happened on this: I emailed the authors of most of the
LDraw-compatible software packages, and asked for buy-in on this idea.
Basically, my thought was that we needed to have agreement about the file name
and location, more than we needed to hash out the details about the contents.
Generally, the response was favorable, so I'm bringing discussion back here for
more ideas.
I developed the idea a little more, suggesting that we plan for a general
'configuration file' that might get used for other settings besides color
definitions. I don't know what those 'other settings' might be right now, but
it seems reasonable to allow for the possibility.
My suggestion for the file name is ldconfig.ldr. This seems to identify the
file adequately. I happened to have a fairly extensive colors file lying
around. I cleaned it up, and here it is. I'm planning to put in this file in
the 2003-02 parts update, in the ldraw/ directory.
Notice that this file won't actually work fully in any software, AFAIK. The
main problem is that it attempts to define color codes in the 'dithered color'
range, which LDLite doesn't support. But as I said previously, the content can
be hashed out over time. The important thing is to get a file out there into
the hands of people who can dissect it. :)
Comments? Suggestions? Criticisms?
Steve
======================================================================
0 LDraw.org Configuration File
0 Name: ldconfig.ldr
0 Author: LDraw.org
0 Unofficial Configuration File Version 0.01
0 COLOR 0 Black 8 33 33 33 255 33 33 33 255
0 COLOR 1 Blue 0 0 51 178 255 0 51 178 255
0 COLOR 2 Green 0 0 140 20 255 0 140 20 255
0 COLOR 3 Teal 0 0 153 159 255 0 153 159 255
0 COLOR 4 Red 0 196 0 38 255 196 0 38 255
0 COLOR 5 DkPink 0 223 102 149 255 223 102 149 255
0 COLOR 6 Brown 8 92 32 0 255 92 32 0 255
0 COLOR 7 Gray 0 193 194 193 255 193 194 193 255
0 COLOR 8 DkGray 0 99 95 82 255 99 95 82 255
0 COLOR 9 LtBlue 0 107 171 220 255 107 171 220 255
0 COLOR 10 LtGreen 0 107 238 144 255 107 238 144 255
0 COLOR 11 Turquoise 0 51 166 167 255 51 166 167 255
0 COLOR 12 LtRed 4 255 133 122 255 255 133 122 255
0 COLOR 13 Pink 0 249 164 198 255 249 164 198 255
0 COLOR 14 Yellow 0 255 220 0 255 255 220 0 255
0 COLOR 15 White 0 255 255 255 255 255 255 255 255
0 COLOR 17 MintGreen 0 186 255 206 255 186 255 206 255
0 COLOR 18 LtYellow 0 253 232 150 255 253 232 150 255
0 COLOR 19 Tan 6 232 207 161 255 232 207 161 255
0 COLOR 20 LtPurple 0 215 196 230 255 213 221 238 255
0 COLOR 21 GlowDark 0x47c07c0 224 255 176 255 224 255 176 196
0 COLOR 22 Purple 0 129 0 123 255 129 0 123 255
0 COLOR 23 Violet-Blue 0 71 50 176 255 71 50 176 255
0 COLOR 25 Orange 0x4000000 249 96 0 255 249 96 0 255
0 COLOR 26 Magenta 0x4000000 216 27 109 255 216 27 109 255
0 COLOR 27 YellowGreen 0 215 240 0 255 215 240 0 255
0 COLOR 28 DarkTan 6 197 151 80 255 197 151 80 255
0 COLOR 33 DkTranBlue 0x4026026 0 32 160 255 0 0 0 0
0 COLOR 34 TransGreen 0x4042042 6 100 50 255 0 0 0 0
0 COLOR 36 TransRed 0x4601601 196 0 38 255 0 0 0 0
0 COLOR 37 TransPurple 0 100 0 97 255 0 0 0 0
0 COLOR 40 TransGray 0 99 95 82 255 0 0 0 0
0 COLOR 41 LtTranBlue 0 174 239 236 255 0 0 0 0
0 COLOR 42 TrNeonGreen 0 192 255 0 255 0 0 0 0
0 COLOR 45 TransPink 0 223 102 149 255 0 0 0 0
0 COLOR 46 TransYellow 0 202 176 0 255 0 0 0 0
0 COLOR 47 Clear 0 255 255 255 255 0 0 0 0
0 COLOR 57 TransOrange 0 249 96 0 255 0 0 0 0
0 COLOR 272 DkBlue 0x4000000 0 29 104 255 0 29 104 255
0 COLOR 320 DkRed 0x4000000 120 0 28 255 120 0 28 255
0 COLOR 335 SandRed 0 191 135 130 255 191 135 130 255
0 COLOR 366 EarthOrange 0 209 131 4 255 209 131 4 255
0 COLOR 373 SandViolet 0 132 94 132 255 132 94 132 255
0 COLOR 378 SandGreen 0 160 188 172 255 160 188 172 255
0 COLOR 379 SandBlue 0 106 122 150 255 106 122 150 255
0 COLOR 462 LtOrange 0 254 159 6 255 254 159 6 255
0 COLOR 484 DkOrange 0 179 62 0 255 179 62 0 255
0 COLOR 503 LtGray 0 230 227 218 255 230 227 218 255
0
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Steve Bliss wrote:
> My suggestion for the file name is ldconfig.ldr. This seems to identify the
> file adequately. I happened to have a fairly extensive colors file lying
> around. I cleaned it up, and here it is. I'm planning to put in this file in
> the 2003-02 parts update, in the ldraw/ directory.
>
> Notice that this file won't actually work fully in any software, AFAIK. The
> main problem is that it attempts to define color codes in the 'dithered color'
> range, which LDLite doesn't support. But as I said previously, the content can
> be hashed out over time. The important thing is to get a file out there into
> the hands of people who can dissect it. :)
>
> Comments? Suggestions? Criticisms?
>
> Steve
hmm ... I suppose this will become a some sort of standard color chart for a
handful of progs? are we sure that the ldraw colors are the right ones (makein'
the devils advocate)? looking around I found at least three different values for
almost every color. (I've taken the ldraw-colors from the website
http://www.ldraw.org/reference/specs/colors.shtml, not counting in the might
updated chart you've posted). please notice that richard morton (brickdog) has
measured them with a pantone spectrometer http://news.lugnet.com/cad/?n=9631.
I also suggest to harmonize the naming with other lego-related sites like peeron
or bricklink.
example (color 32)
Ldraw: Trans Dark Gray
Peeron: Smoke
Bricklink: Trans Black
here is what I found:
Color0
Ldraw RGB 51 51 51 Black
PNLTC RGB 0 0 0 Black
Britdogmodels RGB 33 33 33 Black
Color1
Ldraw RGB 0 51 178 Blue
PNLTC RGB 0 105 179 Blue
Britdogmodels RGB 0 87 166 Blue
Color2
LDraw RGB 0 127 51 Green
PNLTC RGB 0 164 92 Green
Britdogmodels RGB 0 130 74 Green
Color3
Ldraw RGB 0 170 170 Dark Cyan/Teal) values taken from MLCad
PNLTC RGB 0 153 159 Teal
Britdogmodels RGB 0 138 128 Teal
Color4
LDraw RGB 204 0 0 Red
PNLTC RGB 223 0 50 Red
Britdogmodels RGB 189 56 38 Red
Color5
Ldraw RGB 255 51 153 Magenta) values taken from MLCad
PNLTC not defined
Britdogmodels not defined
Color6
Ldraw RGB 102 51 0 Brown
PNLTC RGB 91 41 33 Brown
Britdogmodels RGB 97 48 5 Brown
Color7
Ldraw RGB 153 153 153 Gray
PNLTC RGB 172 171 166 Gray
Britdogmodels RGB 163 161 153 Light Gray
Color8
Ldraw RGB 102 102 88 Dark Gray
PNLTC RGB 99 99 99 Dark Gray
Britdogmodels RGB 112 112 97 Light Gray
Color9
Ldraw RGB 0 128 255 Light Blue
PNLTC RGB 98 148 205 Light Blue
Britdogmodels RGB 120 150 207 Medium Blue
Color10
Ldraw RGB 51 255 102 Light Green
PNLTC not defined
Britdogmodels RGB 61 212 133 Light Green
Color12
Ldraw RGB 255 201 196 Light red
PNLTC not defined
Britdogmodels not defined
Color13
Ldraw RGB 255 176 204 Pink
PNLTC RGB 244 198 215 Pink
Britdogmodels RGB 171 176 199 Violet
Color14
Ldraw RGB 255 229 0 Yellow
PNLTC RGB 246 220 0 Yellow
Britdogmodels RGB 247 209 23 Yellow
Color15
Ldraw RGB 255 255 255 White
PNLTC RGB 255 255 255 White
Britdogmodels RGB 232 227 217 White
Color16
Color17
Ldraw RGB 102 240 153 pastel green
PNLTC RGB 106 192 147 Mint Green
Britdogmodels not defined
Color18
Ldraw RGB 255 255 128 Light Yellow (Belville) color number 495
PNLTC RGB 253 232 150 Pale Yellow
Britdogmodels RGB 247 214 125 Light Yellow
Color19
Ldraw RGB 204 170 102 Tan - color number 382
PNLTC RGB 232 207 161 Tan
Britdogmodels RGB 214 191 145 Tan
Color20
Ldraw RGB 224 204 240 Light Purple
PNLTC RGB 201 198 224 Light Purple
Britdogmodels not defined
Color21
Ldraw RGB 224 255 176 Glow in the dark
PNTLC not defined
Britdogmodels not defined
Color22
Ldraw RGB 153 51 153 Purple
PNLTC RGB 129 0 123 Purple (wine)
Britdogmodels RGB 110 18 115 Tan
Color23
Ldraw RGB 76 0 204 Purple-blue
PNLTC RGB 109 102 169 Blue Purple (Belville)
Britdogmodels not defined
Color24
Color25
LDraw RGB 255 102 0 Orange - color number 462 (values taken from MLCad)
PNLTC RGB 233 113 23 Orange
Britdogmodels RGB 242 125 0 Tan
Color26
LDraw RGB 255 51 153 Dark Pink
PNLTC RGB 211 94 153 Dark Pink
Britdogmodels RGB 209 97 156 Dark Pink
Color27
Ldraw RGB 173 221 80 Lime Green)PNLTC not defined
Britdogmodels RGB 158 171 5 Lime Green
Color28
Ldraw RGB 204 170 102 Tan - color number 382
PNLTC RGB 232 207 161 Tan
Britdogmodels RGB 214 191 145 Tan
Color29
Color30
Color31
Color32
Ldraw POV-Ray: <0.40, 0.40, 0.40, 0.90> Trans Dark Grey
PNLTC not defined
Britdogmodels not defined
Color33
Ldraw RGB 0 0 15 Trans Dark Blue
PNLTC not defined
Britdogmodels not defined
Color34
Ldraw RGB 0 80 24 Trans Green
PNLTC not defined
Britdogmodels not defined
Color35
Ldraw not defined
PNLTC not defined
Britdogmodels not defined
Color36
Ldraw RGB 204 0 0 Trans red
PNLTC not defined
Britdogmodels not defined
Color37
Ldraw not defined
PNLTC not defined
Britdogmodels not defined
Color38
Ldraw not defined
PNLTC not defined
Britdogmodels not defined
Color39
Ldraw not defined
PNLTC not defined
Britdogmodels not defined
Color40
Ldraw POV-Ray <0.40 0.40 0.40 0.90> Trans dark gray
PNLTC not defined
Britdogmodels not defined
Color41
Ldraw RGB 153 192 240 Trans light blue
PNLTC not defined
Britdogmodels not defined
Color42
Ldraw RGB 204 255 0 Trans green-yellow
PNLTC not defined
Britdogmodels not defined
Color43
LDraw not defined
PNLTC not defined
Britdogmodels not defined
Color44
Ldraw not defined
PNLTC not defined
Britdogmodels not defined
Color45
Color46
Ldraw RGB 240 196 0 Trans Yellow
PNLTC not defined
Britdogmodels not defined
Color47
Ldraw RGB 255 255 255 Transparent White
PNLTC not defined
Britdogmodels not defined
Color57
Ldraw RGB 255 102 0 Transparent Orange
PNLTC not defined
Britdogmodels not defined
Color256
LDraw not defined
PNLTC not defined
Britdogmodels not defined
Color320
Ldraw RGB Dark Red
PNLTC RGB 191 135 130 Sand Red
Britdogmodels not defined
Color334
Ldraw RGB 240 176 51 Gold
PNLTC not defined
Britdogmodels not defined
Color335
Ldraw RGB 212 163 157 Sand Red (dull red bruise dusty rose gray-red)
PNLTC RGB 191 135 130 Sand Red
Britdogmodels RGB 153 112 89 Sand Red
Color366
LDraw not defined
PNLTC not defined
Britdogmodels not defined
Color379
Ldraw RGB 159 204 180 Sand green
PNLTC RGB 160 188 172 Sand green
Britdogmodels RGB 112 130 112 Sand green
Color379
Ldraw RGB 159 178 191 Sand blue
PNLTC RGB 130 143 183 Sand blue
Britdogmodels RGB 92 120 143 Sand blue
Color383
Ldraw RGB 204 204 204 Chrome - color number 383
PNLTC not defined
Britdogmodels not defined
Color418
Ldraw RGB 0 191 89 Bright Green
PNLTC RGB 13 177 98 Bright Green
Britdogmodels not defined
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, willy tschager wrote:
> hmm ... I suppose this will become a some sort of standard color chart for a
> handful of progs?
Not exactly, although kind of. The idea is this might become several
things. Not in any particular order:
- This can lead to a standard color-definition (meta-)statement for
LDraw. Since LEGO seems to be releasing more and more colors, it seems
like a very good idea to give users the ability to use (and define) new
colors without downloading entirely new software.
- Users could change their color settings to meet their own needs. Some
people might want to make custom colors for their own use.
- Other settings could potentially be stored in the configuration file.
- Individual programs could provide support for other configuration
files, via command-line parameters or menu options.
> are we sure that the ldraw colors are the right ones (makein'
> the devils advocate)?
No, we aren't sure. These colors are basically what looks good (and
mostly accurate) to me, when rendering with a specific program with
specific settings.
But if we're distributing the color file in parts updates, it won't be
hard to publish corrections & additions to the color file.
> looking around I found at least three different values for
> almost every color. (I've taken the ldraw-colors from the website
> http://www.ldraw.org/reference/specs/colors.shtml, not counting in the might
> updated chart you've posted). please notice that richard morton (brickdog) has
> measured them with a pantone spectrometer http://news.lugnet.com/cad/?n=9631.
I appreciate the effort brickdog put into that. It is valuable
information, I looked at it when I was pulling the file together. But
some of the color values seem wrong. I'm not a color expert -- I might
be all wet (or have a whacked monitor--which actually seems likely).
> I also suggest to harmonize the naming with other lego-related sites like peeron
> or bricklink.
That's generally a good idea. I'd be happier if all sources used
totally rational standards for color naming. But I'm not sure a
'totally rational' standard would actually produce useful results. What
used to be 'light gray' is now 'medium gray', unless we're going to have
a color name like 'even lighter gray'.
Steve
| | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Steve Bliss wrote:
> [XPFUT lugnet.cad.dev.org.ldraw]
>
> In lugnet.cad, Andrew Westrate wrote:
> > I've been thinking about this a little bit, and I'd like to propose a
> > solution. I think that with the next parts update, we should include
> > a "colors.lst" file.
...
> My suggestion for the file name is ldconfig.ldr. This seems to identify the
> file adequately. I happened to have a fairly extensive colors file lying
> around. I cleaned it up, and here it is.
...
I'm working on a Track Designer-like program; I'll be presenting it at
BrickFest. My program, TrackDraw, can read and write LDraw files -- I've also
created a color definition file (in XML) that is very much like Steve's -- so
I've been thinking a lot about this problem, too.
My comments:
- While dithering is not hard to implement, it appears to serve no purpose here.
All of the colors are the same in the last two groupings for all values of RGB.
The ones that appear different (the 'trans' colors) could be the same with no
loss, since the alpha is specified as zero, so the RGB values are irrelevant.
There's a more important reason to lose dithering: it is a display artifact, and
cannot necessarily describe a color well. This is because the dithered colors
need to lie equi-distant from the color on vectors pointing in opposite
directions. Taking gamma into consideration, the distance is neither linear nor
uniform. LDraw did it because on CGA it had to. Keeping it because it isn't hard
to implement ignores how color works. It's easy for a program to construct the
dithered values from a single value; it isn't easy to do the reverse accurately.
- The numerical values are a mixture of hexadecimal and decimal. For the colors,
I'd prefer to see 0xARGB to decimal R,G,B,A. 0xARGB is a standard used by HTML,
CSS, SVG and many others. The file already requires reading hexadecimal 32 bit
values, and is no more difficult to read by humans than R,G,B,A (and I find it
easier to read).
- The names are not consistant. The same way that LDraw parts have complete,
formal names, the colors should too. These names should not have abbreviations
and should be quoted to allow for spaces. So instead of "DkBlue" the name should
be "Dark Blue", and so on. I could see having a short name form in addition to a
formal name, although regular parts don't have short forms.
If you reject this idea, please consider making the abbreviations consistant.
Note only one color uses "Tran" instead of "Trans"; only one color uses a dash
in the name, etc.
- I couldn't figure out what the fifth column is for (e.g. 0x4601601).
- The table only includes flat colors: even if the RGB values are unchanged, it
would be great to include chrome, silver, etc. for the applications that can
render reflectance. Similarly, GlowDark should have a luminosity value.
- The most complete color reference I know of his here:
http://www.bricklink.com/catalogColors.asp
It currently contains 79 colors, with a reasonable choice of names. It would be
great to standardize the names -- I'd like to see good rationale when a
different name choice is chosen. In particular, I think it is a stretch to call
the color only available as a 1x1 plate as "LtGray".
- Black is 33,33,33? Why not 0,0,0? If it needs to be less black for printing,
that should be a print-driver concern. Is there any evidence that Black is
really dark gray but not truely black? See:
http://www.peeron.com/inv/colors
- LtPurple is the only color I see that has slightly different values in the two
dither color columns. Is that deliberate? Why?
Cary
| | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Cary Clark wrote:
> - While dithering is not hard to implement, it appears to serve no purpose here.
> All of the colors are the same in the last two groupings for all values of RGB.
> The ones that appear different (the 'trans' colors) could be the same with no
> loss, since the alpha is specified as zero, so the RGB values are irrelevant.
> There's a more important reason to lose dithering: it is a display artifact, and
> cannot necessarily describe a color well. This is because the dithered colors
> need to lie equi-distant from the color on vectors pointing in opposite
> directions. Taking gamma into consideration, the distance is neither linear nor
> uniform. LDraw did it because on CGA it had to. Keeping it because it isn't hard
> to implement ignores how color works. It's easy for a program to construct the
> dithered values from a single value; it isn't easy to do the reverse accurately.
As you pointed out, dithering is a historical artifact with LDraw. As I
don't see it doing any harm, I'd rather leave it in for now, even if it
is generally unused. Call me misguidedly sentimental. ;)
> - The numerical values are a mixture of hexadecimal and decimal. For the colors,
> I'd prefer to see 0xARGB to decimal R,G,B,A. 0xARGB is a standard used by HTML,
> CSS, SVG and many others. The file already requires reading hexadecimal 32 bit
> values, and is no more difficult to read by humans than R,G,B,A (and I find it
> easier to read).
As to the order and format, I was sticking with the LDLite definition of
the statement. I think you are correct about 0xARGB.
As for the decimal, I was being pragmatic -- by skipping the required 0x
prefix for the 8 RGBA parameters, each line ended up being slightly
shorter.
> - The names are not consistant. The same way that LDraw parts have complete,
> formal names, the colors should too. These names should not have abbreviations
> and should be quoted to allow for spaces. So instead of "DkBlue" the name should
> be "Dark Blue", and so on. I could see having a short name form in addition to a
> formal name, although regular parts don't have short forms.
Formal (or 'official') would be good, I think -- whether the names are
short or long. Long names are good, as long as they serve a purpose.
If we think programs will use the information from these color
definitions to display information for users (like on a color dialog),
then I'm all for long names.
Otherwise, considering that LDLite allows these color names to be used
in place of color codes, I don't think allowing spaces is going to be
likely.
> If you reject this idea, please consider making the abbreviations consistant.
> Note only one color uses "Tran" instead of "Trans"; only one color uses a dash
> in the name, etc.
Good points.
> - I couldn't figure out what the fifth column is for (e.g. 0x4601601).
The fifth column is the edge color. The hex values are LDLite direct
colors. LDLite direct colors use a 12-bit RGB color space; the leading
hex digit in the value specifies something (solid/trans?), the trailing
6 hex digits are two pairs of RGB values. I don't really expect LDLite
direct colors to survive as an official standard -- what's the benefit
over straight (A)RGB?
> - The table only includes flat colors: even if the RGB values are unchanged, it
> would be great to include chrome, silver, etc. for the applications that can
> render reflectance. Similarly, GlowDark should have a luminosity value.
(Sorry, I accidently left ShinySilver and ShinyGold out of the file)
Good points.
Unfortunately, including chromes could possibly confuse/frustrate
people, since they wouldn't actually 'work' in most LDraw-compatible
programs. But the advantage you describe may outweigh the drawback.
> - Black is 33,33,33? Why not 0,0,0? If it needs to be less black for printing,
> that should be a print-driver concern.
(Where is the print going to get its colors from?)
> - LtPurple is the only color I see that has slightly different values in the two
> dither color columns. Is that deliberate? Why?
Sorry, that was an error.
Steve
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Cary Clark wrote:
<snip>
> - Black is 33,33,33? Why not 0,0,0? If it needs to be less black for printing,
> that should be a print-driver concern. Is there any evidence that Black is
> really dark gray but not truely black? See:
> http://www.peeron.com/inv/colors
It's 33,33,33 since these values make the color light enough to show up on a
black backgrond when rendered but dark enough to be considered black.
-Orion
| | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Steve Bliss wrote:
> My suggestion for the file name is ldconfig.ldr. This seems to identify the
> file adequately. I happened to have a fairly extensive colors file lying
> around. I cleaned it up, and here it is. I'm planning to put in this file in
> the 2003-02 parts update, in the ldraw/ directory.
>
> Notice that this file won't actually work fully in any software, AFAIK. The
> main problem is that it attempts to define color codes in the 'dithered color'
> range, which LDLite doesn't support. But as I said previously, the content can
> be hashed out over time. The important thing is to get a file out there into
> the hands of people who can dissect it. :)
>
> Comments? Suggestions? Criticisms?
Since no software can handle the file right now, I suggest the format is changed into:
0 COLORDEF color name edgecolor r g b dr dg db material
COLORDEF in stead of COLOR to avoid confusion with ldlite COLOR.
For edgecolor you can also use extended colors 0x02RRGGBB,
which is supported by MLCad/LDView/L3P/L3Lab,
see http://www.hassings.dk/l3/l3p.html#extcol
"a" is left out (since it is always 255 ?)
"da" is left out, use material=transparent.
You can specify "dr dg db" as "-1 -1 -1", which means no dithering.
It is easier than replicating the "r g b" values, and is less error prone.
"material" added, can be normal/transparent/rubber/metallic/glowing
The rubber is a convenient shortcut, as a "0 MATERIAL RUBBER"
in the tire files would be preferred.
Then you could easily have a (virtual) green rubber tire.
Example:
0 // Code ColorName EdgeColor R G B DR DG DB Material
0 COLORDEF 0 Black 8 33 33 33 -1 -1 -1 normal
0 COLORDEF 1 Blue 0 0 51 178 -1 -1 -1 normal
0 COLORDEF 21 GlowDark 0x277cc00 224 255 176 -1 -1 -1 glowing
0 COLORDEF 25 Orange 0x2000000 249 96 0 -1 -1 -1 normal
0 COLORDEF 33 TransBlue 0x2002266 0 32 160 -1 -1 -1 transparent
0 COLORDEF 256 RubberBlack 0x2000000 33 33 33 -1 -1 -1 rubber
0 COLORDEF 334 ChromeGold 15 196 0 38 255 220 0 metallic
0 COLORDEF 375 RubberGray 8 193 194 193 -1 -1 -1 rubber
0 COLORDEF 383 ChromeSilver 8 255 255 255 193 194 193 metallic
/Lars
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Lars C. Hassing wrote:
> Since no software can handle the file right now, I suggest the format is changed into:
> 0 COLORDEF color name edgecolor r g b dr dg db material
Right off the bat, I'd like to say that I think using a different notation
for (A)RGB would be a good thing. Whether it's #RRGGBB or something else,
I don't care.
Also, should we go to a tagged format? Tags could make it easier to
support multiple optional features. Maybe the standard parameters (code,
name, edge, r g b) would be untagged, and everything else could be tagged.
> COLORDEF in stead of COLOR to avoid confusion with ldlite COLOR.
I assume it would be a trivial change for LDLite/ldglite to support this
new file. They've already got the logic to use ldliterc.dat, they'd need to
duplicate the call to use ldconfig.ldr.
However, I think changing to COLOURDEF (following Ross's point on spelling)
would be a good idea.
> For edgecolor you can also use extended colors 0x02RRGGBB,
> which is supported by MLCad/LDView/L3P/L3Lab,
> see http://www.hassings.dk/l3/l3p.html#extcol
My preference would be to use a specific notation for direct RGB values,
instead of having extended values. Something like RGB rrggbb. Or just
#rrggbb, and require hex notation.
> "a" is left out (since it is always 255 ?)
Well, the idea is that "a" should be allowed to vary.
> "da" is left out, use material=transparent.
>
> You can specify "dr dg db" as "-1 -1 -1", which means no dithering.
> It is easier than replicating the "r g b" values, and is less error prone.
Since dithering should be very rare, why not make it optional with a tag?
Something like:
DITHER #RRGGBB
> "material" added, can be normal/transparent/rubber/metallic/glowing
> The rubber is a convenient shortcut, as a "0 MATERIAL RUBBER"
> in the tire files would be preferred.
Yes, exactly. Except that MATERIAL would be more than convenient -- there
are a few pieces available in multiple materials. The Creator sets had
previously-existing pieces in chrome-plated versions. So we can't code
0 MATERIAL METALLIC into those part files.
> Then you could easily have a (virtual) green rubber tire.
>
> Example:
> 0 // Code ColorName EdgeColor R G B DR DG DB Material
> 0 COLORDEF 0 Black 8 33 33 33 -1 -1 -1 normal
> 0 COLORDEF 1 Blue 0 0 51 178 -1 -1 -1 normal
> 0 COLORDEF 21 GlowDark 0x277cc00 224 255 176 -1 -1 -1 glowing
> 0 COLORDEF 25 Orange 0x2000000 249 96 0 -1 -1 -1 normal
> 0 COLORDEF 33 TransBlue 0x2002266 0 32 160 -1 -1 -1 transparent
> 0 COLORDEF 256 RubberBlack 0x2000000 33 33 33 -1 -1 -1 rubber
> 0 COLORDEF 334 ChromeGold 15 196 0 38 255 220 0 metallic
> 0 COLORDEF 375 RubberGray 8 193 194 193 -1 -1 -1 rubber
> 0 COLORDEF 383 ChromeSilver 8 255 255 255 193 194 193 metallic
My counter-example would be:
0 // Code ColorName EdgeColor ARGB Optionals
0 COLOURDEF 0 Black 8 #FF212121
0 COLOURDEF 1 Blue 0 #FF0053B2
0 COLOURDEF 21 GlowDark #77cc00 #F0E0FFB0 MATERIAL GLOWING
0 COLOURDEF 25 Orange #000000 #FFF96000
0 COLOURDEF 33 TransBlue #002266 #000020A0 MATERIAL TRANSPARENT
0 COLOURDEF 256 RubberBlack #000000 #FF212121 MATERIAL RUBBER
0 COLOURDEF 334 ChromeGold 15 #FFC40026 DITHER #FFDC00 MATERIAL METALLIC
0 COLOURDEF 375 RubberGray 8 #FFC1C2C1 MATERIAL RUBBER
0 COLOURDEF 383 ChromeSilver 8 #FFFFFFFF DITHER #C1C2C1 MATERIAL METALLIC
Steve
| | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Steve Bliss wrote:
> [XPFUT lugnet.cad.dev.org.ldraw]
>
> In lugnet.cad, Andrew Westrate wrote:
> > I've been thinking about this a little bit, and I'd like to propose a
> > solution. I think that with the next parts update, we should include
> > a "colors.lst" file.
>
> A little more has happened on this: I emailed the authors of most of the
> LDraw-compatible software packages, and asked for buy-in on this idea.
> Basically, my thought was that we needed to have agreement about the file name
> and location, more than we needed to hash out the details about the contents.
>
> Generally, the response was favorable, so I'm bringing discussion back here for
> more ideas.
>
> I developed the idea a little more, suggesting that we plan for a general
> 'configuration file' that might get used for other settings besides color
> definitions. I don't know what those 'other settings' might be right now, but
> it seems reasonable to allow for the possibility.
>
> My suggestion for the file name is ldconfig.ldr. This seems to identify the
> file adequately. I happened to have a fairly extensive colors file lying
> around. I cleaned it up, and here it is. I'm planning to put in this file in
> the 2003-02 parts update, in the ldraw/ directory.
>
> Notice that this file won't actually work fully in any software, AFAIK. The
> main problem is that it attempts to define color codes in the 'dithered color'
> range, which LDLite doesn't support. But as I said previously, the content can
> be hashed out over time. The important thing is to get a file out there into
> the hands of people who can dissect it. :)
>
> Comments? Suggestions? Criticisms?
Any reason it doesnt have "colour" in the name? It seems to only contain colour
definitions, or will this be extended in future for other things (possibly)?
Also, in keeping with the Australian flavour of LDraw parts, descriptions, etc,
maybe the line identifier should be "COLOUR" or "COLOURDEF"?
ROSCO
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Ross Crawford wrote:
> Any reason it doesnt have "colour" in the name? It seems to only contain colour
> definitions, or will this be extended in future for other things (possibly)?
Right - it might be used for other things, either by LDraw.org (ie, as a general
standard), or by specific programs.
> Also, in keeping with the Australian flavour of LDraw parts, descriptions, etc,
> maybe the line identifier should be "COLOUR" or "COLOURDEF"?
Good point. Thanks for pointing that out.
Steve
| | | | | | |
