Tom Melly wrote:

> Hmm, well, yes... So blobs would need seperate syntax to handle
> spherical/cylindrical components, and you still don't have an origin for the
> blob as a whole.

Well, since blobs are made of the objects it consists of,  shouldn't one be able
to access the whole by accessing it's parts?

A little abstract maybe, but look at this:

3A={
    A1
    A2
    A3
}

If you remove A1, A2 and A3, then what's left of 3A? All 3A is is completely
defined by it's parts A1, A2 and A3, i.e

3A = A1+A2+A3.

Thus, to do something to 3A, you can just as well do something to it's parts A1,
A2 & A3, since they define 3A!

If you say a blob should have an origin, how do you define the origin - since
the object itself does not is nothing but a function between it's primitive
parts? It's primitive parts have origins though, so if it's the position of the
blob you're after you can use the positions of it's parts!


> I guess I might be more positive if I understood how you
> thought this would help POV. I don't do much pov-animation - is that where
> you would see it as more useful?

That's a good example of where it could come in handy, yes.

> Still, while playing this game, I would
> have thought that if one was going to settle for an arbitary "origin" for
> all objects, the best point would be the first vector specified for the
> object.

A common "location", "position", "origin" or whatever you want to call it is not
worth discussing. How do you define the location of a mesh or a union of
disjoint primitives? Accessing the values used to construct the objects together
with the objects .translation and .rotation vectors is a much better idea, and
you can probably achieve the same results that way.

> BTW, and I've only played with this in my head, but I'm wondering if one
> could take a perl-like approach to OOP in POV and bolt OOP on with some
> well-written include files ( a bit unfair on perl, but you know what I
> mean... probably).

As the current language is as good as any language can be at describing
primitives, I don't see any reason for changing that. Added OO is all that's
needed, so let's keep the other parts as it is.

> Hmm, the more I think about it, the more possible it
> sounds. Probably falls into the catagory of "interesting but stupid", but
> might be fun to play with.

Since when is something that's useful stupid?

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