| |
> In my opinion, just because some of these colors didn't make it into the config
> file, that doesn't mean they're not valid, because
>
> A) we have always tried to maintain backwards compatibility, and
> B) we have to allow not only for the color of molded plastic and rubber
> pieces, but also all the colors of printed parts. There are far more shades of
> paint colors used on printed parts then there will ever be of ABS plastic, and
> as long as we do patterns as quads and triangles, we have to have a big enough
> color palette to accomodate that.
>
> C) So, how about we just add the missing transparent and dithered colors to the
> config file?
This isn't the first time that LDconfig.ldr has been updated - and it is just
that, the file has been updated with MORE colors than before.
I think we are loosing sight of the purpose of LDconfig.ldr...
The LDconfig file is meant to be a quick cheat sheet... it is meant to help
standardize the colors used through easy to use Color Codes. It is meant to be
made up of colors that everyone can recognize. These colors are simply, the
colors of LEGO parts that exist in the real world.
However, if you want a part to have a color that is not in LDconfig, you can
still spell out the RGB values instead of using the Color Codes. LDconfig is a
reference for standard colors and does not limit you to only using these colors.
A) No colors were removed from it. Therefore, it is still backwards compatible.
B) If you think about it, because of manufactoring differences, age, technology
improvements, and even human oversight, there are Red bricks that don't match
other Red bricks. Fortunately for us, the world of imaginary LEGO can be as
perfect as we would like. For us, all of the Reds (including stickers and
printed bricks that were intended to be Red) can all be the same color Red.
This is how the LDconfig file helps standardize colors. Otherwise, everyone
would have different RGB values for the same Red in their parts.
C) The transparent colors that are missing don't actually exist in the real
world. The ones that you are refering to were made from the original 16 colors
- not actually from real LEGO colors. The transparent colors that are included
in LDconfig actually exist in real life. If you do happen to find a real brick
with a color that is not in LDconfig; please let us know.
Likewise with the dithered colors. This system was a quick (and worthy)
solution when it was created. In recent years, it has caused a great deal of
problems. Again, these colors don't exist in real bricks, so should not be
included as colors that LDraw recognizes as a standard.
Scott W.
Member LSC
|
|
| |
In lugnet.cad.dev.org.ldraw, Scott Wardlaw wrote:
> I think we are loosing sight of the purpose of LDconfig.ldr...
>
> The LDconfig file is meant to be a quick cheat sheet... it is meant to help
> standardize the colors used through easy to use Color Codes. It is meant to be
> made up of colors that everyone can recognize. These colors are simply, the
> colors of LEGO parts that exist in the real world.
I disagree that this was the original purpose of the ldconfig file. I can say
that definitively, since I was the one who first proposed the file here:
<http://news.lugnet.com/cad/?n=10066>. The purpose was that when *new* colors
were added, ldraw software tools would have a standardized way of supporting the
new colors. It wasn't meant to limit the available ldraw colors to the actual
shades of plastic used, or to make the dithered color ranges no longer valid.
> However, if you want a part to have a color that is not in LDconfig, you can
> still spell out the RGB values instead of using the Color Codes. LDconfig is a
> reference for standard colors and does not limit you to only using these colors.
I have never seen an official LDraw part that defines a custom RGB color, nor
any part on the part tracker do that. How would you even do it? I don't know
the syntax, and haven't found any part tracker documentation saying what the
syntax is or saying it's ok for official parts.
Plus, how many programs actually support custom-defined colors? If this becomes
the mandatory way for part authors to do printed parts, how many programs are
going to be broken?
> C) The transparent colors that are missing don't actually exist in the real
> world. The ones that you are refering to were made from the original 16 colors
> - not actually from real LEGO colors. The transparent colors that are included
> in LDconfig actually exist in real life. If you do happen to find a real brick
> with a color that is not in LDconfig; please let us know.
>
> Likewise with the dithered colors. This system was a quick (and worthy)
> solution when it was created. In recent years, it has caused a great deal of
> problems. Again, these colors don't exist in real bricks, so should not be
> included as colors that LDraw recognizes as a standard.
Once again, it is a mistaken assumption that the LDraw color codes apply only to
actual brick colors. The the LDraw color codes have to allow for any color of
line or polygon which appears in a part file, be it plastic, rubber, metal,
printing, or sticker color. By saying that any part using a color in the
dithered color range is no longer allowed on the part tracker, we are seriously
limiting the ability of part authors to render a "good enough" approximation of
stickers and printed parts.
|
|
| |
In lugnet.cad.dev.org.ldraw, Andrew Westrate wrote:
> In lugnet.cad.dev.org.ldraw, Scott Wardlaw wrote:
> > I think we are loosing sight of the purpose of LDconfig.ldr...
> >
> > The LDconfig file is meant to be a quick cheat sheet... it is meant to help
> > standardize the colors used through easy to use Color Codes. It is meant to be
> > made up of colors that everyone can recognize. These colors are simply, the
> > colors of LEGO parts that exist in the real world.
>
> I disagree that this was the original purpose of the ldconfig file. I can say
> that definitively, since I was the one who first proposed the file here:
> <http://news.lugnet.com/cad/?n=10066>. The purpose was that when *new* colors
> were added, ldraw software tools would have a standardized way of supporting the
> new colors. It wasn't meant to limit the available ldraw colors to the actual
> shades of plastic used, or to make the dithered color ranges no longer valid.
I never said that it was meant to limit, only that it is made up of these colors
now. Please don't take this to mean that new colors can't be added, or that it
invalidates other colors. We already know of at least one color that should be
added for the next release. If you know of more that should be added, please
let us know (but don't say every color under the rainbow)
> > However, if you want a part to have a color that is not in LDconfig, you can
> > still spell out the RGB values instead of using the Color Codes. LDconfig is a
> > reference for standard colors and does not limit you to only using these colors.
>
> I have never seen an official LDraw part that defines a custom RGB color, nor
> any part on the part tracker do that. How would you even do it? I don't know
> the syntax, and haven't found any part tracker documentation saying what the
> syntax is or saying it's ok for official parts.
>
> Plus, how many programs actually support custom-defined colors? If this becomes
> the mandatory way for part authors to do printed parts, how many programs are
> going to be broken?
That is correct, and you probably won't ever find an official part with RGB
values instead of a Color Code. I have made several sticker parts with RGB
values instead of Color Codes, but these are for my personal use, not official.
Again, if you have a specific RGB that you believe should be added to LDconfig,
please let us know.
> > C) The transparent colors that are missing don't actually exist in the real
> > world. The ones that you are refering to were made from the original 16 colors
> > - not actually from real LEGO colors. The transparent colors that are included
> > in LDconfig actually exist in real life. If you do happen to find a real brick
> > with a color that is not in LDconfig; please let us know.
> >
> > Likewise with the dithered colors. This system was a quick (and worthy)
> > solution when it was created. In recent years, it has caused a great deal of
> > problems. Again, these colors don't exist in real bricks, so should not be
> > included as colors that LDraw recognizes as a standard.
>
> Once again, it is a mistaken assumption that the LDraw color codes apply only to
> actual brick colors. The the LDraw color codes have to allow for any color of
> line or polygon which appears in a part file, be it plastic, rubber, metal,
> printing, or sticker color. By saying that any part using a color in the
> dithered color range is no longer allowed on the part tracker, we are seriously
> limiting the ability of part authors to render a "good enough" approximation of
> stickers and printed parts.
Sorry, instead of real bricks, I meant real LEGO pieces. This can mean printed
bricks, stickers, rubber, etc. You'll note that these have already been added
when they were needed, such as Electric_Contact_Alloy, Rubber_White, etc.
|
|
| |
In lugnet.cad.dev.org.ldraw, Andrew Westrate wrote:
| |
In lugnet.cad.dev.org.ldraw, Scott Wardlaw wrote:
| |
However, if you want a part to have a color that is not in LDconfig, you can
still spell out the RGB values instead of using the Color Codes. LDconfig is
a
reference for standard colors and does not limit you to only using these
colors.
|
I have never seen an official LDraw part that defines a custom RGB color,
nor
any part on the part tracker do that. How would you even do it? I
don’t know
the syntax, and haven’t found any part tracker documentation
saying what the
syntax is or saying it’s ok for official parts.
Plus, how many programs actually support custom-defined colors? If this
becomes
the mandatory way for part authors to do printed parts, how many
programs are
going to be broken?
|
Neither did I but if you really cannot find a suitable color for your pattern
an RGB say in the form:
1 #F2F2F2 1 0 0 0 1 0 0 0 1 part.dat
would surely solve your problem. And I’m going to propose this to the new
elected LSC. As for the broken progs. We will surely break L3Lab
http://news.lugnet.com/cad/dev/org/ldraw/?n=4503 ;-)
Since it usually takes a considerable amount of time to get a part through the
PT I don’t expect popping up parts with such a code before a year. Do
you think
it will be enough time for the still active programmers to update
their code?
| |
Once again, it is a mistaken assumption that the LDraw color codes apply only
to
actual brick colors. The the LDraw color codes have to allow for any
color of
line or polygon which appears in a part file, be it plastic, rubber,
metal,
printing, or sticker color. By saying that any part using a color in
the
dithered color range is no longer allowed on the part tracker, we are
seriously
limiting the ability of part authors to render a “good enough”
approximation of
stickers and printed parts.
|
Well also the old historical RGB values are what they are - approximations.
Since we allow parts carrying “needs work” in the title I guess a “good
enough”
color is fair enough. But seriously as I stated above I started fixing
parts
using MLCad and guess what I came across? Since these:
have been considered “good
enough” to be released as official patterns don’t
you think you’ll find a color
that resembles what you are looking for?
w.
|
|
| |
In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> Neither did I but if you really cannot find a suitable color for your
> pattern¬ an RGB say in the form:¬ ¬
> 1 #F2F2F2 1 0 0 0 1 0 0 0 1 part.dat¬
> ¬
> would surely solve your problem. And I'm going to propose this to the new¬
> elected LSC. As for the broken progs. We will surely break L3Lab
Of course it would - as well as it does LDView. But after adding x, y, z
coordinates and correcting RGB code syntax would work fine with both LDView as
well as L3Lab!
1 0x02F2F2F2 0 0 0 1 0 0 0 1 0 0 0 1 part.dat
Don't know about MLCad, but I guess it will work there, too.
/Tore
|
|
| |
In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
| |
Neither did I but if you really cannot find a suitable color for your
pattern
an RGB say in the form:
1 #F2F2F2 1 0 0 0 1 0 0 0 1 part.dat
would surely solve your problem. And I’m going to propose this to the new
elected LSC. As for the broken progs. We will surely break L3Lab
http://news.lugnet.com/cad/dev/org/ldraw/?n=4503 ;-)
|
There are already two very old ways to specify RGB colors in LDraw files. One
comes from ldlite with somewhere between 12 and 15 effective bits of color
information, and the other from L3Lab/L3P with 24 bits of color information. If
we’re going to have RGB colors in official files, we need to go with one of
those pre-existing formats:
- 0x2RRGGBB: opaque RGB
- 0x3RRGGBB: transparent RGB
- 0x4RGBRGB: opaque dither of two 4-bit RGB colors
- 0x5RGBxxx: transparent dither of one 4-bit RGB color and clear; the xxx is ignored.
In all of the above examples, the R, G, and B are hex digits, just like in
Willy’s example, so 0x2F2F2F2 would produce his sample color.
My personal vote if this were to be allowed would be the 0x2RRGGBB and 0x3RRGGBB
forms. These are supported by a lot of software (including L3Lab, L3P, and
LDView). The 0x5RGBRGB form is supported by ldlite (along with L3Lab, L3P, and
LDView), but is quite awkward.
--Travis
|
|
| |
In lugnet.cad.dev.org.ldraw, Scott Wardlaw wrote:
>
> I never said that it was meant to limit, only that it is made up of these colors
> now.
I have had parts on the Part Tracker held because they used one of these colors.
That means it is limiting.
> Please don't take this to mean that new colors can't be added, or that it
> invalidates other colors. We already know of at least one color that should be
> added for the next release. If you know of more that should be added, please
> let us know (but don't say every color under the rainbow)
Color numbers 32-47 and 256-511 is not every color under the rainbow.
>
> That is correct, and you probably won't ever find an official part with RGB
> values instead of a Color Code.
This is exactly the problem.
> Sorry, instead of real bricks, I meant real LEGO pieces. This can mean printed
> bricks, stickers, rubber, etc.
If this is the case, then why are we discussing re-submitting official part
files to replace certain colors? Just add them to the config file!
> You'll note that these have already been added
> when they were needed, such as Electric_Contact_Alloy, Rubber_White, etc.
These were already a commonly-used convention when the ldconfig file was first
proposed.
---
The whole problem with this that instead of letting patterned part authors
choose a pretty good color match from a small set of color codes and submitting
the part to the PT, you want them to:
1) request a new color code
2) have that request approved by some person or committee
3) wait for the next part release so the new color can be included in the config
file (because any part that uses a strange code on the PT would get held)
and then finally they can create the part and submit it to the part tracker.
The PT is already dysfunctional (there are prefectly fine files on it from 2003
and earlier); this would make it completely useless.
|
|
| |
In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
| |
Neither did I but if you really cannot find a suitable color for your
pattern
an RGB say in the form:
1 #F2F2F2 1 0 0 0 1 0 0 0 1 part.dat
would surely solve your problem.
|
It might fix it (I think it would still gum up the PT with over-zealous hold
votes); but why break anything when we’re just talking about adding fewer than
200 lines to the config file?
I think it’s a terrible idea to make dozens of programmers change their
software, and dozens more part authors change they way they create parts, and
dozens more part reviewers change the way they review parts, just so that we
don’t add a few extra lines.
| |
Since it usually takes a considerable amount of time to get a part through
the
PT I don’t expect popping up parts with such a code before a year. Do
you think it will be enough time for the still active programmers to update
their code?
|
So, you’re saying that since the part tracker is so broken to begin with, it’s
ok if we break it even worse? There are perfectly good parts that have been on
the tracker for YEARS, either through inattention, or for frivolous hold votes.
And I think that holding for using a perfectly valid color code that somebody
just decided to leave out of the config file is frivolous. I think that
re-submitting perfectly fine official parts to the PT for using one of these
valid color codes is equally frivolous.
| |
But seriously as I stated above I started
fixing
parts using MLCad and guess what I came across? Since these
|
snip images
| |
have been considered “good
enough” to be released as official patterns don’t
you think you’ll find a
color that resembles what you are looking for?
|
I don’t know what you’re driving at with these images. The bottom two are
mostly greyscale anyway, and I don’t think that’s where the problem lies.
But here’s an example:
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/3626bph2.dat
this file has been on the PT since 2003. It had two certify votes since 2006.
Recently, it was held and I had to change a color from a close color match to
something that doesn’t look as accurate. I don’t see what we gain by doing
this, and now how many years will it take to get this certified?
|
|
|
