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)

Post a reply to this message

Attachments:
Download 'POV 4 Strategy Proposal.txt' (10 KB)

Sure, while it'd be nice to have stacking like MAX, and object oriented
design, and modula implementation, it would also mean that it would be
harder to make scenes... and t would take longer... you'd have to type more,
you'd have to redesign all your old scenes from scratch... Sure, in programs
like MAX it's easy, mainly because it has an INTERFACE!!!  It's easy to make
a stack, because all objects have one, and all you have to essentially do is
click... but in POV-Ray, can you imagine trying to type all that?  You've
got to be joking right?  I mean, yeah, sure, it would make further
development faster (where like MAX, adding a primitive is as simple as
writing a DLL and droping it in the STD Plug-ins directory), the same would
apply for POV-Ray, just write the new function and away you go... But when
it comes down to it there is an aweful lot of redesigning to be done... a
HUGE amount of redesigning to be done...

Well, I guess if the POV-Team are willing to do it, KEWL!!!  :-)

I don't mean to put a damper on the idea or anything... it WOULD make a lot
of things easier...

Then again, I'm probably not the right person to be commenting on this
because I don't have a huge amount of experiance with C++, so I don't know
how hard it would be to convert everything...

So basically, just ignore this message totally :)

In any case, GOOOOOOO POOOOVVV-RRRRAAAAAYYYYY!!!!!!!!!!!!!!!!!!!!!!  ;-)

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

On Thu, 8 Apr 1999 15:49:03 +0300, Eugene Arenhaus wrote:
>Hi.
>
>Here are some thoughts about what POV-Ray 4 could look like.
>
>The POV team is especially welcome to read. :)

UUencoded text?  Could someone repost this in a newsreader-friendly 
format, like just plain text?

Post a reply to this message

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

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
Högskolan i Borås, Sweden

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
Högskolan i Borås, Sweden

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

About 3ds max.

a) You can't speak to the creators by just e-mailing them, now can you?
b) You are obviously loaded with cash, Lance. (Can I have some?)
c) Long live piracy! (Just kidding... why would I use POV if I could get 3ds...
just kidding again, I _can_ get it, but I prefer POV).

Post a reply to this message

>a) You can't speak to the creators by just e-mailing them, now can you?

       Yes, I can, for example, if I want to know about the up and coming
features in Shiva (MAX 3) then all I have to do is email Frank DeLise...
He's also got a great website by the way... and he also made the opening
sequences for Lost In Space... :)

>b) You are obviously loaded with cash, Lance. (Can I have some?)

       No, I'm not, and no you can't...

>c) Long live piracy! (Just kidding... why would I use POV if I could get
3ds...
>just kidding again, I _can_ get it, but I prefer POV).

       Have you ever used MAX R2.5?  (don't say you've used R1.2 because it
was TERRIBLE!!!)

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

Oh no, don't get me wrong, I'm not trying to put down POV-Ray!!!  I started
in the whole 3D scene with POV-Ray!  I LUV IT!  :)

I'm just saying that MAX is better for MY use because I'm doing work where I
need to render quickly and see the results as I'm altering something.  The
advanced modelling methods like NURBS are also invaluable to me, as are the
post production effects...

All I was saying is that MAX is better for what I'm doing...  Not that it's
better for everyone...  (hey, I can't see Pixar using it... Nor can I see a
lot of the highend guys using it... they use stuff that costs HEAPS more!!!
For example, Maya costs $US 26,000!!!!!!)

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

Hi all,

    I've seen these issue come up a number of times.

    I think one issue is the POV language. I remember there was talk about
this a while back regarding a binary scene language for POV and its plusses
and minuses. I believe the official plan was to clean up the current POV
language a bit and make an official syntax guide for it. This would allow
people to build their own scene language (OOP, stack based, whatever) and
then parse that into the POV format.
    I think this is a pretty good solution. It maintaints backwards
compatibility (as much as possible) but also allows language extensibility.
There is one big minus, though. It still makes it very difficult to use
POV's internal routines during the scene parsing phase. For example, doing
object intersection tests, etc is still not possible. To acheive these
abilities would require either a very large rewrite of POV or significant
work on a new scene language front end. Since that front end would need to
use all of POV's internal algorithms anyway, I think it makes sense to do it
at the corse, i.e., in POV itself.
    So, this brings back up the earlier debate regarding the scene language.
