David Buck <dav### [at] simberoncom> wrote:
> Now, you build a very simple but very expressive SDL grammar that allows 
> you to express graphical modeling concepts very simply.  With this SDL, 
> you can then define what "sphere" means but this time it's written in 
> the SDL language, not in C.

  This is a good idea only if you want your renders to take at least
10 times longer than currently.

  Not only are the C(++) implementations of the primitives faster because
the compiler can optimize them, they are also optimized on a per-primitive
basis. For example, a sphere is not a generic polynomial object which is
solved while raytracing. A sphere is a very specific piece of code which
has been optimized to calculate the intersection points between a line
and a spherical surface.

  If, however, now you would change that to a generic surface definition
language where the user specifies that "a sphere is an isosurface defined
by the function ..." the render times will sky-rocket. Solving a generic
user-written isosurface function is much slower than the optimized
ray-sphere C++ code.

  If the answer to this is "ok, then let's add an internal 'sphere' function
which is optimized for speed and which the user can call" then we are
exactly where we are now. Nothing would have changed.

  The whole idea of POV-Ray is speed. Why do think that thousands of
hours of work has been put into making POV-Ray support multi-threading?
For speed, only speed and nothing but speed.

  Killing this speed kind of defeats the whole purpose.

-- 
                                                          - Warp

Post a reply to this message