POV 4 Strategy Proposal Author: Eugene Arenhaus, chipmunk@netvision.net.il For the information of: POV-Ray tem, and everyone interested. Concerns: Possible way of developing POV 4 POV has gone a long way, and earned its place as the best freeware ray tracer, aiming at artistic rather than commercial values. However, like it happens with many software products that have a long development history, it has reached a state where updating and adding new features poses a serious problem due to feature conflicts and architectural shortcomings. This is why I am making this bold proposal: POV 3 should not be used as direct ancestor for POV 4. Instead, POV 4 should be developed with different principles in mind, aiming at greatest flexibility and easy extension of the product. Backward compatibility with previous versions should not be considered a major requirement: POV 3 is reaching its limit, it's time for breakthrough. What are the chief points in POV 4 ideology that are proposed? In actuality, there are only three of them: 1. Hierarchical, layered object model 2. Full-featured object-oriented scripting 3. Dynamic modular internal architecture By consistently implementing these principles, several major advantages can be achieved: ? Maximum flexibility and consistency of scene language ? Drastically reduced need for patches and external utility software ? Easy and seamless incorporation of new features The proposed ideology concerns chiefly the architectural model, and does not require any large-scale modifications to the actual mathematical algorithms involved - these latter can be reused to up to 95%. Let's discuss the three principles in detail. Hierarchical, layered object model Currently, objects in POV are self-contained entities. Each can be declared with a special command, often with a unique set of properties. Some of those properties are universal to all objects, such like colors and transforms; but many are used uniquely, like height maps in height field object. This leads to many little but nasty inconsistencies and incompatibilities, and even duplicate features (POV essentially has two surface-of-revolution objects, for instance.) The proposed model, on the contrary, would allow all objects use any properties freely and interchangeably. The basic idea is layering (stacking) objects to achieve the final look. In a sense it is similar to MAX modifier stack, and to material maps used in POV. Layered objects are containers for each other, and rely on the underlying layers to determine their final appearance. A sphere can compute its geometry but relies on the underlying texture object to determine its color. CSG object contains several geometry objects which in turn may be having their own textures. Blob object relies on underlying geometry or CSG objects to determine its own geometry. Textures may be composed of texture layers, and so on. Bringing such consistency to the object model is of great importance for flexibility available to the end user. For example, currently we have texture maps and normal maps. (Add the height maps to it, these are still another thing.) Normal maps, in turn, have special parameters to control their slope, which are different from other control parameters in POV. With new ideology in action, we'll have only one map object to do all these things. We'd simply say that color channels must use one map, bump channel must use another map, and slope must use yet another map - or the same as others. (No more specially preparing image files for height fields.) What's yet more important, this approach would easily allow to map *any* parameter. For example, it'd be possible to have turbulence parameter varying but a map, having turbulence gradients (an actual user request), or having a variable mapped IOR, for hot-air effects, using the same mechanism as with other mapping. Effective implementation of this principle would require a certain change in the set of POV primitives: they would become simpler and smaller; instead of being individual big machines capable of doing many things they would be more like machine parts that can do only one little action but also be used to assemble many machines. For example, instead of having separate object for a height field, there would be a special displacement map primitive applicable to geometry, and turbulence parameter could be handled as separate primitive as well, applicable to textures and texturable in turn. Possibilities are endless. Implementation issues Instead of multiple unique objects to handle, it's suggested to use a single consistent object model for everything from geometry to textures. This unitary object must implement a specific POV interface, with such functions available as determining the intersection points with a specific ray, color and normal vector at a specific 3D point, and perhaps distance from the surface to a given point. Every object in POV should implement this interface, including textures. (Textures still should implement ray intersection - simply by themselves, they *always* intersect rays, being infinite solids.) The object must also support the layering through importing this functionality. It's easy to see that the object properties still fall into the familiar channels: geometry, surface, and material, perhaps more. The object should be able to import any of these channels from other objects, to determine its own composite appearance. The actual objects would simply implement this interface, not necessarily in full. For example, it makes sense that geometry objects would handle ray intersections and distance computations, while texture objects would handle colors. Layering these primitives would compose the final objects that handle all channels through calls to underlying objects. Not actually related to this but highly desirable would be support for implicitly and explicitly referencing the objects. It is much more efficient to have multiple references to one and same textured sphere, than declaring it over and over. (Currently it is supported for mesh geometry, but should be made the universal rule.) Full-featured object-oriented scripting Scripting language technically might come along with scene description language, but it's desirable that the scene description language itself should be implemented as such. We are speaking of a real interpreter here, with function calls and user objects. (The current macro language is already a step in that direction, and it should be taken further.) This would largely eliminate the problems with making complex objects, and make for smaller and cleaner scene files. Another important benefit from scripting would lie in possibility to write custom functions for POV primitives, eliminating need for external software. Macro language is already used very widely, but this would make many more things possible - from implementing custom shaders to making new custom primitives from scratch. This would also largely eliminate the need for patches and plug-ins (the feature being hard to implement due to cross-platform incompatibilities). It is essential that the script would provide the user with full access to the object interface. Script must allow the possibility to check surface parameters, cast rays, check intersections and so on. Dynamic modular internal architecture The dynamic modular architecture is not an issue that is essential for the user, since it concerns only the programming. However, it is the approach that can solve most design problems concerning feature conflicts and feature addition. The idea itself is simple. All primitive objects should use the same consistent interface, and their implementations should be contained in separate classes. The main program should refer only to the abstract interface without any connection to the actual implementation - this includes both tracing and scene parsing. The implementation classes should register themselves with the main program through a special registration interface, informing it about their descriptions and telling the parser how to handle their declarations. When a program is built by this principle, it does not know anything about what actual objects it handles. It only contains code to handle a set of unified, standard interfaces - for tracing, for parsing, and for other needs that might arise. Objects, in turn, bother to take the implementation tasks on themselves, handling their own parsing and tracing. Addition of new and removal of old features to such a program is extremely easy, and requires only a modification of the makefile. Individual modules can be implemented by independent programmers, no incompatibility issues arise between objects, and any new primitive object is immediately usable in object layer stacks without any special programming. Also, the third-party patches can be made as separate modules too, and their incorporation into the new versions of the product will become immediate and seamless, not even speaking that conflicts between patches will disappear. In conclusion This proposal comes from six years of designing the object-oriented software, and three years of using POV (along with other 3D software packages) - the experiences of the first applied to the frustrations of the second. Any comments, questions, and discussion in general are welcome. E.A.