Chris Huff wrote:

> Transformations(scale, rotate, translate, matrix) are all stored in a
> 4*4 matrix, and what would "location" mean? The center of the bounding
> box?

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

As you see, one can't create a "povobject", but all objects in the POV 3d
space should be descendants from this class, as all objects in POV can be
rotated and translated. I.e, let's continue with the class declaration for a
sphere:

public class SPHERE extends POVOBJECT{
  public double radius;
  public povMaterial material;
}

Ok, let's create a sphere:

#declare A=sphere{
  0, 0.5
  pigment{ color rgb 1}
}

Right now, A.location=<0,0,0>, and A.rotation=<0,0,0> (as default). If we
change A.location:

#declare A.location=<0,1,0>;  // or by using a method, like
A.translate(<0,1,0>) (?)

..A.location is now <0,1,0>, similar to sphere{ ... translate <0,1,0>}. For
other type of objects, like boxes, it's maybe not a bad idea using the
center of the bounding box. Coming to thinking of it - maybe it's better to
have a "translation" attribute instead, which together with object specific
member attributes could be used to get the data needed:

#declare foo=sphere{
  <0,1,0>,  //let's store this in a sphere-specific attribute called
"origin", which holds the vector where it was originally created.
  0.5
  translate <1,0,0>
}

To retrieve the center of the sphere, one could use foo.origin and
foo.translation: The center of the sphere is now at
foo.origin+foo.translation.

This would work better with other types of objects, as box for example,
where the whereabouts on this box:

#declare foo=box{
  -1,1
  translate <1,1,1>
}

..could be retrieved using foo.corner1, foo.corner2 (or something like that)
together with foo.translation. Cylinders could have .top, .bottom, .radius,
polygons could have .point[] and .point_count etc.

> BTW, I would prefer a #reference keyword to your ref {} syntax, it could
> be used outside of objects. Maybe a specific members {} block in objects
> would be a good idea, though...
> object {...
>     members {
>         #reference Next = object {...};// a reference
>         #declare Velocity = < 1, 5, 0>;// a public variable
>         #local Speed = vlength(< 1, 5, 0>);// a protected variable
>         #macro GetSpeed() Speed #end // a member macro
>     }
> }

Not a bad suggestion, at all. I've been thinking of something similar, i.e.
all (POV) objects can have abstract (non visual) member attributes and
methods:

#declare myMovingThingy=union{
  cylinder{...}
  box{...}
  members{
        #reference Next = object {...};// a reference
        #declare Velocity = < 1, 5, 0>;// a public variable
        #local Speed = vlength(< 1, 5, 0>);// a protected variable
        #macro GetSpeed() Speed #end // a member macro
  }
}

Here, the encapsulation subject is also covered, so I guess Warp is happy
now :)

As said, the subject is open for suggestions..

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