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

Ron Parker wrote:

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

The main issue is the extremely hard extra work load ;-)

Well, there are situations when it just should be very convenient to be able to
collect info about an object by accessing the attributes of it. An example is in
a situation when you're writing an include file, and you want to access the
objects in the users file, without having to force the user to declare separate
values for camera locations, light source transformations etc. It's just a
question of simplicity and convenience.

An example - compare this:

camera{ location <0,1,-10>  look_at 0 }
#declare foo = light_source{ <50,50,-100> color rgb 1 }

...to this:

#declare camera_lookat = <0,1,-10>;
#declare object_position = <50,50,-100>;
camera{ location <0,1,-10>  look_at camera_lookat }
#declare foo = light_source{ object_position color rgb 1 }

Much less work needed to retrieve the look_at of the camera and the location of
foo using camera.look_at and foo.origin later in the file as provided in the fist
case, don't you agree? Much less work needed by the user, i.e....more user
friendly, to use a popular phrase... :)

Making POV-Ray (even) more user friendly at the same time as you're providing a
more powerful scripting language can't really be a bad thing, can it?

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

In article <39A123A1.5B90BD85@ida.utb.hb.se> , Mikael Carneholm 
<sa9### [at] idautbhbse>  wrote:

> Making POV-Ray (even) more user friendly at the same time as you're providing
> a more powerful scripting language can't really be a bad thing, can it?

Just wondering, what do you think is faster:

- Selecting a menu item in a menu (the menu bar is at the top of the screen)
- Using a keyboard shortcut


    Thorsten

Post a reply to this message

On 21 Aug 2000 05:28:18 -0400, Warp wrote:
>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>

It's been a while.  I think there were additional constraints on the solution.

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

Post a reply to this message

Thorsten Froehlich wrote:

> Just wondering, what do you think is faster:
>
> - Selecting a menu item in a menu (the menu bar is at the top of the screen)
> - Using a keyboard shortcut

This is not comp.os.microsoft.windows.forgetting.keyboard.interaction - please post
to the proper group.

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

In article <39A13586.CD67AD69@ida.utb.hb.se> , Mikael Carneholm 
<sa9### [at] idautbhbse>  wrote:

>> Just wondering, what do you think is faster:
>>
>> - Selecting a menu item in a menu (the menu bar is at the top of the screen)
>> - Using a keyboard shortcut
>
> This is not comp.os.microsoft.windows.forgetting.keyboard.interaction - please
> post to the proper group.

:-)   I am still curious what you think is faster ... I won't start a flame
war for either answer, just would like to know.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Tom Melly wrote:

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

I don't think anything is impossible - until proven, of course. My suggestion
for blob as well as CSG objects or other complex objects is the use of a
.subobject[] property, along with a .subobject_count. An example:

#declare ABlob = blob {
    threshold .65
    sphere { <.5,0,0>, .8, 1 pigment {Blue} }
    sphere { <-.5,0,0>,.8, 1 pigment {Pink} }
    finish { phong 1 }
  }

The blob object lends itself nicely to OO, like this:

ABlob
    -subobject_count
    -subobject[0]
        -type //sphere or cylinder
        -origin  // as it is a sphere
        -radius
        -strength
        -pigment
    -subobject[1]
        ..
    -finish

(If some of the blob items had been a cylinder, there had been .top and .bottom
properties of subobject[0] instead of .origin.)

This means we can access our blob as in this example:

#declare i=0;
#while(i<ABlob.subobject_count - 1)
    #if(ABlob.subobject[i].type=0)    // type 0 = sphere, 1 = cylinder
        // do something using subobject[i].origin
    #else
        // do something using subobject[i].top, subobject[i].bottom
    #end
    #declare ABlob.subobject[i].radius = ABlob.subobject[i].radius + 1;
    #declare ABlob.subobject[i].strength = ABlob.subobject[i].strength + i / 10;

    #declare i=i+1;
#end

A CSG example:

#declare ACSG = difference{
    box{1,-1}
    difference{
        sphere{0, 1}
        plane{y, 0}
        translate <1,0,0>
    }
}

ACSG
    -subobject_count
    -subobject[0]    //the box
    -subobject[1]    //the sphere - plane difference
        -subobject_count
        -subobject[0]    // the sphere
        -subobject[1]    // the plane

We could now access the plane down in the hierarchy by

ACSG.subobject[1].subobject[1]

Similar for meshes, unions of bicubic patches, etc.

----------------------------------------------------
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:39A14052.36F8CD0F@ida.utb.hb.se...
> Tom Melly wrote:
>
> > 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?
>
> I don't think anything is impossible - until proven, of course. My
suggestion
> for blob as well as CSG objects or other complex objects is the use of a
> .subobject[] property, along with a .subobject_count. An example:
>

<snip>

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. 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? 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. So, for a blob, it would be the first point of the first component,
whether cylindrical or spherical.

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

Post a reply to this message

In article <slr### [at] fwicom>, 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.

But can you decompose the matrix into the *same* set of transforms which 
produced it?
My understanding is that there are often an infinite number of 
solutions. Getting the "orientation" might be useful, but what else 
would be possible?

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