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

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

Image mapping and texturing would be exactly the same.


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

The best way(in my opinion, the right way) to do this is to use 
persistant *variables* that are added to the scene each frame. The scene 
would be cleared each frame, so you wouldn't see any difference, but the 
code would be simpler(you wouldn't have to make sure you aren't 
duplicating an object already in the scene), and there isn't as much of 
a problem of different incompatible ways of referring to an object.


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

Specifically, search in povray.general and the more recent discussions 
in povray.programming.


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

You can already use POV for both stills and movies...


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

What are these ideas that require a new raytracer? What changes would 
you have to make in order to use a scene file that an API wouldn't 
require?
These are the usual arguments for an API, some of the arguments against 
it are:
It isn't needed, you can already access all of POV's features through 
the scene description language.
It isn't cross-platform, you would have to write different code to 
expose these APIs for every port.
It makes it less obvious to the user that POV is the program doing the 
work.

Some of the platforms(Mac and Windows) already have limited API's, 
basically enough to tell POV to render a specific scene with certain 
settings, and this is all that is necessary. Also, it doesn't belong as 
a core feature, but a platform-specific feature.

BTW, good luck on your raytracer...I hope you release the source(and if 
you do, that you keep platform dependant code isolated from the rest of 
the code). :-)


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

No. You have to go through special work to allow other programs to use 
the function...and there isn't a platform independant way to do this.


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

Making POV-Ray dependant on an internet connection? No thanks...
And it still has the problems of accessing the plugins in a 
cross-platform way, speed, etc.


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

I'm interested in Linux, but I don't have much experience with it, and 
haven't heard about this. I wouldn't know about any M$ project 
either...I don't use Windows. Look at my headers, e-mail address, and 
web site. :-)


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

#declare ViewFromSky = camera {...}
#declare ViewFromGround = camera {...}
...
camera {ViewFromSky}

Or do you mean rendering more than one image at once?
I think the .pov file should stick to scene description as much as 
possible...but maybe another type of file could be useful...something 
more friendly and powerful than .ini files, which controls the rendering 
process, and can pass information to the POV file through variables.


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

How does this conflict with using a variable?
#declare Dog =
object {...
    members {
        #declare FrontLeftLeg = object {...};
        #declare ControlPoint2 = < 0, 1, 2>;
        #macro GetCurrentState() ... #end
    }
};

Dog.FrontLeftLeg.translate(...);
#set Dog.ControlPoint2 = vtransform(Dog.ControlPoint2, ...);

object {Dog.GetCurrentState()}

Notice the #set command...this is just something I think should be 
added, it would only modify existing variables and would not create a 
new one. I have had many times when this would make things easier to 
read and prevent a bug or two...oh, and the vtransform() function is 
something new in MegaPOV. The GetCurrentState() macro would take the 
current condition of the dog and return a union object.
The members{...} block would be to retain backwards compatability...you 
can already place declarations within objects, having them suddenly 
become members of the object in the new version wouldn't be very 
user-friendly. :-)


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

Your ideas are not "crap"...I doubt anyone will know what OOPOV will 
look like until it actually exists. :-)
BTW, POV-Ray is *not* open source, though that seems to be a common 
misconception...the main difference is in the licensing. The POV-Team 
wishes to keep more control over their work than open-sourcing would 
allow, which they have every right to. They do make the source available 
and allow distribution of modified versions, though, so they (and the 
community) get some of the same benefits of open source without many of 
its problems.

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