Jean-Sébastien Guay wrote:
So the answer IMHO would be that in any case, you will want to try and
build a good scene graph (both for culling performance and
intersection performance). Whether you want to make a global kd-tree
for the whole scene will depend on how dynamic your scene is, and if
you can take the time to implement it so that only parts that change
In my case I am reading OpenFlight files produced by a third party, so I
don't have much control over whether it was constructed efficiently or
not. Since the terrain will be static, my thought was to build a mostly
static KdTree of scene graph nodes separate from the normal rendering
state graph and to be used for culling and intersection tests. I
believe a number of other 3D engines use this approach. However my
question was really whether something like this already existed in OSG,
to which the answer is no.
This is not implemented currently. It's another one of those little
projects I'd like to do eventually. It's what some publications call
"test-intersection" vs "find-intersection".
I do need this feature, so I will look into implementing it in
osgUtil::IntersectionVisitor. This should be as simple as setting a
flag, I think, and modifying the traversal to return as soon as an
intersection is found. I will let the list know how it goes.
Test-intersection: If all you want to know is if something intersects
(for example, for shadow tests in raytracing) some shortcuts can be
Find-intersection: If you really want to find all objects that
intersect (and potentially then sort by distance so you can get the
closest one) (for example, for the main rays in raytracing) then you'd
do it more or less the way it's done right now.
If you want to implement test-intersection, you could subclass
IntersectionVisitor/LineSegmentIntersector, or you could do it
directly in these classes as an option and then submit it to OSG. :-)
osg-users mailing list