Special:
|
[DAT] (requires LDraw-compatible viewer)
|
Subject:
|
RE: Problem with L3P
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Fri, 12 Mar 1999 10:16:13 GMT
|
Viewed:
|
876 times
|
| |
|
|
The Color7 is a "fallback" color. If no colors are defined in a model
(which then most likely is a part) POV would use a DEFAULT black
texture. I therefore used the grey (Color7) as LDraw does.
Normally this is not a problem since a model typically specifies colors
for all of its parts, and then it doesn't matter if the model object
itself is colored grey. The color settings (texture/material) for each
part overrides this. Exactly as for patterned parts, where a portion of
the part is not colored 16, but specific colors.
However, as Terry found out, it seems that there are some side effects.
I have investigated some scenarios:
First Terry's problem:
0 FILE test4073.dat
1 33 0 0 0 1 0 0 0 1 0 0 0 1 4073.dat
which L3P translates into:
#declare test4073_dot_dat = object {
object { _4073_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> material {
Color33 } }
}
object { test4073_dot_dat material { Color7 } }
As you have noticed, Color7 overrides Color33.
And changing "object" to "union" in the declaration of test4073_dot_dat
will solve the problem. However, you get a warning from POV: "Should
have at least 2 objects in csg".
But, suppose you have the following two files:
0 FILE test4073.dat
4 14 0 0 0 0 0 1 1 0 1 1 0 0
0 FILE te2_4073.dat
1 33 0 0 0 1 0 0 0 1 0 0 0 1 test4073.dat
1 1 0 0 1 1 0 0 0 1 0 0 0 1 test4073.dat
L3P translates this into:
#declare test4073_dot_dat = object {
mesh {
triangle { <0,0,0>, <0,0,1>, <1,0,1> }
triangle { <1,0,1>, <1,0,0>, <0,0,0> }
material { Color14 }
}
}
#declare te2_4073_dot_dat = union {
object { test4073_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,1> material {
Color33 } }
object { test4073_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> material {
Color1 } }
}
object { te2_4073_dot_dat material { Color7 } }
Here Color1 will override Color14, but Color33 will not. And changing
"object" to "union" in the declaration of test4073_dot_dat will NOT
have any effect!
Another example:
0 FILE test4073.dat
1 14 0 0 0 1 0 0 0 1 0 0 0 1 4073.dat
0 FILE te2_4073.dat
1 33 0 0 0 1 0 0 0 1 0 0 0 1 test4073.dat
1 1 0 0 1 1 0 0 0 1 0 0 0 1 test4073.dat
#declare _4073_dot_dat = union {
// Plate 1 x 1 Round
object { peghole_dot_dat matrix <1,0,0,0,2.5,0,0,0,1,0,3,0> }
object { _4_dash_4cyli_dot_dat matrix <6,0,0,0,5,0,0,0,6,0,3,0> }
object { _4_dash_4disc_dot_dat matrix <10,0,0,0,1,0,0,0,10,0,3,0> }
object { _4_dash_4cyli_dot_dat matrix <10,0,0,0,3,0,0,0,10,0,0,0> }
object { _4_dash_4disc_dot_dat matrix <10,0,0,0,1,0,0,0,10,0,0,0> }
object { stud_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> }
}
#declare test4073_dot_dat = union {
object { _4073_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> material {
Color14 } }
}
#declare te2_4073_dot_dat = union {
object { test4073_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> material {
Color33 } }
object { test4073_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,1> material {
Color1 } }
}
object { te2_4073_dot_dat material { Color7 } }
Here Color1 will override Color14, but Color33 will not! And changing
"object" to "union" in the declaration of test4073_dot_dat will render
both objects in Color14!
CONCLUSION:
===========
So it seems that there is a problem with parts that only has one POV
element and that element is colored. (Note that a part with many colored
quads translates into ONE mesh=one element).
The good news is that I don't think we have (or will get) any.
Unless we use hard-coloring of parts (e.g. chrome antenna),
which I generally find a bad idea.
So the problem will probably only arise when trying to render a
part in another color as Terry did.
There are two possible solutions to Terry's the problem:
1) I could use POV's #default directive in stead of Color7. However,
the #default directive only allows texture and not material (I
wonder why?), so this will not help Terry with his trans-blue.
2) I will add an -c<color> option to let you specify the default
drawing color. This also eliminates the need of the temporary file,
you created only to apply a color.
Expect 2) to appear in the forthcoming release.
/Lars
> -----Original Message-----
> From: legoverse@geocities.com [mailto:legoverse@geocities.com]
> Sent: 11. marts 1999 01:45
> To: lugnet.cad@lugnet.com
> Subject: Problem with L3P
>
>
> Lars,
>
> I have found what appears to be a flaw in L3P.
> When rendering a single piece, the renderings always come out
> in a grey (#7)
> color. (1)
>
> For instance, make a dat file containing only a single 4073
> 1x1 round stud.
> Color it 33 for trans-blue. Then process it with L3P.
>
> What seems to happen is that, when processing only a single
> piece, L3P writes
> the #Declare line as equaling an "object" using the proper 33
> color code.
> But then Object line calls the declared item and gives it a
> default color of
> #7.
>
> When processing _more_ than one piece, L2P writes the
> #Declare line as a
> "Union". Which works properly.
>
> Changing the single part #Declare to = union fixes the problem.
> But is it proper to have a single item declared a union?
>
> ---------
> #declare 1x1round_dot_dat = object {
> object { _4073_dot_dat matrix <snip> matrix <snip> #if
> (version >= 3.1)
> material #else texture #end { Color33 } }
> }
>
> object { 1x1round_dot_dat #if (version >= 3.1) material #else
> texture #end {
> Color7 } }
> ----------
> Changing that first line like so to fix:
> #declare 1x1round_dot_dat = union {
>
>
> -- Terry K --
> (1) Why the heck am I rendering single pieces? :-)
>
|
|
Message has 1 Reply:
 | | Re: Problem with L3P
|
| (...) True. But warning or no, changing it to "union" still works. :-) (...) Which is going to happen eventually. Does it make a difference if the actual part is _not_ hard-colored? As in, the chrome colored part is a "shortcut" that calls the (...) (25 years ago, 13-Mar-99, to lugnet.cad)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
