This is (AFAIK) how nVidia's OptiX technology works; the advantages of rasterization for first-bounce rays are pretty well-documented.

I don't know, it's nice for now as it takes advantage of very fast rasterization hardware already present in GPU's, but once (and if) special-purpose ray-tracing hardware is developed, this step should be unnecessary. It's also quite redundant on any other hardware than graphics cards. I suppose it's good to have, but the ray-tracing problem has pretty much been solved in theory, all we need now is cheap and efficient ray-tracing hardware so that it can actually compete on equal grounds with real-time rasterization.

That said, the one advantage of rasterization is that the memory access pattern is completely predictable (which is partly why it is so fast on special-purpose hardware), whereas in ray-tracing it is rather random, so it makes sense to use rasterization on high-latency/high-throughput memory hardware like GDDR5.

Another is that the performance of rasterization does not depend too much on resolution, but it does depend on scene complexity linearly (it's the opposite for ray-tracing). As scenes get more and more complex rasterization may become prohibitively expensive even with rasterization hardware, forcing a switch to fully ray-traced graphics (but I doubt it, as user resolution increases considerably faster than scene complexity).

A drawback of rasterization is that it cannot represent implicit surfaces without triangulating them explicitly first (and hence paying the storage tradeoff). Ray-tracing can, however depending on the surface's complexity the analytical intersection formula may be too expensive to compute anyway. This is mostly for spheres, cylinders, toruses, and simple shapes like that.

And for more I have some ideas about optimizations for ray depth - 1.[/quote]
Don't hesitate to post them, I'm sure there are many people on this board interested (including me)!

Hi !

[color=#000000][font=Arial, sans-serif]

What do you think about , below[/font]

[color=#000000][font=Arial, sans-serif]

ray trace engine as[/font]

[color=#000000][font=Arial, sans-serif]

ray depth - 0 - raysterization[/font]
[color=#000000][font=Arial, sans-serif]

ray depth - 1 - ray tracing[/font]

[color=#000000][font=Arial, sans-serif]

?[/font]

I've worked extensively on that approach in the past and I can tell you it works well. Rasterizing the scene for depth=0 gives you a nice performance improvement because it allows you to skip one tracing step. However, depth = 0 is the easiest and less expensive step because the rays are coherent. For depth > 0, the rays can get highly incoherent and will be the bottleneck of the rendering thus the advantages of using rasterization for the first step may become a lesser optimization.
Of course, all this depends on what kind of rendering complexity you're aiming at. In my case, I used ray tracing to complement the GPU rendered scene with a single bounce of ray-traced reflections which worked pretty well and fast. If you're interested, check my master thesis for details: http://voltaico.net/serenity.html

Bacterius, Ok. for ray depth-1.

1) Polygons on screen is dividing to somes small squares. (around 16 pixels for example)

2) All points from all polygons are traced using sah bvh.

3.1) For all subpolygons find last bvh node which are intersected by all subpolygon vertices.

3.2) Trace other subpolygons points from founded lasts bvh nodes .
...

You can't assume that if I trace a ray A in the general direction/origin of a bunch of other rays B, I only have to test intersection vs objects close to the first intersection of rays B.

I do something like that, I use the usualy DX11 pipeline to rasterize the scene, I also create a voxelspace and then (using direct compute) I ray trace through the voxel space to create ambient occlusion:
http://twitpic.com/8iohd5/full

I am working since some months on a more advanced version, using tracing for the whole lighting solution as well as for transparent objects and volumetric effects, but as jcabeleira said, the first hit is the simpelst and fastest pass, beside that it also is quite important for anti aliasing, so you either have to render with a very high resolution und trace for sub pixel, or you end up with aliasing. On problem with the same reason is that HDR rendering can produce neighbouring pixel with very different magnitudes of light intensity. without high AA that you just can get through raytracing, you will see aliasing. you can of course try the hacky way of sperating tonemapping and resolve before gamma correction, but it's kind of breaking the purpose of using raytracing (high quality and correct images).

There are some games that trace in screen space through the gbuffer for some local reflections and more advance occlusion/shadow checks.