Hi Jean-Sébastien,

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 need updating.
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".

Test-intersection: If all you want to know is if something intersects (for example, for shadow tests in raytracing) some shortcuts can be taken.

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. :-)
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.

osg-users mailing list

Reply via email to