| Christian Langis 2004-02-27, 7:29 pm |
| Hi there.
I been writing a VRML app and I'm testing it right now with the NIST
test suite (http://xsun.sdct.itl.nist.gov/~mkass/vts/html/vrml.html).
One of them is bugging me:
Shape {
appearance Appearance { material Material {}}
geometry Extrusion {
endCap FALSE
beginCap FALSE
crossSection [
1.00 0.00, 0.75 0.66, 0.50 0.87, 0.25 0.97, 0.00 1.00, -0.25 0.97,
-0.50 0.87, -0.75 0.66, -1.00 0.00, -0.75 -0.66, -0.50 -0.87, -0.25
-0.97, 0.25 -0.97, 0.50 -0.87, 0.75 -0.66, 1 0
]
spine [
0 -1 0,
0 -2 0,
0 0 0,
0 1 0, 0 2 0, 0 3 -1, 0 3 -2, 0 3 -3, 0 3 -4, 0 3 -5, 0 3 -6
]
solid FALSE
}
}
Nothing wrong for most of it. The cross-section defines a simple circle.
Together with the spine, they define an elbow tube. Problem with the
spine however, is its 1st 3 points. The spine goes down and then up "ON
ITSELF". As a result, according to the standard method of computing the
orientation of the cross section,
1st crossSection gets
SCP-Y axis (0,-1,0) SCP-Z axis (-1,0,0)
2nd crossSection gets
SCP-Y axis (0,+1,0) SCP-Z axis (-1,0,0)
3rd crossSection gets
SCP-Y axis (0,+1,0) SCP-Z axis (-1,0,0)
....
They all get the same SCP-Z axis since this is the result of the
cross-product 1st 3 non-colinear points of the spine (namely (0 1 0), (0
2 0) and (0 3 -1)) as the standard says:
"If the Z-axis of the first point is undefined (because the spine is
not closed and the first two spine segments are collinear) then the
Z-axis for the first spine point with a defined Z-axis is used."
The 1st SCP-Y axis is spine[1] - spine[0] -> (0 -2 0) - (0 -1 0)
The 2nd SCP-Y axis is spine[2] - spine[0] -> (0 0 0) - (0 -1 0)
....
Hence, it is clear that the SCP (or the orientation if you will) of the
1st cross-section is rotated 180degrees around the world X axis compared
to the next 2.
So, in a extrusion, if you have 2 succesive crossSections with one
oriented 180 degrees from the orientation of the other, what do you get?
You'd get the same as what Cosmo (see cosmo image) delivers. The quad
faces between the 1st and 2nd cross section, instead of being parallel
to the spine direction (the Y axis), they cross in diagonal from the X
side to the -X side. This is all consistent with the standard of VRML
V2.0. And it seems clear that there is a logical bug in the VRML file:
the 1st spine point not only is redundant but it also causes the viewer
to screw up one end of the otherwise 'open' tube (no cap).
What bugs me is that Cortona and Blaxxun do dectect this situation and
seem to remedy to it (see Cortona image).
The question is:
1-Does Cosmo respect correctly the standard?
2-How do Cortona and Blaxxun cope with this situation?
3-Should the author of a new browser do as Cosmo and enforce strict
compliance with the standard?
BTW, if you go at
http://xsun.sdct.itl.nist.gov/mkass...+Geometry+FALSE
and select number 7, you'll see that the test suite is not that clear
itself, the image of the bottom view is ambiguous.
Thanks
PLS reply by Email (remove the NOSPAM from the address)
|