This is a continuation of the discussion of my intuitive response to the way
the Reorient macros work. (Unfortunately, I was unable to try out JvS's
suggestion due to a likely typo).

Consider two space ships  [  object{shippy}, one moving by first rotating in
the xz plane, then from xz plane to the desired position,  and another which
simply goes by the Reorient position.

I like the right one (Transform_2) a lot better for camera transforms and
flocking particles both.  I'm trying to figure out if it's merely my
misunderstanding of the geometry, or whether there's a tweak I can do
(perhaps it's in the correct version of JvS's p.o.-t.  note).


#declare Transform_1=transform{Reorient_Trans(Axis1, Axis2)}

#declare Transform_2=transform{Reorient_Trans(Axis1,
<Axis2.x,0,Axis2.z>)Reorient_Trans(<Axis2.x,0,Axis2.z>, Axis2)}

object{shippy transform{Transform_1} translate -4*x }
object{shippy transform{Transform_2} translate 4*x }

Post a reply to this message

Attachments:
Download 'rotated01.mpg' (405 KB)

Not much interest in this post.  Have others:
1) observed the same problem and found more intelligent solutions?
2) not yet experimented with Reorients this deeply and never discovered the
"problem" ?
3) observed it and had no aesthetic difficulties with it?
4) not understood me at all?

Post a reply to this message

It would have been easier to compare the motion if the two ships started in
the same orientation.  I let it loop several times and finally gave up
trying to figure out what was different.  Sorry.

"Greg M. Johnson" <gregj:-)565### [at] aolcom> wrote in message
news:3e105910@news.povray.org...
> Not much interest in this post.  Have others:
> 1) observed the same problem and found more intelligent solutions?
> 2) not yet experimented with Reorients this deeply and never discovered
the
> "problem" ?
> 3) observed it and had no aesthetic difficulties with it?
> 4) not understood me at all?
>
>
>
>

Post a reply to this message

> Not much interest in this post.  Have others:
> 1) observed the same problem and found more intelligent solutions?
> 2) not yet experimented with Reorients this deeply and never discovered
the
> "problem" ?
yup that's me :)

> 3) observed it and had no aesthetic difficulties with it?
Doesn't it just depend on the scene? What looks best in the particular
situation?
Transform_2 looks far better in this case, but what perhaps in a different
scene Transform_1 would look better? Me thinks you'd have to set up the
macro for what you'd need.. The POV-Ray way :) Or am I completely out of
bounds now? Sorry if I am!

> 4) not understood me at all?
Perhaps? Haven't followed the other discussion..

-Peter

PS: The tip of your spaceship isn't connected smoothly to the body, but it
might have been the way you want it to be? ;)

Post a reply to this message

The reorient macro just provides one solution for reorienting an object.
I always makes custom solutions for the specific cases. Couldn't have
made any of my character animation work without that. In my bones
system, I have carefully decided for each bone how it should be aligned
dependent on the alignments on the other bones and the various input
data.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

I think it's pretty evident that the left reorientation scheme is much
smoother than the other one.

That might help you to choose.

Good luck,

Fernando

Post a reply to this message

Fernando Gonzalez del Cueto wrote:
> I think it's pretty evident that the left
> reorientation scheme is much
> smoother than the other one.
>

In the following, assume your plane/ body is facing the +z direction.

In aviation, they talk of pitch (rotate x), yaw (rotate y), and roll (rotate
z).  Pitch and yaw are (over the long term) an inevitable consequence of
WHERE YOU'RE GOING.  Roll is a factor of comfort.  Even watching "Top Gun,"
 you'll see that the pilots may go through all kinds of stunts with rolls
