jute <nomail@nomail> wrote:
> The POV-Ray SDL.  I read from a post that v4 will include a new version of
> the SDL.  Is this true?  How extensive are the planned changes?  Why, if I
> may ask, are they required?

  Exactly as the current POV-Ray source code is a bunch of hacks over hacks
and patches over patches, making it an unmaintainable chaotic mess, the
SDL is pretty similar. The original SDL was never meant to be a programming
language, just a data container format. However, over the years many
programmatical features were added (read: kludged) over the old SDL.
The result is a bloated, mostly ugly, limited and specially inefficient
language.

  Most POVers are accustomed to the current SDL and find it mostly easy
to use and understand, and people have created more or less complex include
files as kind of "plugins" to add new features to the program which people
can easily use. However, due to its limitations and inefficiency it's just
not possible to implement everything which could be possible and this is
a big minus.

  Example: Imagine an include file which you could use to load a scene in
3DMax format. Moreover, imagine that you could *save* a POV-Ray scene
consisting of meshes in 3DMax format with that include file.
  Or imagine you could make an include file that can be used to save the
rendered image in JPEG format.
  Imagine an include file which could allow you to handle NURBS data,
or HDRI data or whatever.
  The list of possibilities is endless.

  What is the current solution to add these kind of new features? To patch
the POV-Ray source code, adding it to the endless list of other patches,
requiring people to download an install yet another unofficial version
of POV-Ray... And yet these newly implemented features are usually rigid
and limited and can't be enhanced by the user unless he knows C++ very well
and is willing to fix the code and recompile a new version of the binary.
This just needlessly bloats the source code, making it harder to maintain
and adding tons of possible bugs and incompatibilities
  And most importantly: These new features would be just kludges over the
already-cluttered poor old SDL which was never designed for these kinds of
things.

  Another problem is speed: The SDL is slow like a bug in molasses.
  I once made a concrete test: I made an ascii-mandelbrot program with perl
(which is also an interpreted scripting language) and basically the same
program with POV-Ray SDL (the output of both was practically identical).
The perl version was over 13 times faster than the POV-Ray version.
  The problem is that the current SDL is not very suitable for speed
optimizations because of its very design (kludges over kludges over old
SDL which was never designed for this).
  A better-designed language could be made as fast as perl.

  I have always said that one of the most powerful features of POV-Ray
(its SDL) is also one of the weakest features of POV-Ray.

  POV-Ray is in desperate need of a powerful and efficient scripting
language. The user-defined functions introduced in POV-Ray 3.5 were a
step towards this, but they were also just kludges over the old SDL.
That is just not the way. It doesn't work very well.

  People have suggested not inventing the wheel once again but to use
an existing scripting language which is fast and efficient. This is not
a good solution because the scripting language of POV-Ray needs to be
specific to POV-Ray. It must be easy to create primitives, textures, etc
with the language. This task becomes harder if they must be created with
a generic scripting language not designed specifically for POV-Ray.

  Conservatives oppose all kind of changes to practially anything, but
that's too bad. The current SDL is just not it. If fundamental improvements
are desired for POV-Ray, the current SDL would be just a drag and would
make any new improvements a lot harder.
  Conservatives find it hard to see the *advantages* of having a more
powerful language: Programmers could create better and more powerful
include files with more diverse features for people (including these
conservatives) to use. And because all these new include files are based
on the one and same scripting language, their usage will be very alike,
making it easier to learn to use them. In the long run people would
benefit from this a lot more than from tons of patched binaries which are
kludges over the current SDL and completely new syntax to learn.

  However, this doesn't necessarily mean that pov4 will be completely unable
to render old scenes. I'm sure the team will have some level of backwards
compatibility.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message