If interested here are some of my thoughts on features for the pov4.0
c++
release:

   1. This one is simple and could be implemented now without too much
trouble, but would be very convenient to povers.. we have a union, a
diff.
a ... ect why not a simple group keyword that does not physically
combine the objects just groups them so they can be manipulated as one,
like with translate or scale or something. this info could probably also
used
for calculating bounding slabs.(quicker, more efficiently??)
   2. One should be able to create and delete objects from a scene at
any time.(and a delete group object would recursively remove all the
object contained by that group...)
   3. The pov-core should be like a library, providing basic functions
to other programs. For example, it could define methods like
pov.parser.load_scene_from_file() pov.renderer.trace_scene(), making it
easy for new methods to be added like load_scene_from_binary_file() or
trace_partial_scene() for cluster rendering. these functions in turn
could be called by other
programs,(so that one program might say: load scene, render, write as
jpeg, another as gif, while others might be like modellers, where the
modeler doesn't have to worry about parsing pov-format files, it can
just call load_scene(), maybe even a write_scene(), and
manipulate_scene(), to modify an existing scene(imagine you can make a
change in a pov modeller/editor and then click the render button without
even saving the file and having pov reread and reparse it!!))and the use
would be independent from the
core, which would probably encourage more utilities and generally cool
stuff to be made by and for pov enthusiastic.
note: this would also make it more portable, nothing platform specific
would be included in the core. 
   4. plugable... plugable object types, plugable effects, plugable
cameras.. everything. If this happened, I would even write a
plugger-client/server to connect to the official plug-in site, and offer
all users a easy way to download/install/ any plug-ins.. you could even
have different channels.. ever seen helix-code update???
   5. multiple cameras, why can't I define 10 cameras in one scene, and
then say, pov.renderer.trace_scene(POVCamera camera)
   6. why not give each object, including group objects, and cameras a
