| |
In lugnet.cad, Willy Tschager wrote:
> Hi folks,
>
> the colors page at LDraw.org has been updated:
>
> http://www.ldraw.org/Article93.html
>
> You'll find links to localized versions of the color table as well as Philo's
> Visual LDConfig.ldr picture: http://news.lugnet.com/announce/?n=4016
>
> Bye, w.
All this work on the colours is fantastic, guys. If I get some time I plan to
try to work out how to make the pearl colours in POVray. But time is the
precious commodity.
For those that are interested (and have a copy of perl) I wrote a little script
to patch the new colours directly into MLCad by altering the executable (windows
only). It seems to have eliminated the problems with 10 million colour comments
at the start of LDraw file output. Contact me directly if you are interested.
Tim
|
|
| |
In lugnet.cad, Willy Tschager wrote:
> Hi folks,
>
> the colors page at LDraw.org has been updated:
>
> http://www.ldraw.org/Article93.html
>
> You'll find links to localized versions of the color table as well as Philo's
> Visual LDConfig.ldr picture: http://news.lugnet.com/announce/?n=4016
>
> Bye, w.
That's good!
Anyway, there are still many color codes included in official parts
(39,257,258,260...) that seems are not supported.
I have already rosen the problem in a previous discussion and the answer was
that they where MLCad color codes and not "official" ldraw colors, even if
include in "official" ldraw parts (!?)
So, what about it? How can I translate these color code to or how should I have
to manage them?
They are NOT listed in the color list in http://www.ldraw.org/Article93.html
nore in http://www.ldraw.org/Article547.html table of colors !!
Isn't it possible to just add missed color codes, at least 39 since is largely
used in doors and windows
please let me know...
Sergio
|
|
| |
In lugnet.cad.dev.org.ldraw, Sergio Reano wrote:
> Anyway, there are still many color codes included in official parts
> (39,257,258,260...) that seems are not supported.
>
> I have already rosen the problem in a previous discussion and the answer was
> that they where MLCad color codes and not "official" ldraw colors, even if
> include in "official" ldraw parts (!?)
>
> So, what about it? How can I translate these color code to or how should I have
> to manage them?
I started fixing those parts and they will be uploaded to the PT for
certification since some also include minor primitive substitution as well as
BFCing. However I cannot forseen when those fixes will be ultimately be shipped
in an official parts update (as you know the PT is the best example for
Einstein's quote that "Time is Relative" :-P) .
This leaves you with two posibilities:
* Set all colors which are not listed in the LDConfig.ldr to light gray
or
* handle it like LDView. Which apparently uses an internal color table for those
not in the color file. Travis?
w.
|
|
| |
In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> In lugnet.cad.dev.org.ldraw, Sergio Reano wrote:
> > Anyway, there are still many color codes included in official parts
> > (39,257,258,260...) that seems are not supported.
> >
> > I have already rosen the problem in a previous discussion and the answer was
> > that they where MLCad color codes and not "official" ldraw colors, even if
> > include in "official" ldraw parts (!?)
> >
> > So, what about it? How can I translate these color code to or how should I have
> > to manage them?
>
> I started fixing those parts and they will be uploaded to the PT for
> certification since some also include minor primitive substitution as well as
> BFCing. However I cannot forseen when those fixes will be ultimately be shipped
> in an official parts update (as you know the PT is the best example for
> Einstein's quote that "Time is Relative" :-P) .
>
> This leaves you with two posibilities:
>
> * Set all colors which are not listed in the LDConfig.ldr to light gray
>
> or
>
> * handle it like LDView. Which apparently uses an internal color table for those
> not in the color file. Travis?
>
> w.
That's a really good new!!! since something is moving on and that's enough for
me.
In the while I will translate all missed color codes in the range on transparent
colors to a light grey transparent (having code between 32 and 63) and all the
other color to color code 7.
This way, if color table will be updated the color codes will be found, or if
you fix the part, the patching code will not be applied. And I needn't to change
again the code !!
Many thanks!!
Sergio
|
|
| |
In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> * handle it like LDView. Which apparently uses an internal color table for those
> not in the color file. Travis?
That is correct. LDView has its own internal color table, which is used if you
don't check the "Process ldconfig.ldr" check box in the General tab of its
preferences. When you check that check box, it overrides these default colors
using the ones in ldconfig.ldr. However, any that aren't overridden are left
with the original LDView values.
--Travis
|
|
| |
In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> In lugnet.cad.dev.org.ldraw, Sergio Reano wrote:
> > Anyway, there are still many color codes included in official parts
> > (39,257,258,260...) that seems are not supported.
> >
> > I have already rosen the problem in a previous discussion and the answer was
> > that they where MLCad color codes and not "official" ldraw colors, even if
> > include in "official" ldraw parts (!?)
> >
> > So, what about it? How can I translate these color code to or how should I have
> > to manage them?
>
> I started fixing those parts and they will be uploaded to the PT for
> certification since some also include minor primitive substitution as well as
> BFCing. However I cannot forseen when those fixes will be ultimately be shipped
> in an official parts update (as you know the PT is the best example for
> Einstein's quote that "Time is Relative" :-P) .
>
> This leaves you with two posibilities:
>
> * Set all colors which are not listed in the LDConfig.ldr to light gray
>
> or
>
> * handle it like LDView. Which apparently uses an internal color table for those
> not in the color file. Travis?
>
> w.
I apparently have missed the discussion when it comes to certain colors are
suddenly "not supported," but I'd like to register my opinion on it.
It is a huge error to be calling colors in the ranges of 32-47 and 256-511 as
"MLCad color codes" or to somehow suggest that they shouldn't be considered
valid just because they don't show up in the LDConfig.ldr file. As I understand
it, the original LDraw executable defined the following colors:
0 - 15 : prefined set of common part colors
16, 24 : main color, edge color
32 - 47 : the 0 - 15 set of colors, but rendered as transparent (i.e. just
adding 32 to first set)
256 - 511 : dithered colors; these are the main set of colors combined with
each other to form a broader color palette. This is described at the bottom of
this page: http://www.ldraw.org/OLD/reference/specs/colors.shtml
This has nothing to do with MLCad, except that MLCad supported the original
LDraw's usage of these colors.
Over time, some of the dithered colors were redefined by convention, so that
black+black (256) became black rubber, white+white (511) became white rubber,
yellow+yellow (494) became electrical contact metal. Eventually the LDConfig
file was created and these were formalized.
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.
So, how about we just add the missing transparent and dithered colors to the
config file?
Andy
|
|
| |
In lugnet.cad.dev.org.ldraw, Andrew Westrate wrote:
> I apparently have missed the discussion when it comes to certain colors are
> suddenly "not supported," but I'd like to register my opinion on it.
>
> It is a huge error to be calling colors in the ranges of 32-47 and 256-511 as
> "MLCad color codes" or to somehow suggest that they shouldn't be considered
> valid just because they don't show up in the LDConfig.ldr file. As I understand
> it, the original LDraw executable defined the following colors:
>
> 0 - 15 : prefined set of common part colors
> 16, 24 : main color, edge color
> 32 - 47 : the 0 - 15 set of colors, but rendered as transparent (i.e. just
> adding 32 to first set)
> 256 - 511 : dithered colors; these are the main set of colors combined with
> each other to form a broader color palette. This is described at the bottom of
> this page: http://www.ldraw.org/OLD/reference/specs/colors.shtml
>
> This has nothing to do with MLCad, except that MLCad supported the original
> LDraw's usage of these colors.
>
> Over time, some of the dithered colors were redefined by convention, so that
> black+black (256) became black rubber, white+white (511) became white rubber,
> yellow+yellow (494) became electrical contact metal. Eventually the LDConfig
> file was created and these were formalized.
>
> 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.
>
>
> So, how about we just add the missing transparent and dithered colors to the
> config file?
>
> Andy
Although I have decided to refrain from participation in this thread (you
already know my position and you totally neglect it), I make one exception and
say "Amen!" to all of Andy's points above.
/Tore
|
|
| |
> 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?
|
|
| |
In lugnet.cad.dev.org.ldraw, Andrew Westrate wrote:
> In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> > In lugnet.cad.dev.org.ldraw, Sergio Reano wrote:
> > > Anyway, there are still many color codes included in official parts
> > > (39,257,258,260...) that seems are not supported.
> > >
> > > I have already rosen the problem in a previous discussion and the answer was
> > > that they where MLCad color codes and not "official" ldraw colors, even if
> > > include in "official" ldraw parts (!?)
> > >
> > > So, what about it? How can I translate these color code to or how should I have
> > > to manage them?
> >
> > I started fixing those parts and they will be uploaded to the PT for
> > certification since some also include minor primitive substitution as well as
> > BFCing. However I cannot forseen when those fixes will be ultimately be shipped
> > in an official parts update (as you know the PT is the best example for
> > Einstein's quote that "Time is Relative" :-P) .
> >
> > This leaves you with two posibilities:
> >
> > * Set all colors which are not listed in the LDConfig.ldr to light gray
> >
> > or
> >
> > * handle it like LDView. Which apparently uses an internal color table for those
> > not in the color file. Travis?
> >
> > w.
>
> I apparently have missed the discussion when it comes to certain colors are
> suddenly "not supported," but I'd like to register my opinion on it.
>
> It is a huge error to be calling colors in the ranges of 32-47 and 256-511 as
> "MLCad color codes" or to somehow suggest that they shouldn't be considered
> valid just because they don't show up in the LDConfig.ldr file. As I understand
> it, the original LDraw executable defined the following colors:
>
> 0 - 15 : prefined set of common part colors
> 16, 24 : main color, edge color
> 32 - 47 : the 0 - 15 set of colors, but rendered as transparent (i.e. just
> adding 32 to first set)
> 256 - 511 : dithered colors; these are the main set of colors combined with
> each other to form a broader color palette. This is described at the bottom of
> this page: http://www.ldraw.org/OLD/reference/specs/colors.shtml
>
> This has nothing to do with MLCad, except that MLCad supported the original
> LDraw's usage of these colors.
>
> Over time, some of the dithered colors were redefined by convention, so that
> black+black (256) became black rubber, white+white (511) became white rubber,
> yellow+yellow (494) became electrical contact metal. Eventually the LDConfig
> file was created and these were formalized.
>
> 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.
>
>
> So, how about we just add the missing transparent and dithered colors to the
> config file?
>
> Andy
Sorry, but I really cannot understand the need to encode dithered colors.
Personally I think that only colors used for parts should be coded, while, when
you create a patterned part you can choose to use a "good enough" already coded
color or create your dithered one.
But again, is this so necessary? Patterned parts often contains fine detail
where color differences between and existing or a new dithered color are not so
appreciable. Moreover, as a programmer, my "amatory" software is not capable to
evidence that kind of differences.
Don't believe it? Try the following sample with either LDVIEW or SR3D Builder or
MLCad and ensure to use latest ldConfig.
-----------------------------------------
- 0
- 1 19 0 0 0 1 0 0 0 1 0 0 0 1 3001.DAT
- 1 68 0 -24 0 1 0 0 0 1 0 0 0 1 3001.DAT
- 1 226 0 48 0 1 0 0 0 1 0 0 0 1 3001.DAT
- 1 18 0 72 0 1 0 0 0 1 0 0 0 1 3001.DAT
- 1 125 0 -48 0 1 0 0 0 1 0 0 0 1 3001.DAT
-----------------------------------------
Yes, you notice the difference between top bricks, but what about the lower? You
have to arrange reflection angle to notice something so, in my opinion, who
cares?
Finally, don't forget that
- choosing from a too rich palette of colors may waste time
- Many software needs accommodation to support dithered colors
If dithered colors is a real need then they should be a chosen of parts
creators. Final user applications just show parts created by their creators
showing coded or dithered colors, but users can only choose the part color.
This way dithered color will be created "on the fly" (from the software
supporting them!) and need not to be coded!
anyway this is just my opinion...
Sergio
|
|
| |
Nobody ever listens to me on the issue of colors, but that doesn't
mean I'll go quietly...
In lugnet.cad.dev.org.ldraw, Sergio Reano wrote:
> In lugnet.cad.dev.org.ldraw, Andrew Westrate wrote:
> > ...
> > So, how about we just add the missing transparent and dithered
> > colors to the config file?
I don't see why they need to be added to the ldConfig file as long as
they're documented somewhere and accepted as the standard default
LDraw pallette. The *only* reason I can think of for putting them all
there would be to prevent the Official Color Police from stepping in
and declaring all underutilized colors should be replaced by dull
grey. But why would anyone in their right mind do that?
> Sorry, but I really cannot understand the need to encode dithered
> colors. Personally I think that only colors used for parts should
> be coded, while, when you create a patterned part you can choose to
> use a "good enough" already coded color or create your dithered one.
The original LDraw defined a bunch of handy numbered colors up to 512,
some of them dithered due to technical limitations at the time. For
quite a while this was accepted as the universal LDraw pallette. Now,
over time many of these have been selected to represent real Lego
colors, and some have been tweaked a bit in the ldConfig file to
better match the real Lego colors. I'm pretty happy with that
approach, as long as the tweaking doesn't change say a reddish color
to a bluish color for no good reason. With this approach, older
software will always render something that looks close to the current
running LDraw official list of tweaked colors, and people still using
the old stuff will be happy. Meanwhile any new software can make
things look exactly as intended by the Official Color Police.
Who cares if some of the colors were originally dithered for technical
reasons? New software doesn't have to dither them. I'm pretty sure
LDview just averages the two component colors. I know ldglite does
that and it's just about as old as dirt. It's easy, and the source
code for both of these is accessible on the sourceforge if you need
help.
> But again, is this so necessary? Patterned parts often contains fine
> detail where color differences between and existing or a new
> dithered color are not so appreciable. Moreover, as a programmer, my
> "amatory" software is not capable to evidence that kind of
> differences.
> ...
> Yes, you notice the difference between top bricks, but what about
> the lower? You have to arrange reflection angle to notice something
> so, in my opinion, who cares?
I agree with the spirit of this. "Close enough" is fine for most of
us.
> Finally, don't forget that
> - choosing from a too rich palette of colors may waste time
> - Many software needs accommodation to support dithered colors
Who thinks 512 colors is too rich a palatte? I think it's just right.
> If dithered colors is a real need then they should be a chosen of
> parts creators. Final user applications just show parts created by
> their creators showing coded or dithered colors, but users can only
> choose the part color. This way dithered color will be created "on
> the fly" (from the software supporting them!) and need not to be
> coded!
Stop thinking of them as "dithered" colors! They don't have to be
rendered that way. Just don't let anyone force us to turn them all
grey.
Have Fun,
Don
|
|
| |
In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> Nobody ever listens to me on the issue of colors, but that doesn't
> mean I'll go quietly...
>
> In lugnet.cad.dev.org.ldraw, Sergio Reano wrote:
> > In lugnet.cad.dev.org.ldraw, Andrew Westrate wrote:
> > > ...
> > > So, how about we just add the missing transparent and dithered
> > > colors to the config file?
>
> I don't see why they need to be added to the ldConfig file as long as
> they're documented somewhere and accepted as the standard default
> LDraw pallette. The *only* reason I can think of for putting them all
> there would be to prevent the Official Color Police from stepping in
> and declaring all underutilized colors should be replaced by dull
> grey. But why would anyone in their right mind do that?
>
> > Sorry, but I really cannot understand the need to encode dithered
> > colors. Personally I think that only colors used for parts should
> > be coded, while, when you create a patterned part you can choose to
> > use a "good enough" already coded color or create your dithered one.
>
> The original LDraw defined a bunch of handy numbered colors up to 512,
> some of them dithered due to technical limitations at the time. For
> quite a while this was accepted as the universal LDraw pallette. Now,
> over time many of these have been selected to represent real Lego
> colors, and some have been tweaked a bit in the ldConfig file to
> better match the real Lego colors. I'm pretty happy with that
> approach, as long as the tweaking doesn't change say a reddish color
> to a bluish color for no good reason. With this approach, older
> software will always render something that looks close to the current
> running LDraw official list of tweaked colors, and people still using
> the old stuff will be happy. Meanwhile any new software can make
> things look exactly as intended by the Official Color Police.
I for one would have been very happy with that approach. That's exactly what I
have tried to tell over and over and over again. Could those of you who have
their intellectual write protection on, pretty pretty please unlock it for just
a few lines.
* Color 256-512 are *NOT*, I repeat *NOT* "MLCad colors". They are true LDraw
colors, as opposed to color 48-255. As any LDraw compatible L-Cad tool, also
MLCad accepts and fully supports color 256-512.
* Color 256-512 are officially recognized, fully backwards compatible colors,
right back to original LDraw, as opposed to color 48-255.
* Color 256-512 were dithered by software using a 16 color palette, but blended
by all newer software, or, if there is an entry for the color in question,
rendered according to instructions in LDConfig.ldr.
* I do accept (believe it or not!) that new transparent colors turn out dull
grey in L3Lab since original LDraw only supported 16 tranperent colors and Lego
makes a lot more than 16. Here we have a strong reason to sacrifice my dear
backwards compability.
* And once again: new official LDraw colors should be numbered in the range
256-512 as long as there are free numbers, preferable as close as possible to
the dithered/blended color a renderer not supporting LDConfig.ldr produces. But
if it turns out the wrong color, it's not that important. It's much, much better
than an errormsgboxes and dull gray.
Is it really that hard to step down from the pride and stubbornness to show just
a little tiny bit consideration? What I ask is by no means slowing down the
progress or making any photorealistic rendering less photorealistic. Now that
any possible misunderstandings about "MLCad colors" should be straightened out
for any not completely write protected mind, to keep sabotaging backwards
compability, obviously for no other reason than sabotaging's sake, can't be
interpreted in any other way than mere ill will.
>
> Who cares if some of the colors were originally dithered for technical
> reasons? New software doesn't have to dither them. I'm pretty sure
> LDview just averages the two component colors. I know ldglite does
> that and it's just about as old as dirt. It's easy, and the source
> code for both of these is accessible on the sourceforge if you need
> help.
>
> > But again, is this so necessary? Patterned parts often contains fine
> > detail where color differences between and existing or a new
> > dithered color are not so appreciable. Moreover, as a programmer, my
> > "amatory" software is not capable to evidence that kind of
> > differences.
> > ...
> > Yes, you notice the difference between top bricks, but what about
> > the lower? You have to arrange reflection angle to notice something
> > so, in my opinion, who cares?
>
> I agree with the spirit of this. "Close enough" is fine for most of
> us.
>
> > Finally, don't forget that
> > - choosing from a too rich palette of colors may waste time
> > - Many software needs accommodation to support dithered colors
>
> Who thinks 512 colors is too rich a palatte? I think it's just right.
(Just over 300 colors in the unlike event that anyone should listen to me.)
Still too rich IMO. I agree on that it may waste time. Any establish color not
yet added to LDConfig.ldr should be added ASAP. No need to change well
established color codes - especially into backwards incompatible numbers!
Picking a new, un-established color for pattern usade from the range 256-512
today would be not future safe as it may be defined completely differently when
added to LDConfig.ldr.
Therefor, and in order to keep LDConfig.ldr fairly comprehensive, I suggest RGB
coding allowed in patterned parts for the PT and official Parts library. I do
not wish to browse among pattern colors when I wish to pick a part color. The
RBG coding should of course follow the very old and well established standard of
0x02RRGGBB - 0x04RRGGBB, and I don't mind 0x05, too.
>
> > If dithered colors is a real need then they should be a chosen of
> > parts creators. Final user applications just show parts created by
> > their creators showing coded or dithered colors, but users can only
> > choose the part color. This way dithered color will be created "on
> > the fly" (from the software supporting them!) and need not to be
> > coded!
>
> Stop thinking of them as "dithered" colors! They don't have to be
> rendered that way. Just don't let anyone force us to turn them all
> grey.
Amen to that!
> Have Fun,
>
> Don
You too!
/Tore
|
|
| |
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> * Color 256-512 are *NOT*, I repeat *NOT* "MLCad colors". They are true LDraw
> colors, as opposed to color 48-255. As any LDraw compatible L-Cad tool, also
> MLCad accepts and fully supports color 256-512.
Just to be clear: all colors from 0 to 511 (except 16 and 24) are true LDraw
colors. For color codes less than 256, LDraw would use the lowest 4 bits to
determine the color value. The sixth bit would determine transparency. The
other bits were basically ignored.
--
Steve
(who is happy that LDRAW.EXE still runs on Windows XP)
|
|
| |
In lugnet.cad.dev.org.ldraw, Steve Bliss wrote:
> In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> > * Color 256-512 are *NOT*, I repeat *NOT* "MLCad colors". They are true LDraw
> > colors, as opposed to color 48-255. As any LDraw compatible L-Cad tool, also
> > MLCad accepts and fully supports color 256-512.
>
> Just to be clear: all colors from 0 to 511 (except 16 and 24) are true LDraw
> colors. For color codes less than 256, LDraw would use the lowest 4 bits to
> determine the color value. The sixth bit would determine transparency. The
> other bits were basically ignored.
Do you mean that original LDraw accepts color 48, 65, 133 without error message?
I didn't know that. Pity L3Lab (and L3P v1.3 which I no longer use)don't act
that way.
If so, I guess I stand corrected. And blushing.
But yet, with a little weaker support from historic facts, I still appeal (now
in a more humble way) not to use colors 48-255 for defining new colors in
LDConfig.ldr. Even on a borrowed PC with 2.5GHz CPU, LDView is totally
unaccepably slo-o-o-ow with no fast render options making any noticable
difference on huge models, so L3Lab is still my no. 1 everyday life renderer
without any competition.
/Tore
|
|
| |
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> Do you mean that original LDraw accepts color 48, 65, 133 without error message?
Yes, exactly. 48 is rendered as trans-black, 65 is blue, and 133 should be dark
pink (or whatever we're calling color #5 today).
Steve
|
|
| |
In lugnet.cad.dev.org.ldraw, Steve Bliss wrote:
> In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> > Do you mean that original LDraw accepts color 48, 65, 133 without error message?
>
> Yes, exactly. 48 is rendered as trans-black, 65 is blue, and 133 should be dark
> pink (or whatever we're calling color #5 today).
>
> Steve
Oh.
Oh.
I... I wish somebody had told me this before, instead of arrogant and provoking
things like: "Welcome to 2009". Or maybe someone has tried, but I've been the
write protected that time?
/Tore
|
|
| |
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> Is it really that hard to step down from the pride and stubbornness to show just
> a little tiny bit consideration?
Tore,
Feel free to add any color, RGB, name or number you like to the LDConfig.ldr.
file. I really won't stand in the way of 100% backwards compatibility to L3Lab.
w.
|
|
| |
In lugnet.cad.dev.org.ldraw, Steve Bliss wrote:
> --
> Steve
> (who is happy that LDRAW.EXE still runs on Windows XP)
Hi Steve,
good to hear from you again. Would you mind lokking into this:
http://news.lugnet.com/cad/?n=16608
Thx,
w.
|
|
| |
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> Could those of you who have
> their intellectual write protection on, pretty pretty please unlock it for just
> a few lines.
I'm gonna explain (and quit afterwards) why I hesitate adding new and old - what
I call "MLCad" - colors to the LDConfig.ldr file:
* The current LDConfig.ldr contains only colors you'll find in official LEGO
Bricks (with two exceptions "Electric Contact Alloy" and "Electric Contact
Copper") with the purpose to limit the choice for the average user. (Since the
color file is easily editable you can always add colors if you wanna paint
landscapes with LDraw parts). It would have had the advantage that you could
have taken your project and go to BL buying whatever you want without carrying
what LDraw color corresponds to BL.
* Dithered colors like 276 or 283 will ultimately show up in the color table of
your editor
http://bricksmith.sourceforge.net/temp/postings/Lugnet20090817_ColorPickerNewLDConfig.png
and this was also the reason why we moved the TLG colors out of the file. IMHO
it would only confuse users if they find not only "Black", "Dark Gray", "Light
Gray", ... "White", but also "Lighter Dark Gray", "Darker Dark Gray" or a
"Whiter shade of pale" just because they can be found in patterns and stickers.
The way out of this dilemma would have been:
* Force the authors the use "good enough" official LEGO colors for their
patterns
or
* Allow every possible color in the 0x4RGBRGB syntax in parts
or
* Add new colors to the LDConfig.ldr with the possibility to flag them as
"Hidden" and leave it to the users if thay wanna check/uncheck non-official
colors in their editors.
Since option 2 and 3 are currently not available we went for number 1 while we
where updating the LDConfig.ldr file. And since we couldn't find a corresponding
LEGO shadow color for some of the dithered colors and they were neither in the
LDraw file defined by Steve in 2003
http://web.archive.org/web/20030801203245/www.ldraw.org/reference/specs/colors.shtml
with RGBs and names it was a logical choice. But as I said before: Do with the
file whatever you want. The current version along with German and Italian
translations can be downloaded here:
http://www.holly-wood.it/tmp/LDConfig.ldr
http://www.holly-wood.it/tmp/LDConfig_German.ldr
http://www.holly-wood.it/tmp/LDConfig_Italian.ldr
while the HTML tables for the LDraw site are here:
http://www.holly-wood.it/tmp/LDConfig_English.html
http://www.holly-wood.it/tmp/LDConfig_German.html
http://www.holly-wood.it/tmp/LDConfig_Italian.html
The files have to be send to Chris for upload, you've got "Author" and "Editor"
rights at LDraw.org, wiki is editable for everyone with an account.
w.
|
|
| |
In lugnet.cad, Willy Tschager wrote:
> Hi folks,
>
> the colors page at LDraw.org has been updated:
>
> http://www.ldraw.org/Article93.html
Running L3P v1.4 BETA on visualldconfig.mpd currently says:
SKIPPING "C:\LDraw\ldconfig.ldr" Line 40: Illegal color code: 0 !COLOUR Main_Color CODE 16 VALUE #7F7F7F EDGE #333333
SKIPPING "C:\LDraw\ldconfig.ldr" Line 54: Illegal color code: 0 !COLOUR Edge_Color CODE 24 VALUE #7F7F7F EDGE #333333
WARNING "visualldconfig.mpd" Line 1296: Color 24 illegal for this line type, using 16: 1 24 0 0 0 0 0 1 0 1 0 -1 0 0 3003.dat
I don't think it makes much sense to have colors 16 and 24 in ldconfig.ldr,
but if you insist on having them there,
I think I will silently ignore those two colors.
For the last warning, http://www.ldraw.org/Article218.html states
"Line type 1 should never use the colour 24."
so I think you should exclude the brick with color 24 (and 16) from
visualldconfig.mpd
/Lars
|
|
| |
In lugnet.cad.dev.org.ldraw, Steve Bliss wrote:
> Just to be clear: all colors from 0 to 511 (except 16 and 24) are true LDraw
> colors. For color codes less than 256, LDraw would use the lowest 4 bits to
> determine the color value. The sixth bit would determine transparency. The
> other bits were basically ignored.
OK, I'll update my programs to use this algoritm
for colors not stated in ldconfig.ldr
/Lars
|
|
|
