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

[Adrian Egli]

Hi Paul,

i know from this data structures. or we can have a look at
http://ompf.org or arauna project http://rt07.raytracing.nl presentation
(Real-time Ray Tracing through the Eyes of a Game Developer)

/adegli





2007/10/2, Paul Melis <paul at science.uva.nl>:
>
> On 10/2/07, *Adrian Egli* <3dhelp at gmail.com <mailto:3dhelp at gmail.com>>
> 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
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
********************************************
Adrian Egli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20071002/a9d4c0be/attachment.html