Maybe it is time to create a different POV scene language. One that is very
strictly defined and also has the information retrieval routines (e.g.,
object intersection) that would be so useful. Then someone could put a
"traditional" POV scene language wrapper on top of that for backwards
compatibility.

    Another issue is POV engine growth and extensibility. It is certainly
very important to be able to add new features to POV as they become
desireable and feasible (as CPU become faster and faster). How to do useful
plugins is always a difficult question. The biggest issue here being
portability. It is not fair for only some platforms to have the new plugins.
    Well, one solution I see to this would be having some interpreted
language in POV to create the plugins. This would then, of course, be very
slow. Another solution is to have a more open development system where
contributions can be rolled into official builds more quickly.
    If the development system is opened up then I think that the POV source
code should be made more orderly so that it is easier to add to (I believe
this is planned anyway). Also a good method of evaluating POV patches would
be necessary.
    Personally I'm pretty happy with the POV feature set. My biggest desire
is a different scene language that allows retrieving information from the
POV engine during parsing. Of course some of the recent patches are pretty
cool and I think they should be rolled into the official POV distribution
but not too hastily.

    One other thought I've had was going back to the interpreted idea
mentioned above. I was wondering if a very small, tightly coded, minimum
feature-set of ray tracing could be written and compiled and from that set
additions are added. I do not know enough about the details of a ray tracer
to say too much more but it seems there are things in POV that need not be
in the core of the program. For example, shouldn't there be a more flexible
way to define objects such that there need not be so many different types?
Yes, yes, I know, this would cause a speed hit on the rendering but I'm
wondering if that could be minimized via the scener parser/compiler.
Similarly, all of the warps, turbulations, media, etc should be able to be
emilimated via a very basic system. Perhaps something that allows flexible
object definitions, flexible light definitions, and flexible texture
definitions, and the camera of course. After all isn't that all we need?
Every pov scene is simply objects with textures, light (maybe with texture),
and the camera (maybe with textures). Even media can just be objects with
textures.
    If those 4 things could be broken down into a very basic definition then
everything else could be built on top of that in some scripting language. If
those basics were optimized enough in the main code then perhaps the later
scripting slowness would not be too bad.


    Well, sorry for the length. Just some thoughts. Any input from the POV
team (or anyone else)?


--Rainer

----- Original Message -----
From: Eugene Arenhaus <chi### [at] netvisionnetil>
Newsgroups: povray.general,povray.programming
Sent: 1999?4?8? 21:49
Subject: POV 4 ideology proposal


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

Post a reply to this message

I actually have a friend with 2.5. But, I don't know, I just don't like the
interface, never found it friendly. Now, Bryce and Lightwave, that is a nice
interface! You understand immediately how to use them. Too bad I don't have a
couple thousand just lying around...

Post a reply to this message

Actually MAX 3, from what I've seen of it, has a new interface which is more
like Maya...  I really don't see the problem with it's current interface
though, I thought it was quite intuitive... but then again, that's me!  LOL,
and I'm strange!

I'm not sure now how anyone can really compare MAX to something like LW or
Bryce... because MAX is just so much more advanced!!!  (well, OK, that's in
my very bias opinion... ;-)

I must say though it certainly does like hogging resources :)

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://www.fortunecity.com/skyscraper/parallax/359/colorblind

Post a reply to this message

What's so special about Maya, anyway? I mean, what would justify asking
>$20,000 for a piece of software? I've used ArchiCAD 6.0, which, I believe,
is also an outrageously expensive program. It was nice and comfy, yes, but
there wasn't much I couldn't have done with other, much cheaper utils, with
a bit of inventiveness.
So, what is it about about Maya? Does it wash your dishes? Wax your car? Pay
your bills? Make you popular? What?

Margus

