[osg-users] Searcing for raytracer implementation based on OSG

Paul Melis paul at science.uva.nl
Tue Oct 2 04:59:40 PDT 2007

On 10/2/07, *Adrian Egli* <3dhelp at gmail.com <mailto:3dhelp at gmail.com>> 

>     Greate would be to get a RayTracer attached to the OSG scene. With
>     option to trace or not. Normally OSG won't trace, but if we like
>     to get high quality screens, we can just turn on the tracing. But
>     i was thinking about this still more then once. What we should get
>     or what i like to integrate as soon as i have some hours to
>     analyse the osg core, we should store the triangles, trianglesfan,
>     ... (GL geometries) in a accelerated spatial data structure, best
>     kd-Tree like data organisation. Even the intersection test could
>     be boosted, also futures animations, collision checks and so on,
>     boosting of depth sorting for transparency pre triangles should
>     become possible.  Also haptic-rendering could be an option for
>     future application. This integration would be an essential topic.
>     I am not yet sure how we should change the osg internal data
>     structure, at the moment we store vertices in simple arrays. I
>     feel like to remap them into an kd-tree. then the whole scenegraph
>     is organised in a spatial data structure.
If you're going this way also consider the bounding-volume hierarchy as 
an option for the spatial data structure. It has far more favorable 
storage characteristics, as it can be implemented with a list of objects 
(triangles, quads) in the tree in a certain sorted order. Because of 
this it might even provide for a way to use the same data layout both 
for ray intersection and normal OSG operation.
It also has very fast construction times (which is good for dynamic 
scenes), although it's real-time performance is only beginning to get 
interesting these days. See http://graphics.uni-ulm.de/BIH.pdf if you're 
interested in more details.


More information about the osg-users mailing list