I have written about this years ago already, but here's a quick
recapitulation of what I think would be good for the new scripting
language (and perhaps a few new ideas):

- It must be easily byte-compilable. Preferably to a byte code which may
  be easily JIT-compiled to native machine code in some future version.
  Even without JIT-compiling just the fact of having it in bytecode
  format can make parsing an order of magnitude faster.

- The bytecode will also allow saving scenes in bytecode format for
  faster parsing. (Basically the need to parse the scene is removed
  completely, except for some sanity checks of the bytecode.)

- Currently there's a distinction between parse-time scripting (the SDL)
  and rendertime scripting (user-defined functions, used eg. in isosurfaces).
  Rather obviously no such distinction should be made in the new language.
  Anything you write should be runnable at parse time and at rendertime
  (and also at the post-processing stage).

- Object properties, such as textures, should be fully specifiable using
  the scripting language itself (facilitated by the previous point). In
  other words, you should be able to write, for example, "shaders" with
  the scripting language. This "shader" is evaluated every time that
  certain property of the object (eg. its texture) is needed.
    This would allow eg. writing an AOI patter with the scripting language,
  completely removing the need to add such a pattern to the core renderer.

- Most core renderer features should be available to the scripting language.
  As an example, you should be able to launch a ray from a given point and
  retrieve the color it returns.
    This will allow, among many many things, writing eg. a "portal" shader,
  ie. a texture which shows the image as seen by a secondary "camera"
  somewhere else. I believe megapov has currently such an option. Rather
  than being a core feature, it would be easily implementable with scripting.

- Related to that, the scripting language should be so flexible that many
  current core features can be removed from the core renderer and put into
  libraries.
    Currently there are tons of features in the core renderer which are there
  for the sole reason that you can't implement them with the SDL, and there
  wouldn't be any other reason for them to them to be there (eg. efficiency).
    The core renderer should be as minimal as possible, and only contain
  things which have to be there because of efficiency (it would be way too
  slow to try to implement them in scripting). The smaller the core renderer
  is, the lesser bugs it will have.
    (Another advantage is that bugs in libraries are much easier to fix
  than bux in the core renderer. Also libraries can be modified by the
  user much more easily. Modifying the core renderer is way more laborious
  and error-prone.)

  Related to that last point, an interesting question is how to provide
standard data containers ? la STL. By the previous principle they should
be provided as libraries. This makes them more flexible, easier to modify,
and removes clutter from the core renderer.

  However, there's also a negative side: The STL in modern C++ compilers
is very stable, very well tested and almost certainly bug-free, while
creating equivalents with the new scripting language, no matter how
flexible it might be, is very laborious and will inevitable be ridden
with bugs for years to come. Providing a "wrapper" to the STL in the
scripting as a core feature could be way less work and less error-prone
than trying to re-implement them from scratch using the scripting language.
They will probably also be faster that way (because the container functions
will be compiled, rather than bytecode-interpreted).

  If the scripting language is designed smartly enough, it will actually
not make any difference whether the containers are implemented as libraries
written in the scripting language itself, or whether they are a core
feature (acting as STL wrappers). This allows changing the implementation
of any of them from one approach to the other without breaking any existing
scenes. This is a goal to aim for.

- The design principle of the new scripting language should have some kind
  of "unified object model" approach. With this I mean that core objects
  and user-created objects should work and be usable in the exact same way.
  That is, it doesn't matter whether a "sphere" object is a core feature
  or something which came from a library. In either case you would use that
  "sphere" object in the exact same way (as long as you know its interface,
  of course).
    For example, if you wanted to access (read, change) the texture of the
  object, it would be done with an identical syntax regardless of whether
  the object is a core feature or defined in a library.
    In object-oriented terms, they would have a common base class (even if
  the scripting language wouldn't really use literal inheritance) and you
  can handle any object in the same way.

    And by "object" I don't necessarily mean literally object primitives
  (spheres, boxes), but basically anything povray features (lights, cameras,
  textures, arrays...). In other words, regardless of what it is, it should
  be usable in the same way regardless of whether it's a core feature or
  defined in a library. Of course different types of objects will have
  different interfaces (in OO terms, they will have different base classes),
  and you have to know the "type" of object you have in order to use it
  (eg. handling a sphere is different from handling a texture, for instace,
  as they have different type of data), but the point is that the user
  doesn't have to know if it's a core feature or a library object in order
  to use it (he only has to know its interface).

- As for memory management: Garbage collection (as in the one in Java or C#)
  might be nice, but VERY hard to implement efficiently. If possible the
  scripting language should be designed in a way which makes creating a GC
  engine unnecessary.
    This might mean that the only way to use dynamic memory is through the
  dynamic data containers provided. However, that might be enough for
  almost everything. (After all, most people have done cool things with
  the current array feature, even though it's *really* rigid. The new
  data containers will be much more flexible.)

- The scripting language should also be designed so that it's easy to
  flexibly read, parse and write data files (as well as handle the data
  itself). This would allow writing things like 3DS or OBJ file format
  importers as libraries. (This is an example of something which should
  definitely be a library rather than a core feature.)

-- 
                                                          - Warp

Post a reply to this message