To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.rayOpen lugnet.cad.ray in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Ray-Tracing / 1764
1763  |  1765
Special: 
[DAT] (requires LDraw-compatible viewer)
Subject: 
Color problem- is this a bug in L3P?
Newsgroups: 
lugnet.cad.dat.models, lugnet.cad.ray
Date: 
Tue, 25 Mar 2003 01:25:54 GMT
Viewed: 
65 times
  
The attached .mpd file is showing a weird problem with colors when run
through L3P and rendered in POV-Ray.

There is a subfile that contains a single part.  In there, the part's color
is set to trans-red (Color36).  The parent file sets it to black (Color0).
That gets ignored in ldraw because the bottom-level part is trans-red, not
main-color.  So it correctly renders as trans red.

But after running it through L3P and POV-Ray, the part in the subfile (the
finned 1x1 round brick) renders as black.

Poking through the POV-Ray code and experimenting with variations on this
led me to the keyword used to declare the parts/models ("object" or
"union").  When a file (part or model) contains only one reference to
another file (again, part or model), L3P writes:

#declare [translated_filename] {object
  [reference to another file]
}

But when there are multiple references, it writes:

#declare [translated_filename] {union
  [reference to another file]
  [reference to another file]
}

At first glance, this makes sense.  You have to use a union to contain
multiple POV-Ray objects, and POV-Ray gives a warning when you use a union
containing only one object.  On the flip side, an object can only have one
other object reference.  However, the downside is that color inheritence
works differently with a union than it does with an object.  An object
inherits color from the containing object, while a union gets its color from
the colors of the contained objects.

This particular example may seem like a narrow test case that can easily be
worked around by coloring the subfile differently.  That's true, but this
first came to my attention when Jake McKee contacted me about a problem with
rendering parts in LPub- they were inheriting yet another level, and were
actually ending up showing as light-grey because that's the default color
for maincolored parts.  In LPub, you don't have fine control over everything
and in his case I don't know if there is a viable workaround.

So my question is... is this behavior a bug?  Have others seen this as well?
Should L3P be writing out a union when writing models, regardless of the
number of references inside it?  Is it a problem that POV-Ray throws a
warning?  Does that behavior break down because of some other reason?

--
Tony Hafner
www.hafhead.com


0 FILE Untitled.ldr
0 Untitled
0 Name: Untitled.ldr
0 Author: Tony Hafner <www.hafhead.com>
0 Unofficial Model
0 ROTATION CENTER 0 0 0 1 "Custom"
0 ROTATION CONFIG 0 0
1 19 0 0 0 1 0 0 0 1 0 0 0 1 4733.DAT
1 19 0 24 0 1 0 0 0 1 0 0 0 1 3005.DAT
1 19 0 -24 0 1 0 0 0 1 0 0 0 1 3005.DAT
1 0 -10 0 0 1 0 0 0 1 0 0 0 1 side.ldr
1 0 10 0 0 -1 0 0 0 1 0 0 0 -1 side.ldr
0
0 FILE side.ldr
0 side
0 Name: side.ldr
0 Author: Tony Hafner <www.hafhead.com>
0 Unofficial Model
0 ROTATION CENTER 0 0 0 1 "Custom"
0 ROTATION CONFIG 0 0
1 36 -24 10 0 0 1 0 -1 0 0 0 0 1 4588.DAT
0
0



Message has 1 Reply:
  Re: Color problem- is this a bug in L3P?
 
(...) L3P has a bug with part colors when there is a single part in a sub-file. In this case, you need to ask yourself why you have this case. It seems overkill to have side.ldr with just one part in it. None the less, it is a bug in L3P. (...) LPub (...) (22 years ago, 25-Mar-03, to lugnet.cad.dat.models, lugnet.cad.ray)

4 Messages in This Thread:


Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

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