Subject:
|
Re: [LSC] Colour Definition meta-statement
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Fri, 23 Jan 2004 18:02:55 GMT
|
Viewed:
|
1932 times
|
| |
|
|
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Steve Bliss wrote: • [snippety]
> > Identifiers are alphanumeric strings, case-insensitive. • [doo-dah]
> > name - A short name for the color. Name may be any identifier. This
> > item is provided mainly for human recognition. Name is a required element.
>
> No spaces in the name? Alpha-numeric only? Other constraints?
I was thinking no space. So far, we've avoided wrapping literals in quotes in
LDraw (with only occasional trouble). I'd like to keep avoiding quotes.
[snippety-ay]
> Does the alpha value only apply to the VALUE color, or does it also
> apply to the EDGE, DITHER colors?
Good question. We hadn't thought about that.
The LDLite COLO[U]R statement accepts/expects ARGB (actually, RGBA) values. We
considered noting alpha in this way, but decided to go with the more-standard
RGB notation. Maybe that decision should be revisited, to allow other specified
color-values to include alpha-levels.
> I'm not sure what you mean about
> the dither-transparency. Nobody supports this format yet, so why
> are we concerned about special meanings for old programs?
Actually, most programs use 'dither-transparency'. When I wrote
'dither-transparency', I meant 'rendering transparent surfaces by drawing with a
stippled brush, specifically a brush where the stipples form a checkerboard
pattern'. Please don't get hung up on my use of the term 'dither' in this
context.
> > DITHER d - Specifies the color should be dithered, and provides
> > the second color value. d may be either a color code or an RGB
> > value. DITHER is optional.
>
> Are you thinking about original LDRAW compatibility here, or about
> future needs? I see this as a good way to represent dithered
> printing like on the 6190 aquashark baseplate, and perhaps to provide
> a separate color for the embedded bits in the pearly bricks, but not
> much else.
I expect most dithered printing to also be gradiated (gradiented?). So, IMO, a
DITHER option on a color definition would only be of limited use to resolve the
half-tone printing issue.
> I sort of wish the DITHER and EDGE colors had their own
> ALPHA and LUMINANCE values, but I suppose you can use a color code to
> pull that in.
That's a good point. I don't expect direct-colors (ie, EDGEs and DITHERs with
RGB values) to be a full equivalent of pointing them at other LDraw colors.
> > METALLIC - A flag indicating that surfaces should have a finish
> > like Lego's 'metallic' colors. These colors are commonly called
> > 'pearlescent' by fans. Not currently implemented in
> > LDraw-compatible programs. METALLIC is optional, and may not appear
> > with the CHROME, RUBBER or MATERIAL.
>
> Shouldn't this have an optional color for the embedded bits, or is
> that going to be handled by the DITHER color? I agree with Travis.
> METALLIC is confusing. What's wrong with PEARLY or SPARKLY? Is
> metallic what Lego calls it?
As I understand it, Lego calls it Metallic.
I consider all of the little-m material tags to act as directives to the
rendering programs to use certain settings or parameters. IOW, I don't plan on
specifying what 'RUBBER' means in the LDraw meta-statement.
> I'd like to see a predefined METAL tag for rails and electrical
> contacts.
nod, yes.
> Do we really want the MATERIAL params on the same line as the color?
> I think we just want the name there. Define the params somewhere
> else. Think about the predefined materials we have now (ABS, RUBBER,
> CHROME...). They come in multiple colors. Define the material once
> and select it by name on the !COLOUR line.
Again, I consider all of the little-m material tags to act as directives to the
rendering programs to use certain settings or parameters. IOW, I don't plan on
specifying what 'RUBBER' means in the LDraw meta-statement.
OTOH, if someone wants to write a functional definition of RUBBER, METALLIC,
CHROME, etc, in terms that can be code and still by useable by different
rendering engines, I'd be very keen on seeing it, and would certainly be willing
to consider putting into LDraw's definitions.
> Or maybe we want to be
> able to override the params of a previously defined material on the
> !COLOUR line?
I would see that as a good thing, depending on what I outlined in my prior
paragraph.
Steve
|
|
Message has 1 Reply:
 | | Re: [LSC] Colour Definition meta-statement
|
| (...) I realize many current ldraw rendering programs use a stipple pattern to render transparent surfaces. I do it in ldglite because I'm too lazy to do the sorting required to use alpha blending. However, I don't really want the specs to dictate (...) (21 years ago, 23-Jan-04, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: [LSC] Colour Definition meta-statement
|
| (...) I prefer the currently used 0x prefix, but I guess if you picked # to match other file formats in use by ldraw users then I can live with it. I forget, does POV or HTML use # for the hex prefix? (...) No spaces in the name? Alpha-numeric only? (...) (21 years ago, 22-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
|
|
|
|
