GPU ray tracing in real time

Yes. One of the standard spacial partitioning schemes for Ray Tracers is a k-d tree which allows you to more quickly traverse space to find relevant triangles to test against. The main issue with this approach is that it works best for static scenes, since building the k-d tree can be time consuming and must be done every time a dynamic scene would change.

edit:

As to how to implement that traversal on the GPU, I'm not entirely sure but a quick google does turn up quite a few papers.

Yeah... k-d tree and its ways. Its whats keeping me awake at night.
Everything must be dynamic. There will be no static objects in my game engine.

I found this: https://developer.nvidia.com/optix
And i heard about GUBA
this thing here is using it: http://www.opengl.com.pl/adam27-projekty-c-opengl-t-raycer-silnik-3d/
( it has only demo, no source code )

It is using the spheres and one quad so i'm assuming, thats the reason why it is rendering 200 fps in my computer.
Havent tried that nvidia thing but just downloaded SDK, i have no idea how it is working and i think i'll be wasting my time learning this.

Perhaps i should just give up since computers are not ready for those things. Not even ready when my game engine is done. :/
The only demos of ray tracing in real time i find are with spheres.
Found one what was rendering that monkey's head model. It was really really slow.

Not sure if there is a way to render normal ( modern ) amount of triangles with 30-40fps with ray tracing.

Yeah... k-d tree and its ways. Its whats keeping me awake at night.
Everything must be dynamic. There will be no static objects in my game engine.

I found this: https://developer.nvidia.com/optix
And i heard about GUBA
this thing here is using it: http://www.opengl.com.pl/adam27-projekty-c-opengl-t-raycer-silnik-3d/
( it has only demo, no source code )

It is using the spheres and one quad so i'm assuming, thats the reason why it is rendering 200 fps in my computer.
Havent tried that nvidia thing but just downloaded SDK, i have no idea how it is working and i think i'll be wasting my time learning this.

Perhaps i should just give up since computers are not ready for those things. Not even ready when my game engine is done. :/
The only demos of ray tracing in real time i find are with spheres.
Found one what was rendering that monkey's head model. It was really really slow.

Not sure if there is a way to render normal ( modern ) amount of triangles with 30-40fps with ray tracing.

to write realtime ray tracing engine you need deep knowledge on the subject

(both algoritmic and how the gpu work) but this is perfectly doable on current consumer's hardware

here is example: http://brigade3.com/

You can look for Arauna 2 - another pathtracer

See my old engine source code http://mxadd.org/bin/RayCasterCode.rar

(binaries are on http://mxadd.org see projects section)

First read few books and papers, then prepare for year or so of hard work, and then you'll be able to write another pathtracer (unles you'll give up ;))

Here is a more practical aproach suitable for games:

http://directtovideo.wordpress.com/2013/05/07/real-time-ray-tracing/

Download the demo and see yourself - very impressive.

They used a simple nested grid instead complex space partitioning structures (kd tree, octree...)

There is also another technique not mentioned in you older thread, keywords 'Many Lods' or 'Microbuffer Rendering':

http://perso.telecom-paristech.fr/~boubek/papers/ManyLoDs/

It is about rendering many but small enviroment maps over the surfaces. (less sharp, but you can calculate diffuse interreflection as well)

I work on a similar technique currently. It's definitive realtime, but i don't know yet if i can get the sampling resolution high enough to please todays 'I want at least 4k textures' gamers :)

About 4 years ago I wrote a GPU based raytracer written in directx 9 and XNA. This was used to evaluate the possibility of using raytracing for secondary rays in a deferred renderer where the GBuffer was used to determine the primary rays. For the thesis I used it for just shadow rays from one directional light. The result was this:

https://www.youtube.com/watch?list=UUEKKcDZ4qxf4rXDOKTD3Ktg&feature=player_detailpage&v=vqrg0yxZtvM#t=67

The video has three passes, the first without shadows the second using a shadow buffer and the third with raytraced shadows, I've linked to the third pass.

As you can see the result was quite slow, down to around 5fps, not exactly realtime. Modern hardware should be able to cope with this better, I tested this on an nVidia 470x GPU.

I used a simple dynamically updated fixed grid size octree where each cell contained object references which held the transform and an offset which pointed into a large texture containing the vertex position of all the object types in the scene, for this test I used polygonal spheres and a tree model. As the spheres are polygonal they are equivalent to an object with around 1,000 triangles if I remember correctly. I deliberately avoided parametric spheres as I wanted the results to equate to using real game assets. Using a 2k texture you could store up to 4 million vertices. Most games at the time limited their vertex count to under 10k for hero assets.

The octree as well was passed through in texture form, I can't remember the exact implementation I used to assure multiple objects could inhabit the same cell. With modern GPGPU programming languages you should definitely use better data transfer formats but as I was limited at the time to directX 9 HLSL I worked with what I had.

Long story short it is possible, but it's not fast. You're essentially duplicating your scene description, one for rasterisation and one for raytracing. I really like the idea of using the GBuffer to feed into secondary rays but it just doesn't make much sense at the moment as the "fake" methods look better (I had to downsample before raytracing) and perform much much better.

The only demos of ray tracing in real time i find are with spheres.

Then render everything in spheres and do physics on spheres. I assume you are doing this for the sake of learning so it could be an interesting approach. It might save you some time too if you only have to work with a single, simple primitive shape.

Probably not a practical approach if you are intending to make something comparable to other games though. But it would be different.

Generally ray tracing is fast enough today to get some solid quality rendering, but...

Now, I've been contributing to one academic project for some time, first - this is Aila/Laine work on high performance ray tracing in CUDA:

https://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/

We took their project and started adding some stuff (I based my thesis on the new-added stuff ... and generally a theory around it), we ended up with quite large framework that is able to use a lot more features:

https://github.com/marekvinkler/NTrace

The features that were added are -> Solid texture support, path tracing support (bidirectional path tracing is currently WIP), more acceleration structures (right now we have KD-Trees and BVHs (with several ways to build, including HLBVH)), multiple materials support, etc.

The only large problem with this project is, that we based our code on top of Aila/Laine framework (not that it is bad, but it isn't something you can turn into library and give it out to public ... it would need a lot of work), and the bigger problem... it is in CUDA, I hate platform specific code (and I love OpenCL), but as I stated before, it is academic project - academics like CUDA, they prefer it + the other guy wanted to base the code on top of existing framework.

I've been trying to write a OpenCL based library (and example files) with my experiences from that project (and several others that involved ray tracing, but they were a lot smaller), that would generally allow to perform ray tracing using "any device" (not all of them, but at least all that supports OpenCL) without some crazy dependencies. I've got to the state, where it worked (it still was slower than NTrace, supporting just some older BVH schemes, etc.). I currently don't have time to fully continue my work on the project (any contributors are welcome ... just joking of course ) - but if you would like to get access to it, I have it on local Linux machine, putting it up into git isn't a problem and you could check that out (that project is several times smaller than NTrace and in my opinion easier to read).

what if we sort things by normals?

While compiling the model in first hand, sort vertexes by normals then when rendering, sorting the objects by normals.
There is something in my mind right now but im not sure how effective it will be.

If my theory doesn't fail then while ray tracing, finding the rights triangles what ray may hit would be really fast and easy.
But things get complicated when objects have animations...

Haven't yet gave up that ray trace idea yet i wont be using any methods that exists right now since they aren't fast enough.

The future is The Screen Space Raytracing.