Hi Paul, <br><br>i know from this data structures. or we can have a look at <br><a href="http://ompf.org">http://ompf.org</a> or arauna project <a href="http://rt07.raytracing.nl">http://rt07.raytracing.nl</a> presentation (Real-time Ray Tracing through the Eyes of a Game Developer)
<br><br>/adegli <br><br><br><br><br><br><div><span class="gmail_quote">2007/10/2, Paul Melis <<a href="mailto:paul@science.uva.nl">paul@science.uva.nl</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 10/2/07, *Adrian Egli* <<a href="mailto:3dhelp@gmail.com">3dhelp@gmail.com</a> <mailto:<a href="mailto:3dhelp@gmail.com">3dhelp@gmail.com</a>>><br>wrote:<br><br>>     Greate would be to get a RayTracer attached to the OSG scene. With
<br>>     option to trace or not. Normally OSG won't trace, but if we like<br>>     to get high quality screens, we can just turn on the tracing. But<br>>     i was thinking about this still more then once. What we should get
<br>>     or what i like to integrate as soon as i have some hours to<br>>     analyse the osg core, we should store the triangles, trianglesfan,<br>>     ... (GL geometries) in a accelerated spatial data structure, best
<br>>     kd-Tree like data organisation. Even the intersection test could<br>>     be boosted, also futures animations, collision checks and so on,<br>>     boosting of depth sorting for transparency pre triangles should
<br>>     become possible.  Also haptic-rendering could be an option for<br>>     future application. This integration would be an essential topic.<br>><br>>     I am not yet sure how we should change the osg internal data
<br>>     structure, at the moment we store vertices in simple arrays. I<br>>     feel like to remap them into an kd-tree. then the whole scenegraph<br>>     is organised in a spatial data structure.<br>><br>If you're going this way also consider the bounding-volume hierarchy as
<br>an option for the spatial data structure. It has far more favorable<br>storage characteristics, as it can be implemented with a list of objects<br>(triangles, quads) in the tree in a certain sorted order. Because of<br>
this it might even provide for a way to use the same data layout both<br>for ray intersection and normal OSG operation.<br>It also has very fast construction times (which is good for dynamic<br>scenes), although it's real-time performance is only beginning to get
<br>interesting these days. See <a href="http://graphics.uni-ulm.de/BIH.pdf">http://graphics.uni-ulm.de/BIH.pdf</a> if you're<br>interested in more details.<br><br>Paul<br>_______________________________________________
<br>osg-users mailing list<br><a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br><a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
</a><br></blockquote></div><br><br clear="all"><br>-- <br>********************************************<br>Adrian Egli