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

sorry, my mistake, I was thinking that a union could only be used for
objects physically connected, and that it would be nice to be able to
manipulate a group of objects as one, with out changing the final
image..(though I guess image mapping might look different).

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

I meant for animations, interactive 3d, ect. where you would want to
change objects arbitrarily from any point, like switching a virtual
light switch to remove(or just make invalid) a light source, for
example.

> 
> >    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.
> 
there are over 20,000 messages in this newsgroups, so there is no way I
could just read them all to see if the topic had been discussed.  I
really think this is an important thing to have, it allows it to be very
versatile and modular, and independent of application, one person might
want to used it to render a singe frame, another might want to take his
hand at a movie :), (I have a lot of ideas with raytracing that would be
alot easier to try if it was like this, for right now I'm  actually
writing my own ray tracer because it easier than making changes all
across what like 90,000 lines of code that povray currently is!!

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

huh?? I don't know what you mean by that. if you provide a platform
independent method called trace_scene(POVScene,POVCamera), any other
c/c++ program can call it and do what every it wants with it(likely
platform specific like some kind of gui.)

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

This one would be difficult... if not impossible, but I was thinking
something like.. you can have a patch/plugin fetcher that connect to a
plugin site, and allows you to download any plugin you want, and install
it. you could have different channels for different types of patches AND
platforms, so you only get ones available to your platform...

> And what do you mean by "helix-code update"?
> 

if your a linux fan, them you know what gnome is, helix-code is
basically gnome with alot of extras, one of which is an updater that
fetches new patchs/releases/extras and has multiple channels. I've been
told M$ has something similar now,win-update or something..

> >    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...
> 
I haven't tried any animations yet, I didn't realize you could have more
than one camera,.. but I think it would be cool to create multiple
cameras, each with a name(like "ViewFromSky") and then say
trace_scene(scene, getCamera(scene, "ViewFromSky")


> >    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.
> 
Imagine you have a virtual dog, if you have names for everything, you
could say: translate (dog.front_left_leg, control_point_2, <0,0,0>), to
move objects, and subobjects arbitrary.

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

these are just ideas, apparently not even good ones... the only reason
I'm even interested in povray is because its the best damn raytracer
I've seen yet! and it's flaws are more than made up for by what it can
do. I am a fan/supporter of the open-source community and wish to see
povray become a raytracer that everyone wants to use(over commercial
crap)..

pleas edont be offended by anything I say, I didn't mean to criticize
povray..

Abe

Post a reply to this message