> The solution in both cases is to put rays into "queues", such that all the 
> rays in a given queue take the same code path [for a while]. When you need 
> to spawn a secondary ray, you add it to a queue rather than recursively 
> tracing it. When some rays hit an object and others don't, you add them to 
> different queues.

Why add it to a different queue?  All rays that still need to be traced 
(whether they are reflection, refraction, primary or shadow rays) simply 
need to be intersected with the scene geometry.  If you like you could keep 
a flag in the queue for each ray to say what type it is, but the GPU part 
that does the ray-scene intersection probably doesn't care what sort of ray 
it is.

In that way the GPU will just process as many rays as it can in batches 
until the scene is complete.  The CPU would handle preparing the queue at 
each step, ie removing rays that have terminated and inserting new rays for 
shadows and reflections etc.

Of course to be able to do efficient scene intersection on the GPU it would 
probably be best to only allow triangle-based scenes, and figure out some 
way to store a Kd-tree of triangles efficiently in a texture.  Sounds like 
the sort of thing someone has already done a PhD on :-)

Post a reply to this message