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

In article <39a127d9$1@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> 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

Keyboard shortcut(assuming you already know the shortcuts). Otherwise, 
you have to use the menu(or keep the manual open).

Writing a particle system or other complex coding in POV-Script versus 
OOPov-Script: OOPOV-Script.

Learning the basics of using the above: neither.(the basics are exactly 
the same)

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

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