when changing direction, but for long term travel toward a destination
(once they've completed a turn), they choose the orientation of the craft
on the right: ZERO ROLL.  Watch birds: they'll roll on a turn but choose
zero roll once they're pointed in the direction of choice.  We also design
our roadways to minimize roll;  yaw is an inevitable function of where
you're going; an effort is made to reduce pitch somewhat but it's rarely
eliminated.

http://liftoff.msfc.nasa.gov/Academy/ROCKET_SCI/SHUTTLE/ATTITUDE/PYR.HTML
http://www.bmfa.org/faq/flight_controls.htm

Similarly, if you're watching home videos, you're going to get more nauseous
with a camera that has done rotate z than you will with rotate x or y. A
common camera trick is to have the camera say no (yaw) or yes (pitch).  In
a typical day, your head & waist go through hundreds of rotate x's of tens
of degrees, but rotating your waist about the z axis is *uncomfortable* to
say the least.

These are the intuitive, aesthetic reasons why I disliked the roll inherent
in the as-written Reorient macro.   This is actually the reason I stopped
doing flocking animations a while ago: I knew that a bird or plane wouldn't
rotate in this fashion. I just this month figured out a solution when I hit
this wall with my camera reorientation.  The solution is a two step one.
That NASA link suggested that the rotations are always done in order of
Pitch, Yaw, and Roll.  My intuition is that one could tweak the macro
itself to affect the change I'm talking about-- perhaps even avoid the
abrupt change  you noticed.  While I'm tinkering, I'm publicly asking if
anyone else has figured this out.

Greg M. Johnson


>
>That might help you to choose.
>
>Good luck,
>
>Fernando
>

Post a reply to this message

I prefer the right ship's movement. It's more alive, but if you're just
using a 'simple' formula, then maybe the math is unstable. I think the
movement is 'intelligent', done on purpose by the ship's computer, in order
to fly in an atmosphere or ... something like that.. The left ship is
boring.

Regards,
Hugo

Post a reply to this message

To get greatest comfort, you don't really want to minimize roll, you
want to make sure that the total force vector that the pilot is
influenced by matches the downward direction of the ship. For example,
if the ship makes a sharp turn (to the side), then you actually desire
roll, because the centrifugal force is added to the regular gravity
force, and the total force is then not straight -y but some slanted
direction, and you want the roll of the ship to match that, so that the
pilot isn't thrown sideways in the cockpit.

You can't compute these kind of things with a simple transform. You have
to consider the force vectors influencing the ship, and based on those
find the optimal roll at the given time. Another thing to take into
account is that a too fast roll may not be very comfortable. The point
I'm coming to is that you need a dynamic simulation that for any given
time considers the direction, the speed, the curvature of the path, and
the current alignment and calculates the roll based on that. Of course,
this may be overkill for what you want to do.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

You're purely correct for a turn.  You're right about needing to roll your
own macro.

But when you're beyond a region with any considerable "curvature to the
path"-- I said once you'd completed the turn--  I'd assert you always want
zero roll.

Interesting Q:  Is there a way to compute instantaneous "sphere of
curvature" on a plain ol' pov 35. spline?


"Rune" <run### [at] runevisioncom> wrote in message
news:3e173498@news.povray.org...
> To get greatest comfort, you don't really want to minimize roll, you
> want to make sure that the total force vector that the pilot is
> influenced by matches the downward direction of the ship. For example,
> if the ship makes a sharp turn (to the side), then you actually desire
> roll, because the centrifugal force is added to the regular gravity
> force, and the total force is then not straight -y but some slanted
> direction, and you want the roll of the ship to match that, so that the
> pilot isn't thrown sideways in the cockpit.
>
> You can't compute these kind of things with a simple transform. You have
> to consider the force vectors influencing the ship, and based on those
> find the optimal roll at the given time. Another thing to take into
> account is that a too fast roll may not be very comfortable. The point
> I'm coming to is that you need a dynamic simulation that for any given
> time considers the direction, the speed, the curvature of the path, and
> the current alignment and calculates the roll based on that. Of course,
> this may be overkill for what you want to do.
>
> Rune
> --
> 3D images and anims, include files, tutorials and more:
> rune|vision:  http://runevision.com (updated Oct 19)
> POV-Ray Ring: http://webring.povray.co.uk
>
>

Post a reply to this message