>You're quoting the POV-Team, aren't you? LOL

I am?  Since when?

--
Lance.


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

When people suggest good ideas, they often forget one thing: How much does
it cost in speed to implement those ideas?
  In raytracing speed is a critical element. One of the main developing
issues in povray has been the speed performance. Povray 3.0 was a lot faster
than 2.2. Povray 3.1e is a lot faster than 3.0 (at least in sors and lathes).
  You mention that there are actually two kinds of sor objects in povray,
and you insinuate that it's a bad thing. The reason why there are two
different sor objects is explicitly the rendering speed. If you need only
a simpler sor, you can use a much faster version of it.
  Suppose now that we don't have different kind of objects, but just one
"superobject", which you can define in any way. Do you think that this
object will render even nearly as fast as a highly optimized sor object?
  You also comment about the heightfield object. Do you really know why
the heighfield is so limited (for example, you can't wrap the heightfield
around a sphere or whatever)? Yes, the answer is again: speed. The height-
field object in the actual form is very fast to render since many
optimizations can be made due to these limitations. The heightfield object
renders much faster than a general triangle mesh object with the same number
of triangles. And once again: I seriously doubt that the "superobject" would
render even nearly as fast as the heightfield.
  So the reason for the limitations is not that they didn't know how to do
it, but they wanted to do it fast.
  And what about the object-oriented scripting language? The main change in
this would be just a change in the syntax. A change from a clever,
straightforward, BASIC-like script language to a cryptic object-oriented
language.
  Instead of saying "object { MySphere rotate y*20 }" you would say
somenting like "Sphere1=object { MySphere }; Sphere1.rotate(y*20)". There's
no difference between the two things. Just a little bit different syntax.
And all the OO-fanatics are happy because the can "use" "methods"...
  I'm not saying that OO is a bad thing. No, it's a very good thing.
  The problem with it is that you need to learn to think "object orientedly".
  An object oriented approach could be fine in the povscript language, but
not as a substitute, but as an alternative.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Mika wrote:

> Instead of saying "object { MySphere rotate y*20 }" you would say
> somenting like "Sphere1=object { MySphere }; Sphere1.rotate(y*20)". There's
> no difference between the two things. Just a little bit different syntax.

No, no, no.....you really got me wrong there: You still could do like this:
object{ MySphere rotate y*20}. The new thing would be that you could define
methods _if_you_want_ that you could call when needed.

OO-scripting should not replace the current (very user-friendly) scripting - it
should be a complement. A tool you could use if you need to do more advanced
stuff.

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

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