In article <3C3D9297.6641E0E4@avalon-net.co.il>,
 Eugene Arenhaus <eug### [at] avalon-netcoil> wrote:

> Here's my two cents. 

Well, first, you should be aware that there won't be any official 
discussion about POV 4 from the POV Team until POV 3.5 is finished.


> Example 1. 
> PoV3 has a camera object that is used to render the scene. However, it
> cannot be used in no other form in the scene, so making a scene that has
> a television screen viewing the same scene requires trickery with image
> maps and double-pass rendering, or even recreating copies of the scene.

Well, the camera isn't really an object, it's more of a setting, like 
global_settings. You can move it around, but you can't texture it and 
you can't see it.


> Example 2.
> PoV3 has dedicated texture maps that can be combined to create patterns
> on objects' surfaces. However, geometry cannot be used for that; it's
> not possible to draw three red circles in a row on the surface of white
> cylinder, unless you use an image map (which causes artifacts) - not
> even if you use CSG to merge the three red cylinders and one white and
> then clip it all with another cylinder - because CSG has side effects on
> color. Geometry-controlled pigments are just not generally possible.

Your example, 3 red circles on a cylinder, is quite possible...even with 
POV 3.1, though it is a lot easier with 3.5. And CSG has no side-effects 
on color.


> Example 3.
> PoV3 has a flat height field object whose shape is calculated from an
> external image map. It does not, however, allow generation of height
> fields from built-in procedural textures,

POV 3.5 has 3 ways of doing that: the built-in height_field using the 
function "image" feature, isosurfaces, and standard macros.


> Principle II. Complete accessibility of object properties from scene
> description language

True, the only way you can do this is to declare the properties you want 
as variables, often a clumsy way to do things.


> for instance, it would enable the artist to use texture values to 
> control size and positioning of the objects, where currently it has 
> to be done either using random numbers or external programs.

This can be done already in POV 3.5.


> PoV3 only has limited macro support, with parameters strictly
> precalculated and support of true functions absent.

What do you mean "precalculated"? And in what ways have you been limited 
by POV macros?
BTW, POV 3.5 supports "true functions" that can be evaluated at render 
time when necessary.


> We suggest that the only and sole data type used by PoV4 should be a
> vector.

Well, I'd suggest 4: vector, scalar, character, object. The "object" 
type would be objects in the OOP sense, not shapes. The library would 
include a standard "string" object to handle characters, "file" objects, 
etc.

Anyway, you might want to look at the CSDL draft I will post in 
povray.off-topic...it is a simulation description language I'm working 
on which will have a library for POV-Ray scene description.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message