> I was thinking more along the lines of each surface possibly having a 
> different code path for computing illumination. Rays in the same bundle 
> can't take different code paths.

Sure they can, you just have an "if" in the shader code based on some flag 
in the ray data.

> Depends on whether you're thinking of running the whole computation on the 
> GPU, or just the ray intersection tests, or what.

Some things I think the CPU still needs to do, like preparing the ray data 
to put on the GPU at each step. It is quite hard to write a shader that does 
anything other than return one "output value" per "pixel", ie you can't 
write a shader that returns a veriable number of rays, the only thing you 
can do is return a flag set that means "spawn another ray".

> I see no especial reason why you can't do arbitrary intersection tests on 
> a GPU. The math isn't that complicated.

I was thinking more about how to store the scene on the GPU efficiently, if 
you just have a triangle list it is relatively simple.

> The only real problem is going to be trying to run something like 
> isosurfaces, which use adaptive space division; a GPU probably won't like 
> that.

Nah it's no problem :-)  Modern GPUs don't have any limit on loops or number 
of instructions or anything like that.

> Also depends on whether you're trying to write your code as a shaper, or 
> use a real GPGPU system. (Such as the OpenCL in the title.)

I think something like a raytracer will be too complicated for a computer to 
try and figure out how to put it on the GPU the best way, needs to be hand 
coded by an intelligent person :-)

> Indeed, that's where I read about the render queue approach. (No, I don't 
> remember where *exactly*.)

Damn.  If you think up *anything* you think is new, you can be guaranteed 
that someone else somewhere has already thought of it :-)  The internet just 
makes it easy to find that person!

Post a reply to this message