Download

RInterp issue

Hello community! I’ve come across a problem I can’t make sense of.

Here’s a picture of the code I am using:

This is for rating a ship in space for a small game I am working on. This works great, and here are the output logs:


LogBlueprintUserMessages: [Ship_Basic_C_0] P=0.000000 Y=0.000000 R=0.000000
LogBlueprintUserMessages: [Ship_Basic_C_0] P=0.000000 Y=1.333447 R=0.000000
LogBlueprintUserMessages: [Ship_Basic_C_0] P=0.000000 Y=2.000061 R=0.000000
LogBlueprintUserMessages: [Ship_Basic_C_0] P=0.000000 Y=2.666730 R=0.000000
LogBlueprintUserMessages: [Ship_Basic_C_0] P=0.000000 Y=3.333399 R=0.000000
LogBlueprintUserMessages: [Ship_Basic_C_0] P=0.000000 Y=4.000233 R=0.000000
LogBlueprintUserMessages: [Ship_Basic_C_0] P=0.000000 Y=4.666875 R=0.000000
LogBlueprintUserMessages: [Ship_Basic_C_0] P=0.000000 Y=6.052537 R=0.000000
LogBlueprintUserMessages: [Ship_Basic_C_0] P=0.000000 Y=6.359700 R=0.000000
LogBlueprintUserMessages: [Ship_Basic_C_0] P=0.000000 Y=7.026429 R=0.000000

As you can see the Yaw value smoothly increases, just like it should.

However I want the Pitch value to be a constant value of 90.
So I changed it like this

I changed the target’s Pitch to 90.

And the outcome is this:


LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=0.000000 R=0.000000
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=0.319912 R=-0.895172
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=0.063354 R=-1.151733
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=1.061397 R=-0.153687
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=179.580704 R=178.365616
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=0.580744 R=-0.634338
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=179.333282 R=178.118179
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=178.633682 R=177.418579
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=0.410886 R=-0.804230
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=-0.210358 R=-1.425446
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=178.885635 R=177.670547
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=0.198518 R=-1.016571
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=0.715268 R=-0.499817
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=-0.149109 R=-1.364197
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=179.205185 R=177.990097
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=1.153647 R=-0.061432
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=-88.419128 R=-89.744232
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=36.505108 R=35.180012
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=-90.666687 R=-89.205627
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=35.778683 R=35.906406
LogBlueprintUserMessages: [Ship_Basic_C_0] P=90.000000 Y=-90.666687 R=-89.205627

As you can see, while the pitch is steady 90 as I want to be, the Yaw value is completely messed up! I am trying to understand if there is a logical explanation behind this or if it’s an engine bug. Any input would be great.

@DjSt3rios

The behavior is most likely by design. Could be related to Gimbal-lock or some other rotation gotcha. Things to try… 1. Get the current Roll and feed it into the RInterp Roll input (don’t try freezing it as a constant along with the Pitch). 2. Don’t assume you can fix the pitch at 90. You probably have to do a separate relative rotation calc each time (see below) 3. Explore working with World-Rotations instead if its an option in the project… 4. Work empirically… Build a quick test system that rotates the actor the way you want to see ‘visually’ on-screen (using x,y,z keyboard keys or entering values into 3 UMG text boxes etc). Then work backwards observing the values (not trying to judge or interpret them). Instead, just ask what calc work needs to be done, to replicate those exact same series of numbers (like using MS-Excel equation solver etc).

What you need to be careful about when working with rotations is making assumptions. Its different than working with translations or moving objects in 3D space, where you can translate or move an actor, and the x,y,z values will remain independent. That’s not the case with rotations, they are interdependent. If an object is level you can fool yourself into thinking that working out rotations is simple. But once the object comes pre-rotated or at an angle, or the parent is rotated, simple calculations will fail. It looks like you just want to turn this actor in a 360, but at a vertical pitch of 90 degrees. However, if the rotation of the object or parent is not centered, the actual rotational values are going to be off, so its not going to be nice simple numbers anymore…

TLDR: You’ve got a choice to make. If you like math you can read up on rotations and some of the gotchas including Gimbal-lock. Or, you can take an empirical approach. Figure out a way of creating the rotations you want to see visually on-screen, observing the values and then working backwards… Figuring out how to calc or ‘solve’ those exact numbers. Sorry, if you just wanted a dead simple answer, but rotations are head-wreckers. Hopefully the advice will help you later though, when solving similar problems! :slight_smile:

@franktech Thank you so much! I am not sure I understood everything, but I got it working haha. I ended up setting actor rotation’s pitch 90, so I left the relative to 0 as it was and with some tweaking it works as it should now, thank you very much :slight_smile: