> Warp:
> Here are some ideas of mine

As good a place as any to start. I want to contribute to this discussion 
as someone who is not a knowledgeable programmer but has possibly 
written at as much POV SDL code as any other person on this server.

I have put some thought over the past two weeks into deciding what 
exactly POV-Ray is. A renderer of course; A modeler perhaps. But, beyond 
that, what is POV-Ray in relation to other "free" renderers out there?

My conclusion is that POV-Ray is, importantly, the renderer whose users 
best understand it. Here's an example: I asked on the Yafray forum 
whether Yafray allowed a user to explicitly define the vertex normals of 
a mesh; 165 views so far - 0 answers. No user on the forum seems to 
know. Blender can't do it, so Blender's limitation has become, literally 
or practically, Yafray's limitation. Contrast this with the POV-Ray user 
base, the even moderately experienced of which are familiar with both of 
our mesh formats, light_groups, no_image, and many other critical 
features which the mouse-modeler crowd might consider merely "tweaks."

Given that, what can and cannot be changed without changing POV-Ray's 
identity?

> Warp:
> * Even if it's based on the current SDL <snip> some backwards-
> compatibility  must be broken

Must be based around certain characteristics of the current SDL. A scene 
with a camera, light_source, and sphere must require familiarity only 
with the camera, light_source, and sphere objects. There should never be 
a section in the documentation titled, "Structure of a POV-Ray Scene 
File" or anything similar.

Forget backwards compatibility. Now is the best opportunity that will 
likely ever come to undo any "mistakes" of the past.

> Warp:
> * Existing data containers, namely arrays and strings  (which are
> special arrays of characters), should be enhanced and new data
> containers  introduced <snip> it may be necessary to introduce the
> concept of modules (ie. classes without inheritance) or classes
> (with perhaps a simple inheritance support) and references. These
> modules or classes could have member variables and perhaps even member
> functions. Accessing the elements could be done with the dot operator.

All of this would add piles of pages to the documentation (a bad thing), 
and provide (in most cases) nothing which could not be provided by 
generating SDL with any given user's programming language of choice.

The way I work now is by generating POV SDL in Python, but I still make 
use of POV-Ray macros. An example is a macro which uses eval_pigment. 
POV-Ray knows the value of "leopard" at <3,4,5> - Python doesn't.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Any addition to the procedural part of POV SDL must either be necessary 
to create a scene, significantly decrease the size of a scene-file, or 
significantly increase the readability of a scene-file.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

> Warp:
 > * The most difficult thing of all: Some kind of shader language,

How about keeping it simple? For instance, a function "surface" which 
knows what every ray knows and works with POV-Ray's existing texture and 
finish options.

How a colored specular shader might look (if functions could return 
vectors):

#local colored_specular = function {
     pigment {
         function { surface().specular }
         pigment_map {
             [0 object_pigment]
             [1 rgb <1,1,0>]
         }
     }
}

sphere { 0, 1
     pigment { rgb <1,0,0> }
     finish { specular .8 }
     shader { function { colored_specular() } }
}

A toon shader might make use of surface().illumination or 
surface().angle_of_incidence

  -Shay

Post a reply to this message