 | | | | | |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
Please read and respond to this message if you are a parts author,
particularly if you have authored any patterned or sticker parts.
The LSC is trying to come up with rules for colors for both LDConfig.ldr and
official parts. We are having an internal disagreement about whether the
so-called “dither” colors are still needed for use in patterned and sticker
parts. Since none of us have much experience with authoring these parts, we
decided that we needed to get the opinions of existing authors of such parts.
Please note: we are specifically looking for opinions from people who have
authored patterned/sticker parts. That isn’t to say that we will ignore
other input, but be aware that such input will have less bearing on our
decision than input from patterned/sticker part authors.
At this point, we’ve come up with three possible options:
- Explicitly allow “dither” colors in official patterned/sticker parts. Right now, they are used, but we could not find anywhere in any specification where they are even mentioned. This option would essentially officially recognize the current status quo. (I’m not aware of any “dither” colors being used outside of patterns/stickers, but we don’t intend to allow that.)
|
I don’t know if I got that right. Isn’t Maersk Blue one of those part colors
most wrongfully and misleadingly labeled as a “dithered” color?
| |
- Explicitly disallow “dither” colors in all official parts, but allow RGB colors (of the form 0x2RRGGBB) in their place in patterned/sticker parts.
- Explicitly disallow “dither” colors in all official parts, and require all patterned/sticker parts to be created using “brick” colors from LDConfig.ldr.
A few items to clarify:
- I always put “dither” in quotes, because any official recognition of said colors will be as the RGB value that the two colors average together to form, and NOT the dither pattern that was originally used in ldraw.exe.
- We don’t plan to allow non-brick 0 !COLOUR statements in LDConfig.ldr, although that’s a separate but related issue. Hence my putting “brick” in the third option.
--Travis Cobbs (on behalf of the 2009-2010 LSC)
2009-2010 LSC Members (alphabetically by last name):
Travis Cobbs
Michael Heidemann
Santeri Piippo
Allen Smith
Scott Wardlaw
|
I suggest the 0x2RRGGBB form is recommended for less “basic”/established pattern
and sticker colors. It’s much more future safe than being dependant on using the
correct version of LDConfig.ldr. I may for example use a certain area of color
codes for Modulex colors which may conflict with the next LDConfig update. Other
LDraw users may make their own color definition in LDConfig.
I repeat my opinion when it comes to defining new part color numbers for the
official LDConfig.ldr, that they should be picked from the blended (=”dithered”)
area as long as there are free numbers to choose. Thus, anyone who hasn’t the
latest LDConfig would get a fair closest existing color blend. And, of course,
no programs that support LDConfig will have any problems replacing that blended
color with the LDConfig entry! It sounds like some preople believe that picking
a number from that area would cause any problem, but that is of course not true.
Or is there something I’m unaware of?
/Tore
| | | | | | | | | | | | | | |
In lugnet.cad.dat.parts, Tore Eriksson wrote:
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
- Explicitly allow “dither” colors in official patterned/sticker parts. Right now, they are used, but we could not find anywhere in any specification where they are even mentioned. This option would essentially officially recognize the current status quo. (I’m not aware of any “dither” colors being used outside of patterns/stickers, but we don’t intend to allow that.)
|
I don’t know if I got that right. Isn’t Maersk Blue one of those part colors
most wrongfully and misleadingly labeled as a “dithered” color?
|
Two things. First of all, is Maersk Blue hard-coded into any part files? I
would expect parts that show up in Maersk Blue to have color 16 encoded in the
file, and the user to select Maersk Blue as the parts’ color when building a
model. Since we are only interested in restrictions on colors for official
parts, this wouldn’t be an issue here.
Secondly, we plan to recommend that LDConfig.ldr contain all “brick” colors,
meaning all colors that LEGO has shipped bricks in (including Maersk Blue). My
original list of options was ambiguous, but as long as a given color shows up in
LDConfig.ldr, we will be allowing it in parts, even if the color code picked
comes from the “dither” range. This will be the case no matter which of the
three options we decide upon. In other words, even if we forbid “dither” colors
from being used, colors in that range that also appear in LDConfig.ldr will
still be allowed.
| |
I repeat my opinion when it comes to defining new part color numbers for the
official LDConfig.ldr, that they should be picked from the blended
(=”dithered”) area as long as there are free numbers to choose. Thus, anyone
who hasn’t the latest LDConfig would get a fair closest existing color blend.
And, of course, no programs that support LDConfig will have any problems
replacing that blended color with the LDConfig entry! It sounds like some
preople believe that picking a number from that area would cause any problem,
but that is of course not true. Or is there something I’m unaware of?
|
What to do in LDConfig.ldr is that other half of our discussion. I can’t
remember the specifics off-hand, but we have pretty much agreed upon what to do
there. We will be releasing rules for LDConfig.ldr at the same time we enact
rules for color usage in official parts. I personally agree that new color
codes should be picked from the “dither” range where possible for maximum
backwards compatibility, but I can’t remember if this is the LSC consensus.
--Travis
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dat.parts, Travis Cobbs wrote:
> In lugnet.cad.dat.parts, Tore Eriksson wrote:
> > I don't know if I got that right. Isn't Maersk Blue one of those part colors
> > most wrongfully and misleadingly labeled as a "dithered" color?
>
> Two things. First of all, is Maersk Blue hard-coded into any part files? I
> would expect parts that show up in Maersk Blue to have color 16 encoded in
> the file, and the user to select Maersk Blue as the parts' color when
> building a model. Since we are only interested in restrictions on colors for
> official parts, this wouldn't be an issue here.
I didn't get it right at all, but now I think I do. It isn't an issue here and,
believe it or not, I'm cool with it. :)
> Secondly, we plan to recommend that LDConfig.ldr contain all "brick" colors,
> meaning all colors that LEGO has shipped bricks in (including Maersk Blue).
> My original list of options was ambiguous, but as long as a given color shows
> up in LDConfig.ldr, we will be allowing it in parts, even if the color code
> picked comes from the "dither" range. This will be the case no matter which
> of the three options we decide upon. In other words, even if we forbid
> "dither" colors from being used, colors in that range that also appear in
> LDConfig.ldr will still be allowed.
Good! :)
>
> What to do in LDConfig.ldr is that other half of our discussion. I can't
> remember the specifics off-hand, but we have pretty much agreed upon what to
> do there. We will be releasing rules for LDConfig.ldr at the same time we
> enact rules for color usage in official parts. I personally agree that new
> color codes should be picked from the "dither" range where possible for
> maximum backwards compatibility, but I can't remember if this is the LSC
> consensus.
>
> --Travis
I'm glad that at least I'm not alone with this opinion. :)
/T
| | | | | | |
