Eugene Arenhaus wrote:

> Hi.
>
> Here are some thoughts about what POV-Ray 4 could look like.
>
> The POV team is especially welcome to read. :)
>
> Thanks!
>
>      (``      Email:    mailto:chi### [at] netvisionnetil
>      (=o \    Web page: http://www.furnation.com/chipmunk
>   _  / ,-'    ftp://velar.ctrl-c.liu.se/vcl/Artists/Eugene-Arenhaus/
>  ( `(   )
>   ) /  ``O    "To see a World in a grain of sand,
>   ''  `,~'     And a Heaven in a wild flower,
>   \    ))      Hold Infinity in the palm of your hand,
>    `---``      And Eternity in an hour."  (W. Blake)
>
> POV 4 Strategy Proposal
>
> Author: Eugene Arenhaus, chi### [at] netvisionnetil
>
> 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.

Post a reply to this message