scott <sco### [at] scottcom> wrote:
> > In short: The rendering speed of a CPU of these days is within the
> > measurement-tolerance of an actual (not so actual ... HD 7990) graphics card.
>
> ...
>
> > They do NOT have currently such a
> > nice rendering SDL like POV-Ray.
>
> That is not a coincidence.
>
> GPUs are excellent for writing a simple raytracer that runs very fast.
> By simple, I mean only supporting one type of simple shape (eg mesh,
> isosurface, sphere), no CSG, no general procedural textures, only one or
> two types of light in a scene etc. The point is the code that is run on
> the GPU is very specific, and the GPU hardware then excels at running
> this exact code millions of times on different data.
>
> However if you wanted to implement an SDL like POV-ray's, you would need
> code to handle every possible primitive shape (each shape needs it own
> intersection algorithm), every possible procedural texture, CSG, shadow
> and lighting algorithms for every possible finish and light type etc.
> Such a large bit of code, where each time it is "run", a different small
> portion is actually executed, is not well suited to a GPU at all.

I don't think it's totally out of the question to write a GPU-based render
engine that does support plenty of shapes, procedural textures, etc. The
challenge there is to bunch sufficiently similar rays together -- the buzzword
being "ray coherence". This is comparatively easy for 1st-level rays by just
bunching up rays for adjacent pixels, but 2nd- or 3rd-level rays will become
increasingly incoherent, so for efficient computation it will probably be
required to postpone their computation until rays with sufficiently similar
origin and direction have accumulated and are ready to be traced in a batch.

You will probably end up with an architecture that smashes up the whole ray
tracing process into small steps -- possibly even into multiple steps per trace
level, such as separating intersection testing from shading computations --,
introducing buffer structures to both pass data from one step to the next and
re-consolidate it into coherent batches.


The problem with POV-Ray, however, is that its internal architecture is still
comparatively monolithic, and therefore does not lend itself to being smashed
into pieces that easily.

Post a reply to this message