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

Chris Huff wrote:
> 
> 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.

AKA the AxisRotate() macro in the Thoroughly Useful Macros;

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

AKA the Stretch() macro in the Throughly Useful Macros;

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

AKA the Matrix() macro in the Thoroughly Useful Macros.

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

Quite true.

However, the current situation (a few language features, plus a few
augmenting macros) seems to be getting everyone's scenes together.
Adding the above features will make things parse slightly faster, but
will have zero impact on rendering speed (because internally everything
is boiled down to one matrix).

Regards,
John
-- 
ICQ: 46085459

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote...
>
> - Selecting a menu item in a menu (the menu bar is at the top of the
screen)
> - Using a keyboard shortcut
>

This is very interesting.  Many GUI OS and application designers have chosen
to provide both.  The keyboard shortcuts, which have a higher learning
curve, are presented in such a way that experts love them, but newbies
ignore them.  Mouse-operated features are used by newbies and experts alike.

In other words, the introduction of a new method of doing something, if
presented properly, will not necessarily confuse newbies, but will provided
added functionality that experts will grow to love, once they have mastered
the slightly steeper learning curve.

-Nathan

Post a reply to this message