 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Original message, in plain text:
(Note the original writer is not I; I'm only reposting..)
----------------------------------------------------------------------
POV 4 Strategy Proposal
Author: Eugene Arenhaus, chi### [at] netvision netil
For the information of: POV-Ray team, 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Eugene,
You have a lot of great ideas here, and I'm going to think about them more
before I offer any major comments. However, I have a few observations to
add right now.
First, while I long for the fully object-oriented internal design that you
call for, such a design would require an object-oriented language, such as
C++. Have all of the compatibility problems with C++ been worked out yet?
ANSI C (the current language of POV) is highly portable... is C++ just as
portable?
Eugene Arenhaus wrote:
>
> 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.
>
I agree. The POV 3 code (both the scriptiong language and the C source
itself) is somewhat inconsistent in places... I agree that a rewrite to
make it more modular would be great (maybe necessary).
> Hierarchical, layered object model
I don't fully understand this hierarchal layered object model. How would
this look when put to use? I don't use MAX (no $$$), so I can't use that
as a reference.
> 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.
I understand both of your examples (the MAX modifier stack and material
maps), but I don't understand the 'stacking' concept. I can see, from an
OO point of view, the 'Sphere' class being inherited from the
'GenericObject' class... but would you go further and make it so you
could put a 'box' on top of a 'sphere' in a stack? If so, what would
happen? Would the box simply replace the geometry of the sphere but
keep everything else intact?
> 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.
The blob example might look great in theory, but could be extremely
difficult to put into practice. Current blobs only handle spheres,
cylinders (and maybe cones?). Trying to base a blob on a SOR object
could make for some horrific math... and how would you base it on
an unknown object (since we wouldn't want blob to be changed when
a new object is added).
>
> 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.
Some of these make-the-maps-consistent ideas could actually be implemented
relatively easily in POV 3 (at the cost of backwards compatibility). In
fact, some of them have. The superpatch has the image_pattern pattern,
which allows you to use a bitmap image as a POV pattern, and it also
has the ability to generate a bitmap (for use in a heightfield) from a
pattern. I think these features need to be fully merged together,
though, as you suggest.
> 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.
I disagree with doing away with the height field. The current height
field is much faster than a general displacement map would be. There are
many speed shortcuts that can be taken when rendering the displacement
map of a plane that could not be applied to the general displacement
map. Plus, implementing the general displacement map requires
implementing a primative->triangle conversion for all objects (including
CSG) which nobody has done for POV yet.
> 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.
I disagree. I think a distinction must be made between objects, materials,
pigments, finishes, ...
Looking at it from OO again, "a sphere HAS A material" is true, not
"a sphere IS A material". However, "a sphere IS A object" would be
correct.
While the concept of everything being the same is appealing (and I
might like it more after some further thought), my initial thought
is that it would be inefficient and confusing.
More comments to come later.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OO scripting is what I would like to see as well. Like this:
// This is a "class"
#declare MySphere=sphere{
<0,0,0>, 0.5
pigment{Red}
attribute rot_direction
attribute rot_speed
// This is a "method"
#macro Rotate()
rotate rot_direction*rot_speed
#end
}
// An instance (like before)
object{
MySphere
}
// Accessing the attributes
#declare MySphere.position=<3,1,5>;
#declare MySphere.size=MySphere.size+0.3;
#declare MySphere.pigment=pigment{rgb <0,0,1>}
#declare MySphere.rot_direction=<0,0,1>;
#declare MySphere.rot_speed=30;
// Calling of a method
MySphere.Rotate()
Note the fourth & fifth line after the pigment{} line! This is my
suggestion to letting the object have attributes that works as regular
variables, but in a POV-Ray manner. The keyword "attribute" means
"universal type", that works just as we're used to in POV-Ray:
- once declared as type [X], the identifier is always of type [X].
(Of course) position, size and pigent etc. has to be reserved words.
---
Collision detection is the next big thing. One suggestion is to use an
overlap directive that returns true or false, like this:
#if (overlap{MyBox MyPlane})
MyBox.rot_dir=MyBox.rot_dir*-1;
#end
NOTE:
This would not change anything for those who just want to make instant
scenes. You can still "create an instant instance" like you always did in
POV-Ray. And you can still #declare Something=something, and then make an
instance with object{} like before.
The new thing is the attributes (reserved or not) and usage of #macro as
class method.
Just my 2 cents....
Regards,
- Mikael.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> OO scripting is what I would like to see as well. Like this:
>
> // This is a "class"
> #declare MySphere=sphere{
> <0,0,0>, 0.5
> pigment{Red}
> attribute rot_direction
> attribute rot_speed
> // This is a "method"
> #macro Rotate()
> rotate rot_direction*rot_speed
> #end
> }
>
> // An instance (like before)
> object{
> MySphere
> }
>
> // Accessing the attributes
> #declare MySphere.position=<3,1,5>;
> #declare MySphere.size=MySphere.size+0.3;
> #declare MySphere.pigment=pigment{rgb <0,0,1>}
> #declare MySphere.rot_direction=<0,0,1>;
> #declare MySphere.rot_speed=30;
>
> // Calling of a method
> MySphere.Rotate()
If this is what OO scripting looks like, then YUCK! I like POV script as it
is. Sure, a few extras (SuperPatch stuff) would be nice. But, not rewriting
the whole thing. Also, that idea of putting all the maps in a single group is
good. What would that command look like?
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. If you want to
change the source-code of POV to make it _faster_, that's fine by me, but
please don't change what it IS. I don't really want to change it to something
so different. One thing that would be nice, someday in the future would be
that displacement map thing, but until then, I'm happy (when it comes I'll be
really happy).
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. =)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I get very concerned when I read letters like this
I am just about able to write a simple program - have never been able to
learn the subtlties - lack of time(job,family etc)and do not understand the
deeper complexities of computers. My maths is limited and my brain getting
creaky!!
I like pov as it is it's simple intuative and suits my haphazared, artistic
way of working.
Yes I'd like to see improvements in speed and extra facilities but not at
the expense of usability.
Pov is pretty damm good there aint a lot you can't do with it.
Pov can be accessed by a wide range of users with a wide range of motives.
I would hate to see it become the preserve of a computer literate elite more
concerned with the structure then the output.
Just my little outburst I'll go back to my box now!
Mick
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
he he he, yeah... I think it's good to improve on something, as long as it
doesn't mean the user's going to be disadvantaged by it and find it harder
to use...
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You're quoting the POV-Team, aren't you? LOL
Lance Birch wrote:
>
> he he he, yeah... I think it's good to improve on something, as long as it
> doesn't mean the user's going to be disadvantaged by it and find it harder
> to use...
>
> --
> Lance.
>
> ---
> For the latest 3D Studio MAX plug-ins, images and much more, go to:
> The Zone - http://come.to/the.zone
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto:inv### [at] aolcom?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>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)
|
|
| |
| |
|
|
|
|
| |
|
|