Lance Birch wrote in message <3711f88e.0@news.povray.org>...
>Actually MAX 3, from what I've seen of it, has a new interface which is
more
>like Maya...  I really don't see the problem with it's current interface
>though, I thought it was quite intuitive... but then again, that's me!
LOL,
>and I'm strange!
>
>I'm not sure now how anyone can really compare MAX to something like LW or
>Bryce... because MAX is just so much more advanced!!!  (well, OK, that's in
>my very bias opinion... ;-)
>
>I must say though it certainly does like hogging resources :)
>
>--
>Lance.
>
>
>---
>For the latest 3D Studio MAX plug-ins, images and much more, go to:
>The Zone - http://come.to/the.zone
>For a totally different experience, visit my Chroma Key Website:
>Colorblind - http://www.fortunecity.com/skyscraper/parallax/359/colorblind
>
>

Post a reply to this message

Rainer Mager wrote:
> 
>     One other thought I've had was going back to the interpreted idea
> mentioned above. I was wondering if a very small, tightly coded, minimum
> feature-set of ray tracing could be written and compiled and from that set
> additions are added. I do not know enough about the details of a ray tracer
> to say too much more but it seems there are things in POV that need not be
> in the core of the program. For example, shouldn't there be a more flexible
> way to define objects such that there need not be so many different types?

Hmmm... no.  More flexible means more features means more types of objects.
What do you want?  To always start with a sphere and have to deform it into
the object you want?  Always define your objects as an isosurface?  Use only
triangle mesh objects?  I don't think many people would be happy.

If you think POV has too many options/objects/textures, take a look at 3DS
MAX... the features there (especially when you add plugins) are practically
endless (MAX gave me a headache the first time I used it, but I think the
multitude of features are quite useful).

My opinion:  more object types = more flexibility and speed = better system.

> Yes, yes, I know, this would cause a speed hit on the rendering but I'm
> wondering if that could be minimized via the scener parser/compiler.
> Similarly, all of the warps, turbulations, media, etc should be able to be
> emilimated via a very basic system. Perhaps something that allows flexible
> object definitions, flexible light definitions, and flexible texture
> definitions, and the camera of course. After all isn't that all we need?
> Every pov scene is simply objects with textures, light (maybe with texture),
> and the camera (maybe with textures). Even media can just be objects with
> textures.

Well, technically it's in the object's interior, not it's texture.

>     If those 4 things could be broken down into a very basic definition then
> everything else could be built on top of that in some scripting language. If
> those basics were optimized enough in the main code then perhaps the later
> scripting slowness would not be too bad.

In raytracing, it think that it's safe to say that EVERYTHING should be
optimized, not just the very basic stuff.  Slowness is never "not too bad",
unless there is no other way to solve the problem.

-Nathan Kopp

Post a reply to this message

Oh, I forgot to say...

I LOVE the idea of a brand new scripting language for POV with an old
compatibility-wrapper put over it!  I don't think the current syntax
really has what it takes to get things done, since it can't access
and the properties of object instances or access many rendering
engine features.

-Nathan

Post a reply to this message

> Actually MAX 3, from what I've seen of it, has a new interface which is more
> like Maya...  I really don't see the problem with it's current interface
> though, I thought it was quite intuitive... but then again, that's me!  LOL,
> and I'm strange!

_I_ didn't find it intuitive. Also, MAX3, AFAIK has several interchangeable
interfaces, from what a friend told me, he got this info. from a beta tester.

> I'm not sure now how anyone can really compare MAX to something like LW or
> Bryce... because MAX is just so much more advanced!!!  (well, OK, that's in
> my very bias opinion... ;-)

I never said that Bryce or Lightwave compare to MAX in power, just that their
interfaces are MUCH more user-friendly.

Post a reply to this message

Yeah, I know someone who has a copy of the beta already :)

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://www.fortunecity.com/skyscraper/parallax/359/colorblind

Post a reply to this message

Maya, well, it's good... not the BEST, but as good as you'll get in that
price range...

It has an extremely advanced, automated and fast character animation system
and also very advanced NURBS modelling techniques... Inverse Kinematics,
Dynamics system... It has soft-body animation too, so you can get really
realistic characters... It's particle systems are HIGHLY advanced, they can
model water, liquids, interparticle reaction, fire, smoke etc... It is also
built to run on SGI, and generally software designed for SGI is more
expensive inherently because it takes longer to develop for such a platform
(to take advantage of the G-Pipelines and advance graphics acceleration).

There are more expensive programs of course, I'm just speaking of a
particular range here...

