Will's POVRay stuff.

If you came looking for fabulous pictures, you've come to the wrong place.

After a long hiatus, I've begun raytracing again. I'll put some of my efforts up on this page one day, when I've got something that's really worthwhile. However, that doesn't mean that I'm not doing anything; I'm spending most of my time now toying, tinkering, and monkeying with the POVRay code. It has been made known by the POVRay team that the next major version will be written in C++ or some other OO language, and that's what I'm working with right now.

The #exec patch

I've added in an #exec keyword, as discussed on comp.graphics.rendering.raytracing, and the patch file is available here. It's a gzipped unified diff file against the 3.01 source, because it's a heck of a lot smaller than full source files; sorry to people who don't have diff and patch. You should be using Linux anyway. We'll get to some real source files in a minute...

Basically, the exec patch allows you to specify an external command in the scene file. The system executes the command and POVRay reads the stdout. It's simple and powerful, though my patch has only been tested under Linux. YMMV. The syntax is as follows:

#exec <string_expression>

where the <string_expression> is the command line you wish to execute; pipes and redirection are fine, but remember that POVRay will only read the stdout of whatever is last in line. If you want to put your data into a file and expect POVRay to read it, just make sure to #include the file you write.

The cool stuff: my adventures in the POVRay source tree

As I mentioned above, I'm doing some experimentation into rewriting POVRay in C++, and making it much more flexible. Current ideas include:

• Greater flexibility in adding new types. Currently, several files must be changed to add new object types into the system. This was fairly practical when POVRay was first beginning, and the input language was much smaller, but now it's just a nightmare. With my exec patch and the ISOSurface patch, POVRay has 450 keywords, and probably 80% or more of those keywords are used in only one context. Since this is mostly the case, some shortcuts can be exploited:
  • Local keywords for each object type. Following the concepts of OO programming, each object should know totally about itself, and no more. The parser needs to know only what keyword signals what type of object, and the tokenizer only needs to know what words are keywords. Each object should be responsible for parsing itself, and only it needs to know which keywords mean what, and can enforce any context it sees fit.
  • Minimal hardcoding of the parser. The fact that the parser, as it stands now, knows about every single object in the system, it has become completely overloaded. The parser should probably only know about the expression language for floating-point values, vector values, and string expressions. Additionally, it should transparently handle any directives in the POVRay input language, as it already does.
  • Registration of local keywords at startup. Since each object type is responsible for its own keyword list, the parser no longer needs to know what these keywords mean, but only needs to pass them through to the calling object (more on this construction later). The tokenizer must know the keywords, however, and can be notified by way of a global registry mechanism.
  • Local methods for each object. Since many tools are available for creating parsers, and each object will be responsible for parsing itself, tools such as YACC and Bison may be used to generate the local parsers. It is completely irrelevant what method is used, though the current methods should still also be supported.
  Since the parser is being "kept in the dark" about the various types that POVRay may support, it is necessary to extend the registry concept to include registration of a type-keyword mapping. In this way, a keyword which signals an upcoming object definition of a given type can cause the parser to hand parsing over to the specific type's creation/parsing routine. The routine returns a fully-created object back to the parser, which can continue parsing the file as normal. An additional result is that only one or two files need maintenance for each object type, those files of the object type itself (probably object_type.h and object_type.cc). The only dangerous part about this approach is that two objects can use the same keyword, and declare them with different token values, resulting in undefined behaviour for one of the objects.
• Use of dynamic libraries for modularization. Since all manner of modularization can occur with the earlier ideas, it is also possible to make the POVRay executable program into very little more than a dispatcher, and contain most of the real functionality in dynamically-loaded libraries. The only critical portions of POVRay would become the registry and the main routine. Object sets, texture sets, even parsers and renderers could become changeable components. POVRay could also lighten its memory footprint in this manner, loading the necessary components only when they are needed, and unloading them when their task is complete. A parser never need be in core at the same time as a renderer. Command-line options and rcfile options can be employed to specify the necessary libraries.
• Use of STL. The Standard Template Library, or STL, is a simple-to-use and widely available component of most C++ compilers now. Use of STL removes implementation details from the code, making it cleaner to read and understand.

The Modules:

• The Registry

  The registry object's responsibilities include reading the command-line options and rcfile and keeping track of all the symbol tables. Additionally, the registry will be responsible for loading and unloading the various modules, though the main routine will control the timing. The output streams and type-object mapping tables also reside here.

  registry.h
  registry.cc

• The Lexical Analyzer

  This is known in the current POVRay source tree as the tokenizer, and it only needs to retrieve tokens from the current file, and return the appropriate token value. It maintains the current lexical analyzer's black-box approach to white space and comments, and it also now handles includes and execs completely transparently. However, it is not currently possible to use arbitrary string expressions as exec arguments; only string constants are accepted at this time.

  lexer.h
  lexer.l

• The Parser

  This module is only concerned with the semantic meaning of the tokens that the lexer returns, and is controlled mainly by the type-object mapping table in the registry. Whenever a keyword is seen by the parser which it does not already know about (from the expression language), it tries to find that keyword in some translation tables available from the registry. When it finds the appropriate entry, it translates the keyword into a function call via the table, and makes the call. Each function call will be to a static member function of the object class in question (thanks to Thomas Willhalm for this idea), which handles the object creation and parsing. The function returns an object of the appropriate type. See the template.cc file below for a show-don't-tell approach.

  YACC/Bison is used to create the expression parser. Hooking everything up (i.e. encapsulating the YACC expression parser within the parser class) looks to be the biggest problem here. The lexical analyzer and parser will comprise a single library.

  parse.h
  parse.cc
  expr.y

• The Frame

  This is the object which holds the scene tree. Though no work has been done in this area, it may be possible to incorporate various extra functionality here, such as collision detection for animations. The files here are in the very beginning stages, and are most likely useless.

  camera.h
  camera.cc
  ray.h
  ray.cc

• The Object

  The object is fairly simple. The basic Object is designed to export the proper method interface to the renderer, and also supports parsing of object modifiers (hollow for example). The template files are the basic necessities of each class which is derived from Object, including private keyword definition and registration.

  object.h
  object.cc
  template.h
  template.cc

  A generic bounding object (for automatic bounding) seems warranted. Most objects use a normal bounding box, but the blob uses a bounding sphere, and the sor and lathe objects use a bounding cylinder. It may be possible to create some sort of generic objects which all use the same data, so all that needs to happen is to define a different way of using the data.

  bound.h
  bound.cc

• The Texture

  Not much work has gone into this, apart from figuring out what types might be necessary. This file is a big stumbling block if you want to compile almost any of the other files here.

  texture.h

• The Renderer

  Much potential here, though I haven't written a single line. It looks fairly simple to incorporate multithreading and even parallel machines (PVMPOV already does this) into this module. Different rendering methods might also be available (scanline, wireframe, triangle output), though my knowledge in this area is lacking.

• Other files

  Vector, matrix, and quaternion math can all be handled by C++'s ability to overload operators, resulting in cleaner, more meaningful code. The pov_vector template is derived from the STL vector template class. I have also written a spinlocked counter class, which is GCC and Linux-specific for the time being. It should be no trouble to turn it into a pthread-specific primitive, and use the high-resolution routines in frame.h.

  vector.h
  matrix.h
  matrix.cc
  counter.h

  frame.h

  image.h

  Or just visit my source directory. There's a tarfile there too.

Check out my other pages:
top - linux - search - ftps - pov - bm
or send me some mail

Will Wagner (wwagner@io.com) /