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
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!
GPU Raytracing Demo 2: Cornell Box
Re: GPU Raytracing Demo 2: Cornell Box
Looks great. Simulating boxes with raytracing shouldn't be that hard either...
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: GPU Raytracing Demo 2: Cornell Box
^ 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
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
Re: GPU Raytracing Demo 2: Cornell Box
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.
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
Re: GPU Raytracing Demo 2: Cornell Box
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
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
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: GPU Raytracing Demo 2: Cornell Box
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.
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.
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.
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
Re: GPU Raytracing Demo 2: Cornell Box
triangles for raytracing are a really bad choice
Sparse Voxel Octrees/KdTrees
++ waiting for the GI, sio2
Sparse Voxel Octrees/KdTrees
++ waiting for the GI, sio2
Re: GPU Raytracing Demo 2: Cornell Box
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.devsh wrote:triangles for raytracing are a really bad choice
Sparse Voxel Octrees/KdTrees
++ waiting for the GI, sio2
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781