Basically it's the top of the high-end graphics range, then there is like
the
"ultra-expensive-we-designed-this-for-ourselves-because-we-have-millions"
range... Like Pixar and ILM :-)

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://www.fortunecity.com/skyscraper/parallax/359/colorblind

Post a reply to this message

"Eugene Arenhaus" <chi### [at] netvisionnetil> writes:

> Here are some thoughts about what POV-Ray 4 could look like.

I've read all this over and over, and I still have the same remarks.
I cannot believe I have kept in such a bad mood for the last five
days, so I guess at least a bit of what I'm about to say is right.

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

  Huuh?  See the number of patches that are published these days?

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

  Whaaaat?  Are you *really* meaning that?  Backwards compatibility
not to be considered a major requirement?  Makes me jump on my seat
each time I read that.  How dare you speak of easy extension if you
abandon backward compatibility?

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

  Why is it so, in your mind?  Lemme think...  Maybe because it's the
way it is in real life.  A real object has a shape and a material.  A
raytraced object has a model for its shape (to be chosen in a set of
different models) and a model for its material (including texture,
interior, refraction etc.).  Different properties mean different
implementations. 

> The proposed model, on the contrary, would allow all objects use any
> properties freely and interchangeably.

  Yeah, like you're going to use a center and radius for a texture
map.  Or a area_light for a sphere.

[...]

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

  Of course they have!  They are different things!  Why would you want
them to behave like an atmosphere?

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

  Yes, that should have been done ages ago.  Give those haloes a slope
map!  They need it!  What for?  Uh, lemme think...  Consistency with
normal maps, that's it.  Ah, but then the quadric primitive also needs
atmospheric attenuation, doesn't it?

> (No more specially preparing image files for height fields.)

  You'll have to forgive me for that, but that sounds like one of the
biggest pieces of nonsense I've ever heard.  How do you intend to
generate height fields without specially prepared images?  Randomly?

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

  Variable IOR means bent rays, which is kind of a huge piece of work
to do.  I agree on the use of these features, though.

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

  Sounds to me like simplicity just gets killed on the way.

>  Implementation issues 
[...]
> 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.

  So you want, instead of having each object perform the task it's
meant for, to have any object perform any operation *at all*.  I still
cannot understand.

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

  Whaaat?  Object-oriented scene description language?

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

  Wake up man, you're *describing scenes*, not programming!  Is life
object oriented?  Are your car and fridge objects with attributes and
methods?  How often do you call the tap.open() or the window.close()
functions? 

> This would largely eliminate the problems with making complex
> objects, and make for smaller and cleaner scene files.

  Yes, of course.  Replace every single parameter with a function
call.  You call that readability?  And small?

Sphere Left_Eye_Ball is
  Radius : Float := 1.0;
  Center : Vector3 := <0.0,0.0,0.0>;
  Texture := new Texture_Type;
  Texture.Pigment := new Pigment_Type;
  Texture.Pigment.Type := Bozo;
  Texture.Pigment.Turbulence := new Map_Type;
  Texture.Pigment.Turbulence.Type := Gradient;
  Texture.Pigment.Turbulence.Direction := <1.0,0.0,0.0>;
  Texture.Pigment.Turbulence.Map := new Map;
[...]
end Sphere;

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

  And dramatically slow down the parsing and tracing.  Remember,
compilers were invented some time ago to produce fast code.

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

  Could be nice.

>  Dynamic modular internal architecture

  Yeah, object oriented programming, in a word.

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

  Er...  Does this conclude anything?

  This text sounds to me like it's full of ideas.  I'm afraid most of
them are bad ones, though.  Let's sum them up.

- Abandon backward compatibility.  This is a *huge* contradiction of
  all programming principles.  (Unless of course you work for
  Microsoft, but that is not my point.)  Abandoning compatibility
  means throwing all external programs to the dustbin.  You can't
  seriously do that.
- Unify primitive interfaces.  This implies to switch from a realistic
  model (based on how the world works) to a programmingly nice model
  (based on how abstract object oriented programs work).  No, no, no,
  the raytracer uses models inspired from reality, not models that
  make it easy to program!
