Anthony Bennett wrote:

> Also, about that man's ideas: they're sorta good. I don't like the idea of 0
> backward-compatibility. That sucks. I really did not understand what he
> wanted to do with stacks. He really lost me on that point.

This is exactly what I didn't mean: It should _not_ be totally re-written, just
expanded with some new possibilities. It would be _optional_ to have attributes
in an object, and it would be _optional_ to have methods for an object. You could
still do like you're used to, like this:

box{
  <>,<>
  texture{}
}

...and it would still render as a beautiful box, without first being declared as
a "class" and instanced with object{}. But, I personally would like to have the
option to declare it like this:

#declare MyBox=box{
  <>,<>
  texture{}

  attribute speed;
  attribute direction;

  #macro Move()
    translate speed*direction
  #end
}

What I miss most is being able to access the different parts of an object like
the position, size, texture etc. If those were accessable via dot
notation(.position, .size, .texture etc) things would light up a great deal.

Once again, do not remove the backward-compability, just add some new features
that expands the scripting language and that can be used _optionally_.

- Mikael.

-----------------------------------------------------------------
Mikael Carneholm
Dep. of Computer Science


http://www.studenter.hb.se/~arch
E-mail: sa9### [at] idautbhbse

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

> Once again, do not remove the backward-compability, just add some new
features
> that expands the scripting language and that can be used _optionally_.


Now that is a good idea

Mick

Post a reply to this message

Hi,
I personally like the idea of POV4 moving quite a mile. And it should,
considering the change that came along the path from 3.0 to 3.1 :-). And
for the unix-folks even a through e is very significant.
But reading about extensions of POVRay I usually find a mixture of three
very different problems:

a) Writing a good raytracer
b) Writing a good scene description language
c) Writing a good programming language and interpreter

Each and every one of them is well suited to fill up some books, several
lectures or some non-profit organisation. And in general moving from
'good' to 'best' is impossible.

The main problem in my eyes (and the best point in Eugenes proposal) is
the closed architecture of POVRay. I know, that it's religion, but that
would be a major step.

I happen to switch tools faster than anything else, and I will stick to
create scene files with Perl and matlab, just because I don't want
POVRay to be good in solving eigenvalue problems :-)
Exhibiting a well documented interface to what happen to grow an
object-tree sometime, will open up grand new possibilities and at the
same time bring down the load on the POVTeam.

They then may proceed in writing THE BEST raytracer around.

Axel

Post a reply to this message

Interesting ideas.

Some thought should be given as to what purpose
is being served by POV-Ray's scene description
language. If people are writing directly in it,
then making the language easier to write in
is merited. If the language is meant to act
as an interface between the renderer and
other applications (like PostScript), then
parsing speed, file size efficiency, and
availability of atomic features that can be
scalably combined should be foremost.

It is often the case that the two situations
tend to be mutually exclusive. Programmers
write in C++, for example, but this code
is then compiled into a form that CPUs
can better deal with. One can write in
machine code, of course, but few bother.
Over time, compiler evolution has produced
a design that gives programmers most of
what they need without seriously degrading
execution performance.

The creation of a more user-friendly
scripting language should likely be done
as a separate front end, whose syntax is
then translated into what POV would use.
A front end that is 3.x compliant can be
written to provide a bridge to 3.x users.
Many front ends, of course, would be
modellers.

Ray

Post a reply to this message

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

I always thought that a good idea would be to split up POV into the
raytracer and scripting language...the poor POV team has way too much work
to do by maintaing both things..and it shows in that it takes longer to
update things and improve them...
What about taking one of those interpetied languages liek Perl, Sather,
Scheme, Lisp or something and write the interpiter code to give a robust
environment for coding and hook them to the compiled libraries that do math
intensive stuff the actual raytracing.I think you can do this in at least
one of the above mentioned...although it would be a big thing for the POV
team to side with a single existing language...

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

[...]
>What you should do is speed it up with assembly. I spoke with a fellow and he
>factored in an at least 10% speed increase. Can you imagine 10%? I mean what
>would mean you could finish rendering that much faster. Think like this: 24 h
>render = 21 1/2 h render. I don't know about you, but those hours are
>appreciated where I come from. Maybe you could toss in that scanline render
>thing like in 3DS Max, and only use raytracing on reflective surfaces. Or
>maybe I'm wrong. I just write as the ideas come. =)

It's better to direct any speed-issues to the people who write instruction
schedulers and compiler libraries.

Why not use 3DS Max if it has the functions you need?


 /j

Post a reply to this message

Jan Danielsson wrote:

> Why not use 3DS Max if it has the functions you need?
> 
>  /j

It lacks charm and personality. I costs a lot too.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Sorry, I just HAVE to comment on that one...

If you ask me it has PLENTY of personality and charm!!!  :)

It's a fast and efficient renderer too... and when it is used correctly
(which it unfortunately almost never is... because of all the non-dedicated
pirate users) it can create some of the most fascinating images I've ever
seen...

The cost is minimal for what you get in return...

But then again, you didn't ask me did you?  :-)

(You know you've been raytracing too long if you've ever gotten into a flame
war over renderers)

Lance.

P.S.  Plus, I'm a huge MAX supporter as you know so of course I can't say
enough good things about it :-)  Can't wait for R3.0 - SHIVA!  WOOHOO!

---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

The cost is NEVER minimal.
The cost is NEVER Minimal!!!


(I had to repeat that. ;-)

Seriously, now, I would NEVER have been raytracing if there were no POV.
Since it is free, there is no comparing to ANYTHING else, no matter how
much better.

And besides, POV is great!

Post a reply to this message