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

Chris Huff wrote:

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

I think I'm in love.

;-)

----------------------------------------------------
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 <39A11AD5.5A347EF4@ida.utb.hb.se>, sa9### [at] idautbhbse 
wrote:

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

You left out "matrix" and "scale" transforms.
What do you propose? Saving a certain group of points, so the 
orientation of the object could be obtained? Say, origin(which would be 
<0,0,0>), x, y, and z, which would be transformed with the object and 
retrievable later? This seems inefficient, why not just make the 
transform available, and transform vectors yourself?
Or do you want to add rotations and translations to member variables, so 
you can have the total rotation and translation applied to the object? 
How useful would this be?

I think you can do all you need by simply making the transformation 
matrix available to the user. If the user needs more, they can create a 
new object and override the rotate(), translate(), etc. methods 
themselves to do what they want.


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

This does look kind of interesting...especially this part: "We hope to 
have a Macintosh version by August 2000." :-)
However, it looks like it would be a pretty big adjustment from 
POV-Script. And it would need a bit of adjustment to fit with POV...it 
seems designed to do dynamic realtime animations, while POV does frames. 
And it looks like all objects are drawn, no matter what, I would prefer 
at least a draw() method so I can have objects which aren't drawn.
But it looks nice and efficient, just 12 lines...

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

Thorsten Froehlich wrote:

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

Since my hands are resting on the keyboard and I only use the mouse when surfing or
when modelling in some 3d program, my answer is of course: the keyboard. Another way
to answer that question: I only use the mouse when I have to. :)

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

Chris Huff wrote:

> You left out "matrix" and "scale" transforms.

I know...for simplicity I only mentioned translation and rotation.

> I think you can do all you need by simply making the transformation
> matrix available to the user. If the user needs more, they can create a
> new object and override the rotate(), translate(), etc. methods
> themselves to do what they want.

This is probably exactly what I'm looking for. That is, if the values used
to create the object are available also (like the first vector in the sphere
expression, the float value determining the radius, etc.). Note that
"origin" only applies to that first vector parameter in spheres and light
sources...(from what I currently can recall) - other objects use other
construction parameters, like the box with it's two vectors that probably
best could be called .corner1 & .corner2, or something like that. All that
should be object specific, as said before.

> However, it looks like it would be a pretty big adjustment from
> POV-Script. And it would need a bit of adjustment to fit with POV...it
> seems designed to do dynamic realtime animations, while POV does frames.
> And it looks like all objects are drawn, no matter what, I would prefer
> at least a draw() method so I can have objects which aren't drawn.
> But it looks nice and efficient, just 12 lines...
>

I don't want VPython to be the new OO POV-Script - but VPython could be seen
as an example of how nice and efficient it should be...nothing else.


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

Ron Parker wrote:
> 
> 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.

Most algorithms to decompose matrices begin by assuming that the component
transforms were done in a particular order.  This generally works because the
predominant habit among modellers is to scale first, rotate second, and translate
third.  The resulting matrix can always be broken down into the original three
transforms (with a caveat in regards to rotation).

Note that the translate could have been the second or even the first
transform actually applied; however, simple examination of the resulting
matrix cannot reveal whether this is so.

Likewise, if shearing is present, there is no way to tell when or how it was
done.  Consequently the decomposing algorithm must make assumptions, which
may be wrong.

The only time one can make a useful guess at the order of operations is when
the matrix under consideration is a slight modification of a matrix whose
original transforms are already known.  Evn then it can be tricky.

Regards,
John

Post a reply to this message

In article <39A27BD2.C662EFED@erols.com>, John VanSickle 
<van### [at] erolscom> wrote:

> Most algorithms to decompose matrices begin by assuming that the 
> component transforms were done in a particular order.  This generally 
> works because the predominant habit among modellers is to scale 
> first, rotate second, and translate third.  The resulting matrix can 
> always be broken down into the original three transforms (with a 
> caveat in regards to rotation).

Ouch, I often rotate after translating or alternate rotation and 
scaling...I don't think this would work well. And how does it deal with 
things like rotations around an arbitrary axis? (which is a transform I 
have considered adding)
This does seem too unreliable, and the user could always override the 
macros to do what they want, like saving the transforms as they are 
applied.

-- 
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 Tue, 22 Aug 2000 10:21:49 -0500, Chris Huff wrote:
>Ouch, I often rotate after translating or alternate rotation and 
>scaling...I don't think this would work well. And how does it deal with 
>things like rotations around an arbitrary axis? (which is a transform I 
>have considered adding)

Provided that no skewing took place (that is, that you get three orthogonal 
vectors when you transform three orthogonal vectors) it deals quite well.
It just doesn't give you the results you may have expected.  

For example, 

translate x rotate 45*y 

is equivalent to 

rotate 45*y translate <sqrt(.5),0,-sqrt(.5)>

Similarly, 

rotate 45*y around_point x // if such a syntax existed

would be equivalent to

rotate 45*y translate <1-sqrt(.5),0,sqrt(.5)>

BTW, the transform you mentioned would probably be better implemented as 
a macro, but I think it's been done.

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

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> BTW, the transform you mentioned would probably be better implemented as 
> a macro, but I think it's been done.

It has been done as a macro. There are three transforms I am 
considering: 

axis_rotate AMOUNT, AXIS  Rotates around a specified axis.

directional_scale AMOUNT, DIRECTION  Scales in a certain direction(like 
in the LiquidSpray include and the particle_stretch feature in my 
particle_system patch).

coordinate_system X, Y, Z  Takes three vectors for the new directions of 
each axis. This would make operations like shearing a lot easier.

These could all be done with macros, but might be nice if available 
built-in. Rotate, scale, and translate could also be done as macros(and 
maybe they would have been if macros had existed at the beginning), all 
that is really necessary is the matrix transform.

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