I think there's a lot of confusion between OO objects and pov's object {}. I
never intended for the two to be the same thing.

What I need for my scene is the concept of a data structure which can hold a
series of "function" calls (actually macro calls) according to what type of
structure it is. It does not need to be associated with anything renderable.
This just extends the range of possibilities for how pov's macro language can be
used to perform calculations or procedural scene generation, etc.

I can see some uses for having OO objects associated with pov objects, but I
think it would REALLY defeat the point if you are forced to have that
association. For example, you could create a tree using an object that creeps
along the trunk, leaving a trail of spheres, then spawns another object for each
branch, etc... so there would be many more spheres than there are OO objects.

Anyway, just my 2 cents. I'm gonna get on and write my macros :)

-- 
Tek
www.evilsuperbrain.com


"Patrick Elliott" <sha### [at] hotmailcom> wrote in message
news:MPG.1a9d8de2d9dc8dc39899ad@news.povray.org...
> In article <cjameshuff-9D70B1.13425418022004@news.povray.org>,
> cja### [at] earthlinknet says...
> > In article <4032CB5A.9277B9BA@pacbell.net>, Ken <tyl### [at] pacbellnet>
> > wrote:
> >
> > > Not me. It would add another layer of complexity that I don't want to have
> > > to bother to learn. OO is for programming not a scene description
language.
> > > If I wanted to learn programming I would do that rather than using
POV-Ray.
> >
> > You only say that because you don't know what it would add. It would not
> > add complexity, it would greatly simplify many things.
> >
> >
>
> I am seriously confused about what it would simplify... SDL already does
> most everything that OO stuff can. The one and only thing I can think of
> is the ability to over-ride specific attributes, the way you can replace
> an existing function in an object with a new one:
>
> #define Motorcycle1 = object {Motorcycle}
>
> object {
>   Motorcycle1 {
>     #replace Motorcycle1.Handlebars.texture{blah....}
>   }
> }
>
> So you could start with an entirely prebuilt object and change any single
> item in it by directly replacing that item. However, for it to work, each
> individual object would need a unique name or you would need to have some
> way to index which of the objects in a CSG you are applying the changes
> to or adding/removing.
>
> Is the above sort of what you are talking about? Because otherwise I
> don't get what OO feature you are talking about that the SDL doesn't
> already support in some fashion...
>
> -- 
> void main () {

>     call functional_code()
>   else
>     call crash_windows();
> }

Post a reply to this message