Original message, in plain text:
(Note the original writer is not I; I'm only reposting..)
----------------------------------------------------------------------

POV 4 Strategy Proposal

Author: Eugene Arenhaus, chi### [at] netvisionnetil

For the information of: POV-Ray team, 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.

Post a reply to this message