Ideas on RTRT and PhysX

Mirror · Post by **Mirror** » Sat Feb 21, 2009 3:13 pm

Hi. This will probably be a kinda long post as i don't have the time to write a short one.

As ( some of ) you may know ( Blindside, sio2 and others notably ) ray tracing is about tracing light from the eye, through each pixel of the screen to each object of the scene, then dividing the initial ray into a refractive, reflective and a shadow one in case the ray intersects with an object and then recursing for the two first types of rays. As far as i know - i never coded a raytracer - one of the most CPU-intensive parts ( if not the most intensive ) of the raytracing algorithm is the part where we have to find the intersection of the rays with objects of the scene.

Recently i got access to a computer with a physx capable graphics card and i downloaded the physx runtime and some demos from nvidia, mainly intrigued by JP's irrphys project. One of the most notable physics engines examples is the one where we shoot a ball and it bounces on the walls and so on.

At some point, watching in some kind of a trance the physics demos it suddenly dawned to me - thus connecting the seemingly unrelated first two paragraphs of my post - that we could possibly use a physics engine in order to find the intersections of the rays with the scene's objects, something which is already done by the physics engine ( remember the ball bouncing on the walls of our little physics engine app ). I must say at this point that till now i've never used ( because it didn't either thrill me and i never had the intention to make a race game or an FPS ) a physics engine, so I don't know how exactly the points where the ball bounces are found by the physics engines ( physx in our case ), but i guess it's kinda automatic. Some of you guys who are involved with physics engines ( JP can you hear me ? ) could possibly shed some light on this.

So the point is that we could possibly offload all the computations for the intersection of the rays with the objects through PhysX to the GPU ( geforce8 and up ), thus increasing the algorithm's efficiency and hence accelerating the pace in the race for some kind of real-time ray-tracing.

In case you find this idea interesting, I'd love to hear some input about its feasibility from you guys, specially from the devs around here who are involved in some way or another with raytracing.

night_hawk · Post by **night_hawk** » Sat Feb 21, 2009 7:51 pm

There is / was a PhysX example that had shadows via raytracing.

BlindSide · Post by **BlindSide** » Sun Feb 22, 2009 3:19 am

It would be faster/less messy to just ray trace yourself using CUDA or SSE. Ray tracing doesn't take alot of lines to write, and the only thing PhysX will give you is a triangle intersection equation and an acceleration structure. The last part may take a bit more time when doing it yourself but it's alot more fun and rewarding writing your own KDTree/BVH.

Goto ompf.org for more info on all this.

Cheers

agi_shi · Post by **agi_shi** » Mon Feb 23, 2009 1:32 am

I did this with Newton Game Dynamics a while ago:

Crappy 2 minute AO:

Took 2 days to write the full thing, multithreaded and all. Then you get free physics.

BlindSide · Post by **BlindSide** » Mon Feb 23, 2009 3:20 am

Hey not bad, even for 2 minutes that AO looks pretty good.

Still RTRT stands for real time ray tracing, it would be pretty difficult to get these kinda results relying on a physics engine to do all the low-down work, much faster to write and optimize it yourself.

Even if a physics engine could get close it would never be as fast because I am sure they wouldn't employ techniques such as the SAH greedy heuristic which optimizes KDTrees/BVHs to have the most optimal splits. These kinds of optimization are usually ray tracing specific so you're gonna have to do all this yourself if you want the best performance.

Cheers

JP · Post by JP » Mon Feb 23, 2009 8:43 am

I may well side with the folks saying that a physics engine might not be so much help... But that's just because I reckon they know more about it than me!

If you wanted to look into it with IrrPhysx then there's a ray tracing example provided which may be of some use. I think there may be some more results you can get back off it which I haven't wrapped in yet, you could check the necessary Physx dox to see what else might be available.

christianclavet · Post by **christianclavet** » Sat Apr 18, 2009 1:41 am

JP if PHYSX is used with IRRPHYSX and the user as a NVIDIA card with support for PHYSX acceleration, I think it could be worthwhile. Would surely beat a lot of CPU calculations with the video cards available here today.

An IRRlicht application could be used to render in batch process, series of frames from a 3D application (The application would have to bake its scene in a mesh then save it for the application) in batch process. There is surely a use and need for this kind of applications.

Can we use that technique to render picture bigger than the screen buffer? (Ex: 4K resolution for film)