Subject:
|
Re: Color page updated
|
Newsgroups:
|
lugnet.cad.dev.org.ldraw
|
Date:
|
Fri, 4 Dec 2009 22:06:14 GMT
|
Viewed:
|
18022 times
|
| |
|
|
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
|
|
Message has 3 Replies:
 | | Re: Color page updated
|
| (...) 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 (...) (15 years ago, 4-Dec-09, to lugnet.cad.dev.org.ldraw)
| | | Re: Color page updated
|
| (...) 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. (15 years ago, 5-Dec-09, to lugnet.cad.dev.org.ldraw)
| | | Re: Color page updated
|
| (...) 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 (...) (15 years ago, 6-Dec-09, to lugnet.cad.dev.org.ldraw)
|
Message is in Reply To:
| | Re: Color page updated
|
| Nobody ever listens to me on the issue of colors, but that doesn't mean I'll go quietly... (...) 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. (...) (15 years ago, 4-Dec-09, to lugnet.cad.dev.org.ldraw)
|
28 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
