"Eugene Arenhaus" <chi### [at] netvisionnetil> writes:

> Here are some thoughts about what POV-Ray 4 could look like.

I've read all this over and over, and I still have the same remarks.
I cannot believe I have kept in such a bad mood for the last five
days, so I guess at least a bit of what I'm about to say is right.

> 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.

  Huuh?  See the number of patches that are published these days?

> 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.

  Whaaaat?  Are you *really* meaning that?  Backwards compatibility
not to be considered a major requirement?  Makes me jump on my seat
each time I read that.  How dare you speak of easy extension if you
abandon backward compatibility?

>  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.)

  Why is it so, in your mind?  Lemme think...  Maybe because it's the
way it is in real life.  A real object has a shape and a material.  A
raytraced object has a model for its shape (to be chosen in a set of
different models) and a model for its material (including texture,
interior, refraction etc.).  Different properties mean different
implementations. 

> The proposed model, on the contrary, would allow all objects use any
> properties freely and interchangeably.

  Yeah, like you're going to use a center and radius for a texture
map.  Or a area_light for a sphere.

[...]

> 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.

  Of course they have!  They are different things!  Why would you want
them to behave like an atmosphere?

> 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.

  Yes, that should have been done ages ago.  Give those haloes a slope
map!  They need it!  What for?  Uh, lemme think...  Consistency with
normal maps, that's it.  Ah, but then the quadric primitive also needs
atmospheric attenuation, doesn't it?

> (No more specially preparing image files for height fields.)

  You'll have to forgive me for that, but that sounds like one of the
biggest pieces of nonsense I've ever heard.  How do you intend to
generate height fields without specially prepared images?  Randomly?

> 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.

  Variable IOR means bent rays, which is kind of a huge piece of work
to do.  I agree on the use of these features, though.

> 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.

  Sounds to me like simplicity just gets killed on the way.

>  Implementation issues 
[...]
> 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.

  So you want, instead of having each object perform the task it's
meant for, to have any object perform any operation *at all*.  I still
cannot understand.

>  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. 

  Whaaat?  Object-oriented scene description language?

> 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.)

  Wake up man, you're *describing scenes*, not programming!  Is life
object oriented?  Are your car and fridge objects with attributes and
methods?  How often do you call the tap.open() or the window.close()
functions? 

> This would largely eliminate the problems with making complex
> objects, and make for smaller and cleaner scene files.

  Yes, of course.  Replace every single parameter with a function
call.  You call that readability?  And small?

Sphere Left_Eye_Ball is
  Radius : Float := 1.0;
  Center : Vector3 := <0.0,0.0,0.0>;
  Texture := new Texture_Type;
  Texture.Pigment := new Pigment_Type;
  Texture.Pigment.Type := Bozo;
  Texture.Pigment.Turbulence := new Map_Type;
  Texture.Pigment.Turbulence.Type := Gradient;
  Texture.Pigment.Turbulence.Direction := <1.0,0.0,0.0>;
  Texture.Pigment.Turbulence.Map := new Map;
[...]
end Sphere;

> 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).

  And dramatically slow down the parsing and tracing.  Remember,
compilers were invented some time ago to produce fast code.

> 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.

  Could be nice.

>  Dynamic modular internal architecture

  Yeah, object oriented programming, in a word.

> 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.

  Er...  Does this conclude anything?

  This text sounds to me like it's full of ideas.  I'm afraid most of
them are bad ones, though.  Let's sum them up.

- Abandon backward compatibility.  This is a *huge* contradiction of
  all programming principles.  (Unless of course you work for
  Microsoft, but that is not my point.)  Abandoning compatibility
  means throwing all external programs to the dustbin.  You can't
  seriously do that.
- Unify primitive interfaces.  This implies to switch from a realistic
  model (based on how the world works) to a programmingly nice model
  (based on how abstract object oriented programs work).  No, no, no,
  the raytracer uses models inspired from reality, not models that
  make it easy to program!
- Object oriented scene description language.  Means complexity.  You
  cannot expect a beginner or even a programmer to support all the
  hassle of object oriented programming just to describe a scene.
  Boy, if the scene comes from an object oriented vision of life, then
  use a scripting language to generate your scene, such as Perl or
  Python!  Programming is out of the range of a *description*
  language. 

  My conclusion: you're trying to make the raytracer stick to a very
abstract programming model rather than to how it works (remember, it's
used to simulate the way light behaves in a given environment).
You're trying to make the program an abstract one, instead of making
it easy to use.  You're trying to make POV-Ray a programming language
instead of keeping it a raytracer.

  I want to keep POV-Ray as an engine to trace!  Complex scenes are
described by complex files, and if I do not want to write complex
files then I use Perl.  With all the objects that I need.  I want to
be able to use my old Perl scripts with the new POV-Ray.  I want to be
able to write quick-and-dirty scenes without those objects.  I want to
describe scenes as they are (objects with textures) and not as they
are represented inside the engine.  And I want them to be represented
as they are and not according to some abstract and confuse model, so
that I can write new primitives when I need them.

  Ladies and gentlemen, thank you for your attention.

P.S: I have only six months of object oriented programmation behind
me (alright, that was only C++, but many consider it to be a real OO
language), many years of POV-Ray, and although I still don't see why
there is such a buzz about OO programming, all my frustrations in
POV-Ray scene description language have been solved by the -i-
option.  The #while, #for and other directives are rarely used by me.
-- 
Roland Mas

A man walks into a bar.  Bang.

Post a reply to this message