Probably should take a look at how osgUtil::IntersectVisitor does this,
as it has to traverse the low-level geometry data in order to figure out
where the actual intersect point is.
Don
Bill Prendergast wrote:
Hopefully this won't expose my lack of knowledge of OGL too much... ;-)
I'm walking the scene graph, post-load, post-optimize and am looking at
the stripped triangles (preparing to do some area and normal calcs).
Lazily, I made the assumption that they are all DrawElement types and
was just using the PrimitiveSet->getDataPointer() to grab the indices
(and applying the 012 / 021 ordering per the even/odd-ness of the triangle).
Then I crashed because getDataPointer() returned NULL... turns out that
I had stumbled across a Tri-Strip with two triangles that was a DrawArray
type, not a DrawElement type.
From what I can see, DrawArray implies that the vertices are sequentially
ordered, instead of coming from the index array.
If someone doesn't mind a handful of osg-newbie questions (my main
question coming first)...
1) When the optimizer is taking thousands of individual triangles and
merging them into Tri-Strips, what would cause it to decide that a
small (2 to 4 triangle) strip is better represented as a DrawArray
instead of a DrawElement?
2) Could this be indicative of a problem in the original model? (sorry,
I have yet to yank the triangle and see if it's valid or not - I'm thinking
ahead that perhaps a degenerate triangle might be done as a DrawArray).
3) It threw me that Geometry->getVertexArray() worked, but
Geometry->getVertexIndices() (appears to) always return NULL.
So, primitiveSet->getDataPointer() appeared to do the deal, but
(now, obviously) only for DrawElement types.
I guess my question here is... wouldn't it be better to genericize
this so that you could pull the indices from getVertexIndices() for
ANY type of primitive, resulting in (perhaps) a little more up-front
work, but less switch( )ing later on?
(Yeah, I know... "better" is a funny word ;-)
4) I'm pretty familiar with VegaPrime's optimizer... knowing that it
will create a large number of degenerate triangles in order to
make very long strips.
Offhand, will osg's optimizer do this? It looks like it tends to
generate many smaller strips instead... is this observation right?
5) Generally, what would cause the optimizer to end a strip and
start a new one? Different attributes, I would guess, but also
is it that it just runs out of "free" triangles to strip and will not
make degenerate bridges to keep adding to the strip?
To be more concise... will osg's optimizer create degenerate
triangle bridges at all?
6) When pulling triangles out of a DrawArray-type Tri-Strip, what
is the correct method for indexing the vertices? For example,
If primitiveSet->index( ) returned:
200 201 202 203
Does that imply two triangles 200,201,202 and 201,203,202?
In other words, can I treat the sequential series from index( )
the same way I'm treating the indices from DrawElement types?
I'll stop here... I've laid out quite the little essay. Thanks in advance
for any insight.
Regards,
Bill Prendergast
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
--
"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb contesting the vote."
- Benjamin Franklin
+----------------------------------------+
| Don Tidrow |
| Visualization Software Engineer |
| SAIC |
| ph: 703-253-1094 |
+----------------------------------------+
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