name, so it can be easily referenced later(so it can be removed, moved,
scaled, change properties like color...(animator's might like this;>)
   7.  well thats it for now... any opinions?? by the way i don't mean
to be critical of povray, I just wanted to give everybody some stuff to
think about.

Post a reply to this message

In article <399C8823.DD03EB6F@vrml.k12.la.us>, Abe Heckenbach 
<abe### [at] vrmlk12laus> wrote:

> If interested here are some of my thoughts on features for the pov4.0
> c++ release:

I think it should be said again that POV 4.0 will have the source code 
be object-oriented, but the language may be no different than it is.


>    1. This one is simple and could be implemented now without too much
> trouble, but would be very convenient to povers.. we have a union, a 
> diff. a ... ect why not a simple group keyword...
...snip...

Umm, how is this different from union? Pretty much all union does is 
group objects so you can tranform, texture, or CSG all of them at once.


>    2. One should be able to create and delete objects from a scene at
> any time.(and a delete group object would recursively remove all the
> object contained by that group...)

Once an object is in the scene, it should stay there, and stay in the 
same state it was when it was first placed there. If you decide an 
object isn't in the scene, you shouldn't put it there in the first place.


>    3. The pov-core should be like a library, providing basic functions
> to other programs.
...snip...
This sounds an awful lot like the "POV should be/have an API" 
argument...and has been discussed many times. The source code may be 
designed something like this(just for good design practice), but the 
interface may not be available to outside programs.


> note: this would also make it more portable, nothing platform specific
> would be included in the core. 

Organizing the platform-independant core code as separate objects would 
make it more independant, but there still isn't a platform independant 
way of making those functions available to outside programs.


>    4. plugable... plugable object types, plugable effects, plugable
> cameras.. everything. If this happened, I would even write a
> plugger-client/server to connect to the official plug-in site, and offer
> all users a easy way to download/install/ any plug-ins.. you could even
> have different channels.. ever seen helix-code update???

Extremely difficult to do, and practically impossible to do without a 
high cost in speed. The plugins(and the code for dealing with them) 
would have to be cross-platform, so they would either require a compiler 
to be built into the POV application, or they would need to be in a 
byte-code format similar to the way Java is done. Both would be slower 
than a fully optimized compiled version for each platform. If you want 
to modify POV, the best choice is to download the source and make an 
unofficial patch.
And what do you mean by "helix-code update"?


>    5. multiple cameras, why can't I define 10 cameras in one scene, and
> then say, pov.renderer.trace_scene(POVCamera camera)

Umm, where would this line go? In the scene file? I think it would be 
better to stick to the current way of doing it. You can already declare 
multiple cameras and decide which one to use...


>    6. why not give each object, including group objects, and cameras a
> name, so it can be easily referenced later(so it can be removed, moved,
> scaled, change properties like color...(animator's might like this;>)

You can already make a variable, a separate label simply complicates 
things and is inconsistant.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

And what the **** has all this to do with object orientedness?

  It seems to me that most people have a misleading concept on what object
orientedness really means.

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

Post a reply to this message

Abe Heckenbach wrote:

>    6. why not give each object, including group objects, and cameras a
> name, so it can be easily referenced later(so it can be removed, moved,
> scaled, change properties like color...(animator's might like this;>)

This is in the direction of OO-features in the scene language - a popular(?)
topic in these groups. I think what you're thinking of is something like
this:

#declare Foo=difference{
  box{1,-1}
  union{
    sphere{0, 0.5 translate x*1}
    sphere{0, 0.5 translate x*-1}
  }
}

#declare Foo.subobject[1].subobject[0].scale=2;
#declare Foo.subobject[1].subobject[1].location=<-1,1,0>;
#declare Foo.pigment=color{rgb 1};
// etc.

This is exactly the type of features I'd like to see as well - BUT, not for
the price of leaving backwards-compability behind.

(See my longer post in the "Object oriented POV scene language?" thread.)

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


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

Post a reply to this message

Mikael Carneholm wrote:

> (See my longer post in the "Object oriented POV scene language?" thread.)
>

Oops...forgot to mention that it's in povray.programming.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


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

Post a reply to this message

What would be the advantage of transforming subobjects after the CSG has
been declared?
  I think that internally povray would have to create a whole new object
anyways for this.

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

Post a reply to this message

Warp wrote:

>   What would be the advantage of transforming subobjects after the CSG has
> been declared?
>

I think the main advantage of OO (from my point of view) would be _reading_
the location/rotation/scale etc. of objects, instead of (as in the example):
setting the values. Of course, there are also situations when setting the
values of object attributes should be useful, but this (rather meaningless)
example was what I could come up with at the spur of the moment. :)

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


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

Post a reply to this message

>I think the main advantage of OO (from my point of view) would be
_reading_
>the location/rotation/scale etc. of objects

I don't think that will work.  If I'm not mistaken, POV-Ray builds a
transform matrix for each tranformation and keeps multiplying these, so
in the end you'll be lucky for the program to spit out one matrix in the
end.

-Mike

Post a reply to this message

In povray.general Mikael Carneholm <sa9### [at] idautbhbse> wrote:
: I think the main advantage of OO (from my point of view) would be _reading_
: the location/rotation/scale etc. of objects, instead of (as in the example):
: setting the values.

  Sorry for whining, but you (and apparently everyone else) keep calling
this object oriented although it isn't.
  Yes, this is an essential part of an object oriented language, but it's
not object oriented in itself.
  What you are talking about are modules. A programming language can use
modules without being an OO language (for example modula2 is one of those).
These languages have modules which have member functions and member variables,
public and private parts and so on. This, however, is not yet OO.
  For a programming language to be OO it has to have modules as in any
modular language AND it has to have support for inheritance, dynamic binding
and polymorphism. A program is object oriented when it uses these features
(mainly inheritance and dynamic binding). Else it just uses modules.

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

Post a reply to this message

Warp wrote:

>   Sorry for whining, but you (and apparently everyone else) keep calling
> this object oriented although it isn't.
>   Yes, this is an essential part of an object oriented language, but it's
> not object oriented in itself.
>   What you are talking about are modules. A programming language can use
> modules without being an OO language (for example modula2 is one of those).
> These languages have modules which have member functions and member variables,
> public and private parts and so on. This, however, is not yet OO.
>   For a programming language to be OO it has to have modules as in any
> modular language AND it has to have support for inheritance, dynamic binding
> and polymorphism. A program is object oriented when it uses these features
> (mainly inheritance and dynamic binding). Else it just uses modules.

Who said OO-POV shouldn't allow inheritance and polymorphism? If the examples in
my long post does not look like inheritance and polymorphism to you, I apologize.
But, for clarity, here they are, again:

// A "base class" (object) for our worm:
#declare worm_part1=sphere{
 0, 0.5
 pigment{color rgb 1}
 ref{next}  // tells POV that this object has a reference, called "next"
}

// Inheritance...don't you think, Warp? :)
// IDENTIFIER = like ANCESTOR, or actually: SUBOBJECT = like SUPEROBJECT (is
"from" better than "like" maybe?)
#declare worm_part2=like worm_part1{
  pigment{color rgb 0}  // leaves everything like worm_part1, except the pigment.
}

// references can also be declared to "point" to a certain objects from the start:

#declare worm_head=sphere{
 0, 0.5
 texture{some_texture}
 ref{next, worm_part1} // REFNAME [,OBJECT]
}

// Changing the reference of worm_part1:
#declare worm_part1.next=worm_part2;

// Let's create an explicit reference:
#declare temp_ref=ref{worm_head};

// All references are nil:ed from start (if no reference object is
given), so we now can do this:
#while(temp_ref<>nil)
 #declare temp_ref.location = temp_ref.location + <1,0,0>;
 #declare temp_ref=temp_ref.next;
#end

....and this last block would be polymorphism, don't you think, Warp? Well of
course, we don't call common-named methods with different implementations here (as
the well taught OO student points out), but the <object>.location expression is
referencing different object types with common attribute names.

And another thing: OO in POV should be easy enough for everyone to use - one
should not have to study OO theory in order to use it. That's the reason for the
somewhat "crippled" implementation of OO suggested here.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


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

Post a reply to this message