- Object oriented scene description language.  Means complexity.  You
  cannot expect a beginner or even a programmer to support all the
  hassle of object oriented programming just to describe a scene.
  Boy, if the scene comes from an object oriented vision of life, then
  use a scripting language to generate your scene, such as Perl or
  Python!  Programming is out of the range of a *description*
  language. 

  My conclusion: you're trying to make the raytracer stick to a very
abstract programming model rather than to how it works (remember, it's
used to simulate the way light behaves in a given environment).
You're trying to make the program an abstract one, instead of making
it easy to use.  You're trying to make POV-Ray a programming language
instead of keeping it a raytracer.

  I want to keep POV-Ray as an engine to trace!  Complex scenes are
described by complex files, and if I do not want to write complex
files then I use Perl.  With all the objects that I need.  I want to
be able to use my old Perl scripts with the new POV-Ray.  I want to be
able to write quick-and-dirty scenes without those objects.  I want to
describe scenes as they are (objects with textures) and not as they
are represented inside the engine.  And I want them to be represented
as they are and not according to some abstract and confuse model, so
that I can write new primitives when I need them.

  Ladies and gentlemen, thank you for your attention.

P.S: I have only six months of object oriented programmation behind
me (alright, that was only C++, but many consider it to be a real OO
language), many years of POV-Ray, and although I still don't see why
there is such a buzz about OO programming, all my frustrations in
POV-Ray scene description language have been solved by the -i-
option.  The #while, #for and other directives are rarely used by me.
-- 
Roland Mas

A man walks into a bar.  Bang.

Post a reply to this message

I agree with all your thoughts... nuf said :)

Oh, and add translucency to the list of new features ;-)  he he he  Sorry,
but I just couldn't resist it!

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://www.fortunecity.com/skyscraper/parallax/359/colorblind

Post a reply to this message

Roland Mas wrote:

 Yes, of course.  Replace every single parameter with a function

> call.  You call that readability?  And small?
>
> Sphere Left_Eye_Ball is
>   Radius : Float := 1.0;
>   Center : Vector3 := <0.0,0.0,0.0>;
>   Texture := new Texture_Type;
>   Texture.Pigment := new Pigment_Type;
>   Texture.Pigment.Type := Bozo;
>   Texture.Pigment.Turbulence := new Map_Type;
>   Texture.Pigment.Turbulence.Type := Gradient;
>   Texture.Pigment.Turbulence.Direction := <1.0,0.0,0.0>;
>   Texture.Pigment.Turbulence.Map := new Map;
> [...]
> end Sphere;
>

No, no, no.....this is not what it should be like. Look, I bet you have done
this a couple of times:

#declare SomeSphere=sphere{
    <0,0,0>, 0.5
    pigment{color rgb <1,0,0>}
}

object{
    SomeSphere
    // added rotations, tranlations etc.
}

This is already pretty close to OO scripting!  (SomeSphere is the "class" and
it is instanced with object{})
Now, what we can't do with the current version is this:

#declare SomeSphere.position=SomeSphere.position+<0,1,0>;
#declare SomeSphere.radius=1.5;
#declare SomeSphere.pigment=pigment{color rgb<0,0,1>};

This could be very useful.

AND, it should be fully backwards compatible with previous versions (1-3),
i.e, you should still be able to do like this...

sphere{
    <0,0,0>, 0.5
    pigment{color rgb <1,0,0>}
}

...to see a red sphere render on your screen (as the "instant" instance of
the "class" sphere{} it actually is, when you think of it...).
It's only, it would be nice to be able to access the different attributes via
dot(.) notation.

POV scripting has always been a simplified programming language - let's keep
it so.
Introducing OO scripting in POV should be done in the same spirit - powerful,
yet simplified.
POV spirit. THE spirit.

Regards,

- Mikael.

-----------------------------------------------------------------
Mikael Carneholm
Dep. of Computer Science
Högskolan i Borås, Sweden

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

Post a reply to this message

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

Mikael Carneholm <sa9### [at] idautbhbse> writes:

> This is already pretty close to OO scripting!  (SomeSphere is the
> "class" and it is instanced with object{})

Sure.  Why change that?

> Now, what we can't do with the current version is this:
> 
> #declare SomeSphere.position=SomeSphere.position+<0,1,0>;

#declare SomeSphere = object { SomeSphere translate y }
Does exactly it.

