Subject:
|
Re: [LSC] Colour Definition meta-statement
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Thu, 22 Jan 2004 18:29:14 GMT
|
Viewed:
|
1785 times
|
| |
|
|
In lugnet.cad.dev, Steve Bliss wrote:
> LDraw.org Colour Definition meta-statement
> ------------------------------------------
>
> This meta-statement will specify the properties of a single LDraw
> colour code. This statement may appear at any time in an LDR file,
> but will probably be most useful in the file header.
>
> Scope. A color definition will affect colors from the point it
> first appears, continuing through the end of the file. Commands
> preceding a colour definition will not be affected by the
> definition. Color definitions will expire at the end of the file in
> which they appear, effectively going out of scope. Color
> definitions will be passed to subfiles.
>
> The configuration file, ldconfig.ldr, is not affected by the scoping
> rules, in the sense that the definitions in ldconfig.ldr remain in
> effect after the renderer is finished processing ldconfig.ldr.
>
> Syntax. The entire statement must appear on one line. It's broken into
> two lines in this definition for clarity.
> 0 !COLOUR name CODE x VALUE v EDGE e [ALPHA a] [DITHER d]
> [LUMINANCE l] [CHROME | METALLIC | RUBBER | MATERIAL <params>]
>
> Tags. CODE, VALUE, EDGE, ALPHA, DITHER, LUMINANCE, CHROME,
> METALLIC, RUBBER and MATERIAL are keyword tags. Some tags are
> followed by a single parameter value. Tags are case-insensitive.
>
> Numeric parameters may be specified in decimal or hexidecimal.
> Hexidecimal values must be prefixed with #.
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?
> Byte values are integers in the range 0-255.
> Identifiers are alphanumeric strings, case-insensitive.
>
> Definitions of parameters.
> 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?
> CODE x - The LDraw color code. For LDraw compatibility, x is an
> integer 0-511. If strict LDraw compatibility is not required, x is
> any identifier recognized by a rendering program as a color code.
> Code is a required element.
>
> VALUE v - The color value. v is a 24-bit RGB value. VALUE is a
> required element.
>
> EDGE e - The contrasting edge color. e may be either a color
> code or an RGB value. EDGE is a required element.
>
> ALPHA a - The alpha channel (transparency) value. a is a byte
> value, where 0 is totally colorless and #FF is completely opaque.
> LDraw programs that use dither-transparency recognize values 1-127
> as transparent, and 128-255 as opaque. A 0 value is totally
> colorless (useful for temporarily hiding sections of models). ALPHA
> is an optional element.
Does the alpha value only apply to the VALUE color, or does it also
apply to the EDGE, DITHER colors? 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?
> 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 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.
> LUMINANCE l - Brightness for colors that glow. l is a byte
> value. Luminance is not used by LDraw renderers, but may be used
> for translation to other rendering systems. LUMINANCE is optional.
> Only one of CHROME, METALLIC, RUBBER, and MATERIAL may be
> specified for a single color. They all specify the finish/texture
> to be applied to an object being rendered. Other finish-tags may be
> defined over time.
> CHROME - A flag indicating that surfaces should have a
> mirror-like finish. Not currently used by LDraw-compatible
> programs, but may be implemented in the future. CHROME is optional,
> and may not appear with METALLIC, RUBBER or MATERIAL.
> 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?
I'd like to see a predefined METAL tag for rails and electrical
contacts.
> RUBBER - A flag indicating that surfaces should have a finish
> like rubber (typically rubber tubing or rubber tyres). RUBBER is
> optional, and may not appear with CHROME, METALLIC or MATERIAL.
> MATERIAL [name <params> ...] - Some other surface finish
> requiring customized parameter(s). Name is an identifier. MATERIAL
> is not used for official LDraw.org color definitions, it has been
> made available for use by programs. MATERIAL is optional, and may
> not appear with CHROME, RUBBER or METALLIC. MATERIAL should be the
> last tag on the !COLOUR statement.
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. Or maybe we want to be
able to override the params of a previously defined material on the
!COLOUR line?
Don
|
|
Message has 2 Replies:
 | | Re: [LSC] Colour Definition meta-statement
|
| (...) HTML uses # (...) The name should be the characters after the !COLOR keyword and before the next keyword. The only contraint I can think of is that is not be one of the other keywords. (...) ALPHA should apply to the VALUE color and the color (...) (20 years ago, 22-Jan-04, to lugnet.cad.dev)
| | | Re: [LSC] Colour Definition meta-statement
|
| (...) [snippety] (...) [doo-dah] (...) 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] (...) Good question. We hadn't thought about (...) (20 years ago, 23-Jan-04, to lugnet.cad.dev)
|
Message is in Reply To:
| | [LSC] Colour Definition meta-statement
|
| Here's the initial write up for a color definition meta-statement, to be used in ldconfig.ldr and in any model file. The LSC has a couple of outstanding issues with this spec, let's discuss those in follow-up messages. Please respond with any (...) (20 years ago, 21-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
|
|
|
|
