Page 1 of 1

GPU Raytracing Demo 2: Cornell Box

Posted: Fri Oct 05, 2012 5:48 pm
by sio2
Another ray tracing demo, this time the scene is made up of quads (triangles) and is based on the Cornell Box. Should run on DX10 hardware (fingers crossed) as well as DX11 hardware. FXAA anti-aliasing really works well in this app.

Demo zip here (727kb)
http://sio2.g0dsoft.com/demos/gpuraytrace2.zip

Image

Note: This is another testbed as I move toward more sophisticated renderers. There are many improvements I can make but the main aim with this app was getting triangles uploaded to the raytrace shader and getting the ray-triangle intersections working correctly. Just simple lighting and shadows for now!

Re: GPU Raytracing Demo 2: Cornell Box

Posted: Sat Oct 06, 2012 8:35 am
by Mel
Looks great. Simulating boxes with raytracing shouldn't be that hard either...

Re: GPU Raytracing Demo 2: Cornell Box

Posted: Mon Oct 08, 2012 5:06 pm
by fmx
^ he jumped straight to triangle primitives instead of boxes because tris are more flexible and can represent all other primitive types anyway

I've only gone as far as creating offline raytracer for baking AO and radiosity, so I can appreciate the work involved in creating a raytracer to work realtime on GPU
good stuff 8)

Re: GPU Raytracing Demo 2: Cornell Box

Posted: Thu Oct 11, 2012 4:58 pm
by sio2
Don't forget that each of the three "boxes" have only 5 sides each. Plus the large one is "inside-out". Ray-box intersections would have to account for that. :wink:

Re: GPU Raytracing Demo 2: Cornell Box

Posted: Fri Oct 12, 2012 12:40 am
by Mel
Triangles are good, but don't support for instance, boolean operations, as other raytraced primitives would allow.

A raytraced box would need a transformation matrix and 2 corners. An axis aligned box isn't hard to render, so, if you transformed all the rays to the local transformation of the box, the rays would be axis aligned with regard the box, and the effect would be the same, but the box could perform any kind of rotations, scalings and translations, and would still have shadows, reflections, refractions and any other type of raytraced effects without missing parts.

This same approach can be used to render other primitives, like cylinders, or capsules, And stretching the rays along the local transformation of an object would allow to render moving ellipsoids, cones and more complex figures, only using mathematical approaches, and totally perfect. The real drawback is that this would require an horde of matrix transformations IN THE PIXEL SHADER that could be very expensive for a real time application. Though i still remember an old raytrace demo and it performed all of this, and more... (volumetric fog, boolean operations, texture mapping, reflections, refractions....) And all in a PII @ 350 mhz So who knows?...

I found it! XD

http://www.youtube.com/watch?v=tCMo-bJQC8A

Re: GPU Raytracing Demo 2: Cornell Box

Posted: Fri Oct 12, 2012 3:24 pm
by sio2
Well, yes, I know there's lots of things that *could* be done. This was just a "simple" demo getting the basics up-and-running. 8)

Also this scene is based on the Cornell data. There is no front wall, so the main box has only five sides and is not a closed convex hull - any ray-box intersection test would need to know which side of the box is missing.

Re: GPU Raytracing Demo 2: Cornell Box

Posted: Thu Oct 18, 2012 7:20 pm
by devsh
triangles for raytracing are a really bad choice

Sparse Voxel Octrees/KdTrees

++ waiting for the GI, sio2

Re: GPU Raytracing Demo 2: Cornell Box

Posted: Sat Nov 10, 2012 12:56 am
by sio2
devsh wrote:triangles for raytracing are a really bad choice

Sparse Voxel Octrees/KdTrees

++ waiting for the GI, sio2
I just wanted to make a simple demo of ray-triangle intersection for my own R&D. Saying "triangles for raytracing are a really bad choice" in this context is completely moot. Just saying.