Subject:
|
Re: Color page updated
|
Newsgroups:
|
lugnet.cad.dev.org.ldraw
|
Date:
|
Fri, 4 Dec 2009 08:56:46 GMT
|
Viewed:
|
17180 times
|
| |
|
|
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
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | Re: Color page updated
|
| (...) 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" (...) (15 years ago, 2-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
|
|
|
|
