how many rays?

Well, it's exactly the same as collision detection over time. See the light as expanding rapidly in the form of (ultimately) a set of fast moving and expanding hexagons. And when they intersect, you split them up.

 

Anyway, for something completely different: all the really hard problems in 3D tend to break down into not having a good spatial representation of the objects, and/or being able to determine the interactions.

Isn't that the thing we should all spend lots of time on, and come up with something that does work?

 

But your choice of resolution is the problem here. It's just intrinsically difficult to find the appropriate resolution setting.

You could, of course, attempt some sort of hierarchical subdivision of the initial rays, but then it becomes difficult to find the appropriate level of division, and how do you know when you've missed an object entirely just because the resolution was set too low? And what about when you have a small, reflective object (like, say, a glass sculpture) that will require a lot of rays? If you're using a light-source-based dynamic resolution scaling system, it's rather likely that you'll pump a very large number of rays into the space near the sculpture that just aren't needed, and will also pump a large number of rays into regions of the sculpture that are reflected off-screen and never seen.

 

Yes, but any way you look at it, you want some kind of geometry/collision detection scheme to determine where you want to send the rays in the first place, and you could even do away with the individual rays completely if you can break that geometry approach down into small enough surfaces. And in that case, a coarse first pass from the lights would also allow you to determine things like transparency, small objects and global lighting all in one go.

There is nothing stopping you to do the final pass from the screen, and only send the beams you found out to really need. And add the coarse, first pass as global illumination.

Which was the original question.

 

First, you could say that tracing dynamic scenes with very good data structures is basically solved. Here are three different papers on BVH/KD-tree hybrid structures. All three of them were designed independently of each other:
http://graphics.cs.uni-sb.de/Publications/2006/bkd_gh06_final.pdf
http://graphics.uni-ulm.de/BIH.pdf
http://www.cgg.cvut.cz/~havran/ARTICLES/rt06submission.pdf <- might be offline from time to time.

I've seen a 32bit P4 rebuilding the entire tree for ~10k triangles in less than a millisecond. With SAH kd-tree it would have taken ~80-150ms. Tracing the two is roughly equally fast.

For HW, take a 8-pipeline ASIC running at 285MHz and optimize it. If you get into the same die-area as R600/G80 you should have something with at least 24-32 pipelines running around 500-700MHz. That would evaluate to roughly 1.5-10 billion rays per second on average. Should be good enough for most games for a while
http://graphics.cs.uni-sb.de/~slusallek/Presentations/ANS06.pdf


How many rays are needed? As have been said, depends on a scene.

One scenario might be something like this:
1280x1024 resolution
adaptive AA with average of 2.5 rays per pixel
20% of all primary rays generate a secondary ray (reflection, refraction)
5 pointlights

Summing those numbers up we have:
1280x1024*2.5*1.20= ~4M primary rays per frame.
Each of those rays generate 5 shadow rays totalling in around 20M more shadow rays. Intersecting of the shadow rays is a bit less expensive, I would say that those 20M shadow rays are about as expensive as 16-17M primary rays.

So, in total we have ~22M rays per frame, at 60FPS around 1.3G rays per second. At 1600x1200 with the same settings it would be around 32M rays per frame or 2G rays per second.

Current CPU's can archieve around 3-10M rays per second per core, Core2 about twice that.

If you add stuff like area lights, GI and caustics things will of course get quite messy and much slower but it is the same with current rasterizers.