> #declare SomeSphere.radius=1.5;

I'm not sure it really cannot be done.

> #declare SomeSphere.pigment=pigment{color rgb<0,0,1>};

#declare SomeSphere = object { SomeSphere pigment{color rgb<0,0,1>} }
Does exactly it.

Anyway, what's the use of all that?  Want to have another sphere,
redeclare it.  Or better, if it's another sphere, use another object.
-- 
                                                         Roland Mas

Post a reply to this message

Roland Mas wrote in message ...
>
>  Huuh?  See the number of patches that are published these days?
>

Indeed. But there are a number of very useful things, like non-linear
transformations, which, IMHO, can't be done - not without very substantial
core modifications.


>
>  Whaaaat?  Are you *really* meaning that?  Backwards compatibility
>not to be considered a major requirement?  Makes me jump on my seat
>each time I read that.  How dare you speak of easy extension if you
>abandon backward compatibility?
>


I tend to agree, backward compatibility is important. Otherwise, the work of
many people, in the form of plugins, tutorials etc. would come to nothing.
But this should not be a dogma. Some compatibility will have to be
sacrificed, and has been sacrificed before, to facilitate future
improvements.

>> (No more specially preparing image files for height fields.)
>
>  You'll have to forgive me for that, but that sounds like one of the
>biggest pieces of nonsense I've ever heard.  How do you intend to
>generate height fields without specially prepared images?  Randomly?
>

Internally. This is already possible in the Superpatch. In essence, you
assign a height pattern, like a normal pattern. No need to create a separate
scene, plane, orthographic camera etc., render it and use the resulting
bitmap for the heigtfield.

>  Variable IOR means bent rays, which is kind of a huge piece of work
>to do.  I agree on the use of these features, though.
>


I suppose this _could_ be simulated with volume sampling, like in media. But
that's my uneducated guess.

>
>> 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.)
>
>  Wake up man, you're *describing scenes*, not programming!  Is life
>object oriented?  Are your car and fridge objects with attributes and
>methods?  How often do you call the tap.open() or the window.close()
>functions?
>

You could call it programming (well, scripting). How much so, depends on the
particular user. And of fourse POV _objects_ are objects, and can be
instanced with different attributes. But I know too little about OOP to make
any definitive case here.

Margus

Post a reply to this message

On Tue, 13 Apr 1999 20:09:27 +0300, Margus Ramst <mar### [at] peakeduee> wrote:
>Indeed. But there are a number of very useful things, like non-linear
>transformations, which, IMHO, can't be done - not without very substantial
>core modifications.

Even if POV were completely object-oriented internally (which it will
be, someday) non-linear transformations (and other displacements) would
still require substantial modifications.  You still have to modify every
object, whether they're real "objects" or just the simulated "objects"
they are now.

Post a reply to this message

Ron Parker wrote in message <37138cb5.0@news.povray.org>...
>
>Even if POV were completely object-oriented internally (which it will
>be, someday) non-linear transformations (and other displacements) would
>still require substantial modifications.  You still have to modify every
>object, whether they're real "objects" or just the simulated "objects"
>they are now.
>

OO wasn't exactly what I was talking about here. More along the lines of the
modular design concept. While I am by no means familiar with the
technicalities, I am under the impression that integrating new features
(processes, objects etc.) is more difficult than it need be. You tell me,
you know better.

Margus

Post a reply to this message

On Tue, 13 Apr 1999 22:22:40 +0300, Margus Ramst <mar### [at] peakeduee> wrote:
>OO wasn't exactly what I was talking about here. More along the lines of the
>modular design concept. While I am by no means familiar with the
>technicalities, I am under the impression that integrating new features
>(processes, objects etc.) is more difficult than it need be. You tell me,
>you know better.

Adding new objects, assuming you can provide the necessary functionality
for them, is simplicity itself.  Likewise with new textures and warps.  The 
only thing most people might have trouble with is adding keywords to the 
parser, but even that isn't really all that hard if you follow the existing
examples.  Unless you're doing something like the isosurface patch that
makes massive parser changes, but even those hook into the existing code
in relatively few places.

Adding new functions, like trace() or min_extent(), is fairly easy.  Again,
these are small parser changes that are easy once you know where to make
them.

