Pitch Roll Yaw, I Need Relative Rotation

ralusek

Okay so I'm attempting a flight game on UDK Mobile similar to the one featured in Eat3D's latest tutorial.

The difference is that instead of using the motion control of the iOS device, I want to use a joystick.

So I added a joystick, was able to basically get the following result:

[i want to apologize ahead of time, i'm super sick right now and really short of breath, so i'm sorry if it's difficult to understand)

[ame]http://www.youtube.com/watch?v=n9eShK5uAYA[/ame]

the problem is basically that when i take the vector components from the plane's current rotation, and add the new vector component based on joystick vector*strength, only the "roll" behavior (what is plugged in to the "z" vector component) is behaving relative to the plane's "pitch" (what is plugged in to the "x" vector component), but the "pitch" is rotating relative to the world stage instead of dynamically relative to the direction i rolled.

i.e. if pitch is dive/climb, and roll is barrel roll etc: if i roll to the right 90 degrees and pitch "upward", at that point i'd want my pitch to rotate me as if i were banking a turn. (real plane physics)

if anyone has done this without heavy vector math i'd appreciate the solution, otherwise i have my work cut out for me. i just don't understand why one of the rotations would behave locally, and the other is global.

ralusek

Simple rephrase:

Does anybody know how to rotate on local axes in kismet?

Does anybody know why value Z plugged into rotation of pawn is the only axis that appears to rotate locally?

That's it.

Vailias

.. it sounds like a Euler rotation order issue. I'm not sure on the kismet side of things, I'm more unreal scripty, but if z is working, and x isn't, and based on the layout of that kismet node, I'd guess the rotation order is x-y-z, when what you're going to want is z-y-x or at least z first. My suggestion for the nodes you have available is to manually add the z offset first, then add the x, then pipe that out to the actor itself and see if the behaviour changes.

Edit: ok just realized this was incomplete: you'll need to set the rotation with the z offset, then set it again with the x offset before exiting the sequence. Just adding them in the right order won't change anything if the actual set is a composite vector.

Ideally you'd rotate via quaternions.. but that doesn't look like its available in kismet.

ralusek

thanks Vailias.

Ya unfortunately one of the first things I tried was changing the sequence in which I rotated them. It produced the same result unfortunately. It also made me nervous because then I figured that if that was the problem, it might make the Z behave on the global axis instead. However, nothing changed, which in hindsight makes sense.

If the order was important, it would still only be important for a fraction of a second until the input restarts the sequence. Then one would theoretically add it's rotation to the ship's current position and maybe one would add it to the position directly before that.

All that happens though is the pitch continues to rotate globally.

Thanks much for the response. I'll look into quaternions.

Vailias

hmm.. yeah odd. It still sounds like a gimbal issue, since if the order is xyz, then regardless of the prior x rotations the z will always be in global space, just the nature of how rotation matrices stack.
I was likely silly in expecting that to be fixable in kismet, as rotating would be a lower level engine thing.

noxrequiem

Hey man have you tried to separate each rotation so they are both attached to the same controller but perform their matrix multiplication separately.

I'm not sure when UDK normalized the local or global vectors but that may be your issue.

Have you also tried on lay out every operation on paper? That always helps when breaking them up.

On a side note I was wondering if you've ever done scripting with UDK, I'm having issues rotating my vehicle when done through script. I was wondering if you may share a link to the kismet tutorial you found.
XD