Subject:
|
Re: [LSC] Colour Definition meta-statement
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Fri, 23 Jan 2004 19:06:45 GMT
|
Viewed:
|
1900 times
|
| |
|
|
In lugnet.cad.dev, Don Heyse wrote:
> If you're planning on using the DITHER tag to explicitly break up a
> single color into two dithered components for some nonexistant program,
> how can I tell the difference between that and a DITHER tag used to
> describe something real, like a dithered paint job? Look closely at
> the print on the front and back of the stormtrooper torso to see what
> I mean.
I've been keeping clear on the dither issue so far, because I didn't have a
strong opinion one way or another. However, the more I think about it, the more
I think we're not seeing the forest through the trees. Because of this, I vote
we remove DITHER from the COLOUR statement completely. Here's why.
All the examples given so far for "appropriate" uses of the dither tag were to
reproduce dithered printing on actual LEGO parts. On the surface, this seems
reasonable. However, in reality I think it isn't. As far as I know, there
aren't any LEGO parts that are dithered in the LDraw sense. They're half-toned.
If you want to produce a computer file that mimics this, then you need to know
the actual colors involved in the halftone process, and the size of the
half-tone mask. You then have to know the ratio of the base color to the
printed ink color, and finally you have to implement a half-tone algorithm. If
you do all this, then you can reproduce the look of the original.
Unless you have all of the above parameters, and actually go to the trouble of
doing a proper half-tone, all you'll end up with is a DIFFERENT approximation
than you would have gotten if you'd just gone with a solid color. The
half-toning is used on LEGO bricks because it's significantly cheaper than
having exact ink colors. It is NOT done because LEGO wanted the part to look
half-toned. In other words, if they could do so cheaply, I'm sure LEGO would
have used the actual desired colors, instead of half-toning.
Because of all this, I say ditch dither support completely, and just specify the
color you really want. Is it so bad to have the computer-generated colors look
better than the original bricks? Sure they don't match exactly, but I don't
think using checker-board dithering to approximate half-toning is an
improvement. Since you have to use an approximation anyway, I think you should
use the one that looks best.
--Travis Cobbs
|
|
Message has 2 Replies:
 | | Re: [LSC] Colour Definition meta-statement
|
| (...) I could go for that. Simpler is better! Of course that means the METALLIC (or PEARLY) tag needs an argument to define the color of the embedded bits. If you want it to be the same color as the substrate, just use the same color code. Don (20 years ago, 23-Jan-04, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: [LSC] Colour Definition meta-statement
|
| (...) But what if Lego prints an opaque dithered pattern on a transparent brick? I think the ALPHA is more versatile if only applied to the VALUE color. You can still get an alpha dither color by using a color code for d which points to a color with (...) (20 years ago, 23-Jan-04, to lugnet.cad.dev)
|
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
|
|
|
|
