On 10/2/07, *Adrian Egli* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> 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. Paul _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
