|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |