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