[osg-users] Searcing for raytracer implementation based on OSG
Tobias Münch
Does anybody has developed a raytracer based on OSG or OpenGL which is free to use on other applications? It is important for me that no changes are necessary to the OSG-framework like the raytracer of Amit Ben-David, who modified the osg:Vec3f class. I need it for my thesis and unfortunately I have not enough time to code one by my own.
best regards, Tobias
p.s.: The source of Ben-Davids raytracer: http://www.cs.technion.ac.il/~cs234326/projects/GLSLRayTracer/main.htm
Adrian Egli
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.
and the once we have a fast internal data representation, we may are really close to render the scene no longer as face rendering also ray casted, ray traced parts would be an futur options. what would be really greate. May we will get small parts raytraced, others not.
what are others thinking about this topic.
/Adegli
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
********************************************
Adrian Egli
Tobias Münch
If I get you right, you think that the OSG data representation is not optimized for use within a raytracer application. So it will be possible to code a raytracer with OSG but results won't be very efficient and powerful?
regards, Tobias
Adrian Egli
exactly, OSG is develeped w.r.t high performance surface rendering (OpenGL).
/adegli
Paul Melis
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
Adrian Egli
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
--
********************************************
Adrian Egli
Jean-Sébastien Guay
> Does anybody has developed a raytracer based on OSG or OpenGL which is free
> to use on other applications? It is important for me that no changes are
> necessary to the OSG-framework like the raytracer of Amit Ben-David, who
> modified the osg:Vec3f class. I need it for my thesis and unfortunately I
> have not enough time to code one by my own.
I have done some work similar to what you need, but it is not in a
state where I could release it (it's part of the software for my own
thesis, and could not easily be separated out...). I can tell you
though that it is pretty easy to do given OSG's great design.
Sorry I can't help more...
Let us know how your thesis work goes...
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@polymtl.ca
http://whitestar02.webhop.org/
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Jean-Sébastien Guay
> 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.
I agree, something like that would be great. If the goal is just to be
able to take a raytraced screenshot, a kd-tree might be workable, but
if we want to try and get some kind of realtime or quasi-realtime
raytracing going, we'll need something we can rebuild faster than a
kd-tree, or perhaps a kd-tree for anything tagged as STATIC and a BVH
for anything tagged as DYNAMIC...
I've done some raytracing with OSG but I don't have time to implement
anything like that - my thesis is due "as soon as possible" :-) So I
just used osgUtil::LineSegmentIntersector out of the box, and as you
might guess the speed is not that great. In a simple scene I get only
about 20k ray/triangle intersections per second.
If there was real interest in something like this, I would be glad to
help with the implementation, but as I see it, it will only be used in
very few cases...
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@polymtl.ca
http://whitestar02.webhop.org/
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Adrian Egli
as starting point we should think about only static scenes, not morphable objects. And for speed up line intersection tests
we may can append a kd-tree or at least a spatial datastructure. i am sure that then your ray tracer would be faster than 20k.
Event for motion model using intersection tests (terrain, model, ...) becomes faster, i had once a model with 100k triangles
in the same geometry and the osg fps drops unter a usable limit. then i start looking for the issue and i believe now, that this was
of the linear in time intersection test. after removing the intersection test, the frame was greate. the bootle neck was located.
/adegli
--
********************************************
Adrian Egli
Jean-Sébastien Guay
> as starting point we should think about only static scenes, not morphable
> objects.
Yes, of course that would be a good start. Unfortunately I didn't have
time to implement a kd-tree over OSG.
We'll see what the future brings... Many thing will change once I hand
in my thesis. :-)
Abe Stephens
I'm not aware of any open source interactive ray tracers that
vivaciously support third-party scene graphs like OSG.
OpenRT (not open source) has been demoed at the Mercury booth @
siggraph running off a scene graph (possibly OpenInventor (?)). Razor
(not open source) is an IRT system from UT Austin which is tightly
integrated with its own scene graph (supports collada). We've had
some traffic on the Manta (open source) mailing list about scene
graph integration. The projects were all outside of Utah so I'm not
sure if they targeted a standard tool like OSG.
Abe
On Oct 2, 2007, at 4:26 AM, osg-users-
req...@lists.openscenegraph.org wrote:
> Message: 24
> Date: Tue, 2 Oct 2007 12:25:58 +0200
> From: " Tobias M?nch " <muench...@googlemail.com>
> Subject: Re: [osg-users] Searcing for raytracer implementation based
> on OSG
> To: "OpenSceneGraph Users" <osg-...@lists.openscenegraph.org>
> Message-ID:
> <f90040970710020325s44d...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello Adrian
>
> If I get you right, you think that the OSG data representation is not
> optimized for use within a raytracer application. So it will be
> possible to
> code a raytracer with OSG but results won't be very efficient and
> powerful?
>
> regards, Tobias
>
> On 10/2/07, Adrian Egli <3dh...@gmail.com> wrote:
>>
>> Hi Tobias,
>>
>> 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.
>>
>> and the once we have a fast internal data representation, we may are
>> really close to render the scene no longer as face rendering also ray
>> casted, ray traced parts would be an futur options. what would be
>> really
>> greate. May we will get small parts raytraced, others not.
>>
>> what are others thinking about this topic.
>>
>> /Adegli
>>
>> 2007/10/2, Tobias M?nch <muench...@googlemail.com>:
>>>
>>> Hello to all OSG developers.
>>>
>>> Does anybody has developed a raytracer based on OSG or OpenGL
>>> which is
>>> free to use on other applications? It is important for me that no
>>> changes
>>> are necessary to the OSG-framework like the raytracer of Amit Ben-
>>> David, who
>>> modified the osg:Vec3f class. I need it for my thesis and
>>> unfortunately I
>>> have not enough time to code one by my own.
>>>
>>> best regards, Tobias
>>>
>>> p.s.: The source of Ben-Davids raytracer: http://
>>> www.cs.technion.ac.il/~cs234326/projects/GLSLRayTracer/main.htm
>>>
>>> <http://www.cs.technion.ac.il/%7Ecs234326/projects/GLSLRayTracer/
>>> main.htm>
>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> osg-...@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-
>>> openscenegraph.org
>>>
>>>
>>>
>>
>>
>> --
>> ********************************************
>> Adrian Egli
>> _______________________________________________
>> osg-users mailing list
>> osg-...@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-
>> openscenegraph.org
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.openscenegraph.org/pipermail/osg-users-
> openscenegraph.org/attachments/20071002/599a86e8/attachment.html
>
> ------------------------------
>
> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
>
>
> End of osg-users Digest, Vol 4, Issue 4
> ***************************************
Adrian Egli
there are many nice project and on going project for real time ray tracing. i would say in the future there will be many more, because
the ray tracing becomes faster and faster. The future will be a hybrid visualisation systems: GPU / CPU and also OpenGL / RayTracing.
Even for OSG it will become a challenge to follow such latest development and such latest ideas, but the core concept of all such systems are quite similar.
All systems needs a spatial data structure. In OSG the objects are organised in bounding sphere hierarchy. And unfortunately the
primitives are just in arrays, what is may fast for rendering but for intersection testing, tracing it's a known poor data organisation.
(Robert) What are you thinking about this topic, just as a short general idea. What danger do you see if we would implement a spatial hierarchic data structure (kd-tree) to replace the array based vertex, triangles storing. what can be a challenge or what would be quite hard to change, and where are unknown dangers w.r.t performance for face rendering (OpenGL) ?
/adegli
--
********************************************
Adrian Egli
Adrian Egli
just for your informations
i am working on a KD-Tree based line intersection test. First result are quite better, event for the cow object with 5804 and passed 1000.0 lines trought the object with 2 real intersection we have just to check against 33 triangles instead of all (5804).
B-Radius=6.35558
B-Center=0.776125,-0.43866,0
KD-Tree...[5804:1001]
5804:5804
TrianglesChecks=5804
Total Bench Time: 0.209096s
C:\Dokumente und Einstellungen\adegli>"C:\Dokumente und Einstellungen\adegli\Desktop\test\Release\Test.exe"
B-Radius=6.35558
B-Center=0.776125,-0.43866,0
KD-Tree...[5804:1001]
5804:5804
TrianglesChecks=33
Total Bench Time: 0.0879453s
C:\Dokumente und Einstellungen\adegli>
--
********************************************
Adrian Egli
Ulrich Hertlein
Quoting Adrian Egli <3dh...@gmail.com>:
> i am working on a KD-Tree based line intersection test. First result are
> quite better, event for the cow object with 5804 and passed 1000.0 lines
> trought the object with 2 real intersection we have just to check against 33
> triangles instead of all (5804).
>...
> TrianglesChecks=5804
> Total Bench Time: 0.209096s
>...
> TrianglesChecks=33
> Total Bench Time: 0.0879453s
Interesting stuff. I assume you're doing some initial pass to build the kd-tree?
If so, how long does that take and is the setup time included in the total time?
Thanks,
/ulrich
Adrian Egli
KD-Tree Build Time = 0.0550397s
Intersection Time = 0.0336411s <- KD Tree
Triangles Checks = 33
Intersection Time <osg> = 0.331938s <- OSG intersection visitor
Total Bench Time: 0.423215s
--
********************************************
Adrian Egli
Adrian Egli
KD-Tree Build Time = 0.078817s
+ Nodes = 3437
+ Leafs = 1719
Intersection Time = 2.00325s
Triangles Checks = 186
Intersection Time <osg> = 27.5296s
Total Bench Time: 29.6118s
How and where should i implement this feature to test with normal OSG rendering. Vertex Array change to complex objects ?
_/adegli
--
********************************************
Adrian Egli
Jean-Sébastien Guay
> KD-Tree...[5804:100000]
> KD-Tree Build Time = 0.078817s
> + Nodes = 3437
> + Leafs = 1719
> Intersection Time = 2.00325s
> Triangles Checks = 186
> Intersection Time <osg> = 27.5296s
> Total Bench Time: 29.6118s
Your work is interesting, and I wonder if I could integrate it to what
I'm doing... Is your code fit for release?
Since Robert is taking a step back from OSG for a few weeks (see his
post near the end of last week), I don't think this will get
integrated to the core soon, but I would sure appreciate if I could
use it on my local version of OSG for my Masters work. It would make
my things run a lot faster!
At the very least, getting someone to use it would get you a first
review and therefore it would be a first step towards improving it for
later inclusion.
Thanks in advance, and good work,
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@polymtl.ca
http://whitestar02.webhop.org/
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Adrian Egli
i can send the code tommorrow, then you can review it, test it
and my we can improve a new boosting algorthime for next
generation of OSG. How would look like your timetable, do you
feel like having some time left to work on the osg integration or
do you just like finish the master work?
what fps you have at the moment, how many tri-ray intersections
you have to calculate for a default scene?
/adegli
--
********************************************
Adrian Egli
Joachim E. Vollrath
Everyone's talking about optimizations, kD-Trees and stuff...
Does anyone at all have a raytracer that supports everything OSG is able
to model/represent?
I'm talking about multitexturing, terrains, shaders, support for huge
scenes, and all the rest...
I mean, there's absolutely NO POINT in raytracing if you can't reproduce
the exact result (plus global illumination, that is) OSG delivers
natively with OpenGL rasterization!
Personally, I think interfacing to a different rendering backend might
be more promising.
Maybe a translation from the OSG scene description language to Renderman
or PovRay might do the job...
> ------------------------------------------------------------------------
>
> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Joachim E. Vollrath
University of Stuttgart
Institute for Visualization and Interactive Systems (VIS)
web: http://www.vis.uni-stuttgart.de/~vollrajm/
mail: voll...@vis.uni-stuttgart.de
phone: 49.711.7816.403
fax: 49.711.7816.340
german postal address:
Dipl. Inf. Joachim E. Vollrath
Universitaet Stuttgart, Institutsverbund Informatik
Institut fuer Visualisierung und Interaktive Systeme
Universitaetstrasse 38
70569 Stuttgart
GERMANY
Adrian Egli
i agree completely with the your point of view. but one important thing is, and only this part i am working on
is the fact that we haven't an accelerated line intersection test implemented for triangle represented topology. $
if we make use of the drive manipulator, we can drop in ver bad frame rates, and this isn't only a question of the rendering pipeline,
if we have to check against collisions and so on, and if we use the line intersection test based on vertex array,
which is the same as the rendering vertex are, then for a hudge amount of triangles we get really poor fps.
and if we can speed up this intersection, may we will be able to boost many osg based applications, and this
would be really interesting for many others in the community.
/adegli
--
********************************************
Adrian Egli
Joachim E. Vollrath
ok, I agree.
You said you built a kD-Tree on top of cow.osg. What exactly are you
doing with the vertex/triangle arrays then?
How much overhead in terms of memory does this produce? Would this
really scale for large scenes?
regards,
Joachim
Adrian Egli wrote:
> Hi Joachim,
>
> i agree completely with the your point of view. but one important thing is,
> and only this part i am working on
> is the fact that we haven't an accelerated line intersection test
> implemented for triangle represented topology. $
> if we make use of the drive manipulator, we can drop in ver bad frame rates,
> and this isn't only a question of the rendering pipeline,
> if we have to check against collisions and so on, and if we use the line
> intersection test based on vertex array,
> which is the same as the rendering vertex are, then for a hudge amount of
> triangles we get really poor fps.
> and if we can speed up this intersection, may we will be able to boost many
> osg based applications, and this
> would be really interesting for many others in the community.
>
> /adegli
>
Adrian Egli
at the moment it's only a quick and dirty evaluation prototypic implementation, of course i have a huge overhead, i like to replace for triangles
mesh the vertex array by a kd-tree in the osg core implementation. may i get time tomorrow to doing depther tests and some may i will be able
work out a first version of such a replacement in the osg core.
i guess if i will integrate it right in osg core the overhead will be not really huge, but i don't yet know it exactly
/adegli
Hi Adrian,
--
********************************************
Adrian Egli
Joachim E. Vollrath
possibly a stupid question:
if you do that, wouldn't you break the vertex arrays that are needed to
efficiently upload the geometry to the graphics card?
> Hi Joachim,
>
> at the moment it's only a quick and dirty evaluation prototypic
> implementation, of course i have a huge overhead, i like to replace for
> triangles
> mesh the vertex array by a kd-tree in the osg core implementation. may i get
> time tomorrow to doing depther tests and some may i will be able
> work out a first version of such a replacement in the osg core.
>
> i guess if i will integrate it right in osg core the overhead will be not
> really huge, but i don't yet know it exactly
>
> /adegli
>
Adrian Egli
isn't at all a stupid question, of course i have to care about this, but i still thought about this issue,
may there a two possiblity, first i store the data still in a array and just refere to them from kd-nodes,
or a link the kd-nodes, i we assume that only triangles are stored in the leaves, then may we link juste the leaves.
(a stupid idea: may we can "link them to a ring", then may we can order them in depth, may not. i have to think about this,
but i we have a strategy to walk through depth sorted you will see a next application of kd-tree (heuristically depth sorted) )
/adegli
Hi Adrian,
--
********************************************
Adrian Egli
Jean-Sébastien Guay
> i can send the code tommorrow, then you can review it, test it
> and my we can improve a new boosting algorthime for next
> generation of OSG.
That would be great. In which timezome are you? I am in GMT-5, Eastern
Canada/USA timezone.
> How would look like your timetable, do you
> feel like having some time left to work on the osg integration or
> do you just like finish the master work?
Honestly, I am getting close to finishing my Masters (still maybe one
or two weeks coding and then I'll finish writing my thesis) because I
will probably start working soon. Also, since the goal of my Masters
is not to get something really fast, but to see if I can prove my
hypotheses, any acceleration of the intersection testing will be an
added bonus, but not essential.
So what I'm thinking is that I'll test out your changes, see if they
work well. If I have trouble I'll have to evaluate if I have the time
to investigate now or just go on without it and work on it after my
Masters is done.
That being said, I'm very hopeful, because right now it's really
painfully slow! :-)
> what fps you have at the moment, how many tri-ray intersections
> you have to calculate for a default scene?
I currently only do intersection tests as a preprocess, so the fps
does not depend on the intersection testing. In one case I have a
scene where I need to do about 4 million intersection tests as a
preprocess, and this takes about 200 seconds (a little over 3 minutes,
or about 20000 intersections per second). Of course, the
IntersectionVisitor uses the bounding sphere/box hierarchy to avoid
doing ray/tri tests when they are sure to be negative, so it is not
20000 ray/tri intersections per second. But that gives you an idea of
my current situation.
For some upcoming experiments I expect I will have to do much more
intersections (up to about 100 million) and I will soon integrate some
intersection testing at runtime (not as a preprocess, but decoupled
from visualization) so the added speed you speak of will _really_ be
appreciated!
Thanks in advance, I look forward to trying out your changes
Jean-Sébastien Guay
> I mean, there's absolutely NO POINT in raytracing if you can't reproduce
> the exact result (plus global illumination, that is) OSG delivers
> natively with OpenGL rasterization!
That depends on what you're trying to achieve... In my case, I am just
trying to precompute some shadows (and other things) so I can just use
simple intersection tests and do the rest of the rendering with the
normal OpenGL pipeline. I don't need to reproduce everything, but I
agree that's not a complete raytracer.
> Personally, I think interfacing to a different rendering backend might
> be more promising.
In the beginning of my project I tried to create an interface between
OSG and yafaray (the next generation of yafray, Blender's integrated
raytracer). The problem was propagating changes in the OSG scene graph
to yafaray's internal data structures. yafaray was not created for
this purpose, so for example it does not store transformation
matrices, just the raw vertices with transformations baked in. So it
would have implied either adding transformation matrices to yafaray
(which the author did not agree on), or re-transforming all the
vertices each time (which would be slow).
That's just an example, the end result is that eevn though it would
have been cool, I decided I did not need a complete raytracer
integration. So I settled on just using intersection testing and doing
the rest myself.
> Maybe a translation from the OSG scene description language to Renderman
> or PovRay might do the job...
That would do for raytracing static scenes, but what would be even
better would be to integrate a raytracer into OSG so that it can track
the changes to the scene graph and work on the same scene as the
realtime portion, as described above.
We're not there yet, but I think Adrian's changes are a step in the
right direction.
Once I finish my Masters, I hope I will be able to help on this. There
have been lots of publications lately on developing so-called realtime
raytracers, and if OSG can go in that direction (in addition to being
the great scenegraph that it is), we could give an engine like OpenRT
[1], which is not Open Source despite its name, a run for its money
(so to speak). Imagine, getting a realtime engine like Direct3D but
cross-platform, and a realtime raytracer like OpenRT but Open
Source... Taht would kick serious arse. :-)
We'll see what the future holds...
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@polymtl.ca
http://whitestar02.webhop.org/
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Jean-Sébastien Guay
> I currently only do intersection tests as a preprocess, so the fps
> does not depend on the intersection testing. In one case I have a
> scene where I need to do about 4 million intersection tests as a
> preprocess, and this takes about 200 seconds (a little over 3 minutes,
> or about 20000 intersections per second). Of course, the
> IntersectionVisitor uses the bounding sphere/box hierarchy to avoid
> doing ray/tri tests when they are sure to be negative, so it is not
> 20000 ray/tri intersections per second. But that gives you an idea of
> my current situation.
I just tested the same code on a Linux machine I have at school, and
the same scene ran at over 200000 (200k) samples per second instead of
20k... I have no idea what the difference is, I'm investigating, but
the Windows and Linux machines have similar CPU and memory, and both
are release builds, so I did not expect such a difference.
Jean-Sébastien Guay
> I just tested the same code on a Linux machine I have at school, and
> the same scene ran at over 200000 (200k) samples per second instead of
> 20k... I have no idea what the difference is, I'm investigating, but
> the Windows and Linux machines have similar CPU and memory, and both
> are release builds, so I did not expect such a difference.
Mystery solved. I was getting 200k intersections per second but with
bad results. Turns out that it was a bug that only showed up on Linux,
where the localToWorld matrix was not computed correctly. So now that
I fixed that, I'm getting more reasonable results (45k samples per
second, still over 2 times what I get on Widnows, but much slower than
I'd like obviously).
I look forward to trying out your kd-tree. :-)
Adrian Egli
i did a really first implementation of RayTracing with OSG to improve how fast my kdTree intersection test is. Check out the kdTree.tar and test it. (Are there someone who has time to integrate it into OSG core for boosting the Intersection Visitor ? )
/adegli
KD-Tree...[23348 Triangles:20 rays]
KD-Tree Build Time = 0.224797s
******** TEST 1 **** (KDTree / OSG Intersection Test)
Intersection Time = 0.000168s
Rays = 1
Nodes Checks = 79
Bounding Checks = 122
Triangles Checks = 49
Linehits = 6
Intersection Time <osg> = 0.018305s
Linehits = 6
SpeedUp = 108.958 (FACTOR !, 20 rays)
******* TEST 2 *****
Ray Trace Time = 2.97638s
Rays = 787307 (264K Rays/s)
Nodes Checks = 24939199
Bounding Checks = 49512447
Triangles Checks = 16703960
Viewer...
--
********************************************
Adrian Egli
Adrian Egli
have a look at this simple test i am working on.
/adegli
--
********************************************
Adrian Egli