To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.devOpen lugnet.cad.dev in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / 9448
9447  |  9449
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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR