Mikael Carneholm wrote:

>Abe Heckenbach wrote:
>
>>    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;>) 
>
>This is in the direction of OO-features in the scene language - a
>popular(?) topic in these groups.

This might be interesting:
http://virtualphoton.pc.cc.cmu.edu/projects/visual/
http://cil.andrew.cmu.edu/projects/visual/vpythonprog.htm

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

On 19 Aug 2000 20:38:33 -0400, Warp wrote:
>In povray.general Mikael Carneholm <sa9### [at] idautbhbse> wrote:
>: Location, as I thought of it, should be one of the common attributes for all
>: objects. Think java again:
>
>: public virtual class POVOBJECT{
>:   public povVector location, rotation;
>: }
>
>  Now you forget one thing: That takes memory. And povray is not very well
>known when speaking about low memory consumption. Let's not make the matter
>even worse.

Then think:

public virtual class POVOBJECT{
  public povVector getLocation(), getRotation();
}

That doesn't take extra memory per object and is also cleaner from
an OO point of view. The methods could compute their values from the
transformation matrix for most objects.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

In povray.general Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
: That doesn't take extra memory per object and is also cleaner from
: an OO point of view. The methods could compute their values from the
: transformation matrix for most objects.

  How do you compute the location, scale and rotation of an object from its
transformation matrix?
  AFAIK there's more than one way to get any specific transformation matrix.

  The problem becomes clearer when you think about sheared objects.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <399D6B3D.51EACD7E@ida.utb.hb.se>, sa9### [at] idautbhbse 
wrote:

> Location, as I thought of it, should be one of the common attributes 
> for all objects.
...snip...

Still, what *is* the location? A sphere has a center, but what is the 
center of a cone? The middle of the bounding box? The center of gravity?
What is the "location" of an infinite plane? A complex mesh or CSG?
Each object should have it's own variables available, but a single 
"location" variable for all of them isn't possible. Maybe a 
GetLocation() method for all objects in the finite object portion of the 
heirarchy, but you still have to define the location of an arbitrary 
object.

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

In article <slr### [at] tealhhjpat>, 
hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:

> That doesn't take extra memory per object and is also cleaner from
> an OO point of view. The methods could compute their values from the
> transformation matrix for most objects.

Warp is right, matrices store many transforms in order, and there are 
usually a very large or infinite number of possible 
rotations/translations/scales to get to a specific point.
And what would the "object rotation" mean? The direction of the z axis 
in degrees? I think you are thinking of the sum of all rotations, which 
I don't think you can easily extract from a matrix which also stores 
translations, scaling, and arbitrary matrix transforms. Just make the 
matrix available, the user can override the rotate() methods to save 
each rotation in a vector if they want.

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

On Fri, 18 Aug 2000 11:15:57 +0200, Mikael Carneholm wrote:
>Warp wrote:
>
>>   What would be the advantage of transforming subobjects after the CSG has
>> been declared?
>>
>
>I think the main advantage of OO (from my point of view) would be _reading_
>the location/rotation/scale etc. of objects, instead of (as in the example):
>setting the values. 

I don't understand this mindset.  If you need to know what transformations
have been applied to object foo at some point in the future, keep track of
what transformations you've applied.  What's so hard about that?

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Sun, 20 Aug 2000 11:08:18 -0500, Chris Huff wrote:
>I don't think you can easily extract from a matrix which also stores 
>translations, scaling, and arbitrary matrix transforms. Just make the 
>matrix available, the user can override the rotate() methods to save 
>each rotation in a vector if they want.

You might be surprised.  Except for the arbitrary transforms (which make
the problem different, but possibly not much more difficult) it's relatively 
easy to decompose a matrix into rotations, scales, and translates.  I wrote
the whole mess up for someone in c.g.r.r. a few years ago; I think I might
still have it in my outbox.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In povray.general Ron Parker <ron### [at] povrayorg> wrote:
: You might be surprised.  Except for the arbitrary transforms (which make
: the problem different, but possibly not much more difficult) it's relatively 
: easy to decompose a matrix into rotations, scales, and translates.  I wrote
: the whole mess up for someone in c.g.r.r. a few years ago; I think I might
: still have it in my outbox.

  How do you decompose a matrix transformation which causes shearing to
rotations, scales and translates?
  For example think about this:

scale <1,.5,.8>
rotate <30,45,20>
scale <.8,.25,.5>
translate <2,3,4>
rotate <15,20,80>

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Chris Huff wrote:

> Still, what *is* the location? A sphere has a center, but what is the
> center of a cone? The middle of the bounding box? The center of gravity?
> What is the "location" of an infinite plane? A complex mesh or CSG?
> Each object should have it's own variables available, but a single
> "location" variable for all of them isn't possible. Maybe a
> GetLocation() method for all objects in the finite object portion of the
> heirarchy, but you still have to define the location of an arbitrary
> object.
>

I apologize if I was unclear about this. Your previous post made me realize
that it's better to have object type specific attributes (like .origin for
sphere, .top & .bottom for cylinder, .corner1 & .corner2 for box, .normal
and .distance for plane, etc.)  which relate to the initial values given
when the object was created, and then separate .translation and .rotation
attributes (alt. getTranslation() & getRotation() methods). Collecting
information about an objects whereabouts should then be no problem - if the
.translation and .rotation attributes correspond to the respective values in
the transformation matrix of the object. Again, an example:

#declare ABox = box{
  <-1,-1,-1>,
  <1,1,1>
  translate <5,1,0>
}

Then:

ABox.corner1 = <-1,-1,-1>
ABox.corner2 = <1,1,1>
ABox.translation = <5,1,0>

...which means the exact position of "corner1" can be retrieved by

#declare corner1_pos = ABox.corner1 + ABox.translation;

I think this makes more sense, as an object always is created with some
parameters, and then translated/rotated various amounts. It should thus be
quite logical to collect info about an object my reversing the creation
process; think of it as setting the values at creation and getting the same
values at a later point.

Btw, check the VPython pages that ingo found:

http://virtualphoton.pc.cc.cmu.edu/projects/visual/
http://cil.andrew.cmu.edu/projects/visual/vpythonprog.htm

Not very far from POV-Script actually - except that it is object oriented,
of course.

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

"Mikael Carneholm" <sa9### [at] idautbhbse> wrote in message
news:39A11AD5.5A347EF4@ida.utb.hb.se...

> I apologize if I was unclear about this. Your previous post made me
realize
> that it's better to have object type specific attributes (like .origin for
> sphere, .top & .bottom for cylinder, .corner1 & .corner2 for box, .normal
> and .distance for plane, etc.)  which relate to the initial values given
> when the object was created, and then separate .translation and .rotation
> attributes (alt. getTranslation() & getRotation() methods). Collecting
> information about an objects whereabouts should then be no problem - if
the
> .translation and .rotation attributes correspond to the respective values
in
> the transformation matrix of the object. Again, an example:
>
> #declare ABox = box{
>   <-1,-1,-1>,
>   <1,1,1>
>   translate <5,1,0>
> }
>
> Then:
>
> ABox.corner1 = <-1,-1,-1>
> ABox.corner2 = <1,1,1>
> ABox.translation = <5,1,0>
>
> ...which means the exact position of "corner1" can be retrieved by
>
> #declare corner1_pos = ABox.corner1 + ABox.translation;
>
> I think this makes more sense, as an object always is created with some
> parameters, and then translated/rotated various amounts. It should thus be
> quite logical to collect info about an object my reversing the creation
> process; think of it as setting the values at creation and getting the
same
> values at a later point.
>

Such an approach might work for simple primitives, but would fail on
anything more complex - how do you define a sensible reference point for a
blob? In addition, this is forcing a model onto POV that POV does not
actually use. Even if it was only implemented on simple primitives, it would
potentially lead new users astray.

Besides, your code could be rewritten as (I think):

#declare ABoxC1 = <-1,-1,-1>;
#declare ABoxC2 = <1,1,1>;
#declare ABoxTran = <5,1,0>;

#declare ABox = box{ ABoxC1, ABoxC2 translate ABoxTran }

#declare corner1_pos = ABoxC1 + ABoxTran;

Post a reply to this message