Adding new global functionality like U-V mapping or displacement mapping or 
nonlinear transforms, however, requires a change to every object type.  Even
in a more modular world, this would still be the case.  If I need to add a 
"give me a triangle mesh" function to the base class, I will either need
a default implementation of it, or someone will have to add it to each and 
every derived class.  From a non-OO, modular standpoint: if I add that function 
to what's expected from an object, every plugin will have to change.  The 
issue here, for those who have worked with COM or CORBA or Java, is that the
*interface* to an object is changing and requires all implementations of that 
interface to change.  Nathan has gone the default-implementation route with
the UV patch, and I suspect the displacement stuff, if it is ever added, will
be done similarly.  That part could be made easier with a modular or OO 
approach, in that you'd only have to change the nondefault implementations.
I don't see any way of making the rest easier, though.

Other patches like dispersion and photon mapping and blurred reflection and 
so forth are fairly localized already to whatever piece of functionality 
they affect (all lighting code, in these cases.)  Modularity wouldn't help
much there, because the code in question is already in only one place.

Another (potential) kind of patch adds functionality to the language itself,
like the old #macro patch.  These are purely parser changes, and some are
easier than others.  I don't know of any current examples of such patches.

Finally, there are patches like my motion-blur patch that change lots of
fundamental data structures.  Modularity won't help much there.

Perhaps what we need more than modularity is documentation of how patches are
done.  I think DSW is working on that, but I'm sure he could use our help.

Post a reply to this message

"Margus Ramst" <mar### [at] peakeduee> writes:

> Roland Mas wrote in message ...
[...]
> >  Variable IOR means bent rays, which is kind of a huge piece of work
> >to do.  I agree on the use of these features, though.
> >
> 
> 
> I suppose this _could_ be simulated with volume sampling, like in
> media. But that's my uneducated guess.

Yes, sure.  But it would anyway imply a huge lot of calculations,
because the ray is bent all along its path and not just on a few
points of it.  Which means: a *big* number of samples.  Each of them
needing to calculate a ior local gradient.  Sloooow.

Would be nice, though :-)  For all of us who had to model the path of
a laser in a fiber, by writing a C program...
-- 
Roland Mas

Autumn leaves are brown...  And the sky is gray...
  -- California Dreaming (The Mamas and the Papas)

Post a reply to this message

Ron Parker wrote in message <3713af5d.0@news.povray.org>...
>
>Perhaps what we need more than modularity is documentation of how patches
are
>done.  I think DSW is working on that, but I'm sure he could use our help.

This would indeed be invaluable. I only wish I could help. But I'm afraid I
can't. Until it is complete - or I manage to familiarize myself with the
inner workings of POV in some other manner - I will defer any further
arguments over the goods and ills of POV's sructure.
I still think a plugin architecture would greatly facilitate implementing
many new features. But I will not start this dispute all over again.

Margus

Post a reply to this message

Margus Ramst wrote:
> 
> I still think a plugin architecture would greatly facilitate implementing
> many new features. But I will not start this dispute all over again.


And I still agree with you and later this summer might start working on
something.  (I think Ron was going to play with something related to this
too).

-Nathan

Post a reply to this message

For all of you who dislike the concept of object oriened POV script, I think
one thing should be clarified.  At least some of us are proposting a semi-
object oriented language... where we implement the encapsulation and (in a 
wierd way) inheritence, but NOT data hiding.  That means you can access
parts of an object but you don't have to do so through methods.

The main reason I want to do this is because I think that for POV go get
better for animation, it needs to be able to do an entire animation from
a single script WITHOUT RE-PARSING BETWEEN FRAMES!!!!!

How would this look?

-----------------
#declare myCam = camera{...}

#include "big_tree_macro_takes_forever_to_parse.inc"

#declare myTree = object{MakeTree() translate ...}

#declare fr=0;
#while (fr<10)
  myCam.translate <...>        // translate acts like a method
  #declare myCam.angle = ...;  // angle acts like a property
  
  clearFrame()    // special function that clears all objects from scene

  global_settings{...} // global settings for this frame

  // now we put our objects in the scene
  camera{ myCam }   // use the new camera settings
  object{ myTree }  // and no need to re-parse the tree

  // now we render
  RenderFrame(fr)  // a special function that renders the frame (filename
                   // based on the parameter

  #declare fr=fr+1;
#end

--------------------

Now, I want to make a comment about that statement were translate acted like
a method.  You see, in some ways I'm beginning to think that POV should
follow the same ideology as Perl.  The April 1999 Communications of the ACM
has a great article by Larry Wall (original author of Perl) called "The
Origin of the Camel Lot in the Breakdown of the Bilingual Unix".

The article talkes about the Perl community (which reminded me much of the
POV community).  Larry Wall also talked about how Perl was designed to be
a language like a human spoken/written language... one that is kind of
ad-hoc and NOT minimalistic like so many other languages.

A quote from the article: "People who hype orthogonality should be
sentanced to draw everything with an Etch-a-Sketch."

I found the article very enlightening, since I have in the past been
pro-minimalistic, thinking a grand-unified-appoach would be best.
So, maybe we should let the POV scripting language evolve in a way that,
as somebody else mentioned, makes sense to the humans, and then we'll
force the computer to understand.  ;-)

In a previous post I mentioned that I would appreciate a re-write of the POV
language... but as I've thought about it more, the POV scene description
languate is pretty good... some of the things that have been suggested
would actually be going BACK to POV version 1.0 syntax... it must have
been changed for a reason (because people didn't like it the old way).

I've done quite a bit of programming inside POV, and it is really
relatively easy to add functionality to POV.  Adding new keywords to
the parser is really simple, IMHO.  Adding new objects is also
relatively easy (and orthogonal... yes, I still have quite a bit of OO
blood in me).

Adding the photon map was alot easier that many of you probably think it
was.  It required very localized changes to the core of POV.  And I
really doubt if the photon mapping could have been implemented via a
plug-in of any sort unless someone had thought of it when designing the
plug-in interface.

Well, that's my current thoughts on the topic.

One last thing... I really don't like typing #declare... I've got some
ideas on how to 'fix' this, but they should go in a different thread.

-Nathan

Post a reply to this message

Hey, Chris Young says that adding an optional double_sided shaded keyword to
finish is being considered.  If it could be given an amount, you got yourself
some translucency!

-Mike

Lance Birch wrote:

> I agree with all your thoughts... nuf said :)
>
> Oh, and add translucency to the list of new features ;-)  he he he  Sorry,
> but I just couldn't resist it!
>
> --
> Lance.
>
> ---
> For the latest 3D Studio MAX plug-ins, images and much more, go to:
> The Zone - http://come.to/the.zone
> For a totally different experience, visit my Chroma Key Website:
> Colorblind - http://www.fortunecity.com/skyscraper/parallax/359/colorblind

Post a reply to this message

er... sure about that?  I don't know, wouldn't that just mean that the
object has kind of like a double sided thickness?  I mean, translucency is
something that carries THROUGH the object...

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://www.fortunecity.com/skyscraper/parallax/359/colorblind
Mike wrote in message <371### [at] aolcom>...
>Hey, Chris Young says that adding an optional double_sided shaded keyword
to
>finish is being considered.  If it could be given an amount, you got
yourself
>some translucency!
>
>-Mike
>
>Lance Birch wrote:
>
>> I agree with all your thoughts... nuf said :)
>>
>> Oh, and add translucency to the list of new features ;-)  he he he
Sorry,
>> but I just couldn't resist it!
>>
>> --
>> Lance.
>>
>> ---
>> For the latest 3D Studio MAX plug-ins, images and much more, go to:
>> The Zone - http://come.to/the.zone
>> For a totally different experience, visit my Chroma Key Website:
>> Colorblind -
http://www.fortunecity.com/skyscraper/parallax/359/colorblind
>
>
>

Post a reply to this message

Lance Birch wrote:
> 
> er... sure about that?  I don't know, wouldn't that just mean that the
> object has kind of like a double sided thickness?  I mean, translucency is
> something that carries THROUGH the object...

What do you mean by "through" the object?  Maybe you do want media?
Or maybe what you're looking for is a mixture of double-sided shading
and a bit of filter/transparancy (or no_shadow).

I think that the double_sided keyword should take a float value that is
used to attenuate the shading for the 'wrong' side.  That would add a 
bit more flexibility.

-Nathan

Post a reply to this message