x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

How can I keep Control Rotation from freaking out past 90 degrees?

Hi, I'm gone through and setup an inverted sphere world where the control rotation's up vector always points towards the world's center (0,0,0). The player can walk around on the inside of the sphere all the way around, but currently when the player hit's the 90 degree mark of the world the control rotation starts to fall apart. This effect actually starts to occur before 90 degrees (maybe around 75-80) but it's a gradual transition. I've test my walking past 90 degrees on the two working halves of the world ( below the 90, and above) by placing the character upright on the bottom half and then upside down on the top half. The character will fall along his UpVector and then can move along the walls until hitting this point. There's a big chance it's still something burried in the CharacterMovementComponent that I haven't rooted out yet but my gut tells me it's some sort of rotation math issue. Right as the player hits this 90 degree mark the control will sort of spin/ fall over, it feels as though some value is no longer staying within scope. When I slam into this invisible barrier the character will bounce out off the surface and then start to inherit it's Local Z is down gravity setup, and sometimes it'll float over the barrier and allow me to drop down to the ground on the other side (It's actually kind of cool). Again I'm not convinced it's not still a lingering evaluation in my charactermovementcomponent but the fact is that the control mechanism that I've setup in BluePrint loses it's effectiveness around this 90 degree limit, and I don't understand why something that is pointing at a location every tick can wobble out of alignment and break, so I'm looking for some suggestions about where to look. Ultimately I think I should throw away the Blue Print and just embed this stuff in the CharacterMovementComponent, but that'll be easier once I know what is going on. Attached is shot of the actual BP keeping the UpVector pointed towards the world (0,0,0) vector. alt text

Product Version: Not Selected
Tags:
bpzeropoint.jpg (119.1 kB)
more ▼

asked Jun 21 '14 at 03:14 AM in Blueprint Scripting

avatar image

Thumper
966 139 149 388

avatar image Thumper Jun 21 '14 at 03:44 PM

Attached is a little diagram showing a side slide of the problem. Yaw essentially breaks down near the 90 degree mark. No longer behaving as yaw is intended.

alt text

bpzeropoint2.jpg (128.9 kB)
avatar image Thumper Jun 21 '14 at 06:50 PM

If I wanted to put this in code where would I look to find where the rotation of the character is first set/ established?

avatar image Thumper Jun 21 '14 at 06:52 PM

I see rotation stuff throughout the charactermovementcomponent but nothing that appears to be always maintain or override everything else. For me I need the Pitch and Roll to be set to pointing toward the Vector (0,0,0). I know that I can use MakeRotZX to point my capsules UpVector towards that coordinate so now I need to know where I would put this function at (Character, CharacterMovementComponent, somewhere else)

avatar image Thumper Jun 21 '14 at 09:27 PM

Is there another system that effects the control rotation besides the settings in the character cpp? I've already switched the pitch and roll to true.

avatar image Thumper Jun 22 '14 at 09:22 PM

Here I've got the Control Rotation printing out to the screen. You can see the Yaw doesn't behave correctly, in the first shot the yaw is low, then in the next it's been influenced a good bit but the character has not turned any, then in the last shot on the right you can see where the value of the yaw accumulates enough the character capsule actually falls over onto it's side instead of swiveling along it's UpVector.

alt text

bpzeropoint3.jpg (484.4 kB)
avatar image Thumper Jun 23 '14 at 02:13 PM

I've looked all over for a solution to this and I'm coming up short. I'm not even sure what is going on. If I'm telling Pitch and Roll to be something specific every tick then why do they get influenced at all outside of that? You would think they would always be the result of the BP above. Additionally why does Yaw start to lose it's orientation as I walk up the slope. Isn't Yaw always the swiveling down the UpVector? Instead it starts to act like it's only yawing along the world UpVector and as I get near or cross the 90 degree mark it's rolling the character onto it's side.

avatar image Thumper Jun 23 '14 at 06:08 PM

I've noticed that when I cross over the 90 degree mark to the upper side of the sphere, my horizontal input get's reversed. When I Approach the 90 degree mark the Yaw appears to warp heavily to flip the character over on it's head. Something is causing the control rotation to flip over when the capsule crosses the horizon, which would be Zero in my world, because the center of the sphere is 0,0,0.

avatar image Steve Allison STAFF Jun 23 '14 at 06:32 PM

Hey Thumper,

We're working on providing a potential solution for your problem--what is happening is that you are hitting gimbal lock, which causing your rotations to not behave as desired. We hope to have more feedback for you soon on this issue.

-Steve

avatar image Thumper Jun 23 '14 at 06:47 PM

Cool, I thought I was going crazy, I tried using Attach control rotation to pawn, thinking that if it was somehow local to where the player is at that it wouldn't roll out like that, but no luck. Thanks for replying, I had recently put a bunch of work into getting the Walkable angle to be based on my characters up and for the most part I think I have achieved this, but the dead zone in my scene slowly warps the Yaw input/ control rotation. If I was lucky enough to sort of bounce over it to the other side it would fix itself Except that my horizontal control would be inverted, so rotating right made it rotate left.

avatar image Thumper Jun 23 '14 at 07:15 PM

Now that I have gimbal lock to use for searching I found this post . link text

It sounds like maybe I need to perform this setup using quaternions. Sounds a little fancy but I'll try and see if I can do it. If I wanted to embed in the class source where would I put it? Is this something I could stick in the CharacterMovementComponent? I've been trying to find a spot in there where I could just put a code version instead of having it in BP's. All my characters will have the same rule applied to them so it's fine for my purposes.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

2 answers: sort voted first

The answer from Lina is how I got it to work.

 1) Get the input from InputAxis Turn Event,  make a rotation plugging float from event into the "Yaw" slot.  Leave Pitch and Roll Zero's.
 2) Get Actor Location * -1 ( for me inverted kept the character capsule pointed the correct direction),  
 3) Get Actor Forward Vector
 4) MakeRotZX with result of 2) in the "Z" Slot,  and Result of 3) in the "X" slot.  
 5) Combine Rotation from 1) with Rotation from 4)
 6) set the Control rotation to this new rotation. 

 

This stopped the camera from wobbling as I approached the 90 degree mark (eventually turning/ flipping over onto the character's head as the gimbal lock set in). This also stops the control's turning from reversing on the other hemisphere.

Thanks!

more ▼

answered Jun 30 '14 at 09:14 PM

avatar image

Thumper
966 139 149 388

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

Hello,

The problem with Euler rotation system is that it isn't continuous when you change more than 2 components, and it causes gimbal lock issue.

https://en.wikipedia.org/wiki/Gimbal_lock

Try this,

1) Get rotation vector from player as you did up there (pitch and roll with 0 yaw)

2) Get the yaw value you want as the above graph (yaw)

3) Now rotate the vector from 1) with 2) rotation

4) Now convert that vector back to rotator and set to player

This will rotate the original rotator to "yaw" rotator you want, and give the final rotation back.

Thanks,

--Lina,

more ▼

answered Jun 23 '14 at 09:36 PM

avatar image

nikolobin STAFF
700 14 12 33

avatar image Thumper Jun 23 '14 at 10:20 PM

Are these the proper nodes for getting a rotation vector and rotating a vector from?

alt text

rotstuff.jpg (241.8 kB)
avatar image Thumper Jun 23 '14 at 10:33 PM

The above BP causes the original aiming of the Pitch and Roll to not point at the world center (0,0,0)

avatar image Thumper Jun 24 '14 at 12:46 AM

Yeah I don't think I'm using the correct nodes. The above picture is the closest I've got trying to add the rotation in the way suggested. What ends up happening is the upvector of my character which should be pointed toward the world center, doesn't really do that anymore, it just points up. But I don't think I'm getting the vector "1)" or using rotation from "2)" correctly. It make sense what you're saying but how do I do that in BluePrints? Is this something I should put in code?

avatar image Thumper Jun 24 '14 at 12:31 PM

How do I get the rotation vector? It sounds like I have already done it in the BP I posted, but in step 3 I'm supposed to rotate the "vector" but in my BP 1) is a rotation, so which node should I use to convert it to a vector? Also how do I convert the rotated vector back to a rotation?

avatar image Thumper Jun 24 '14 at 04:31 PM

Is this something that can only be achieved through programming?

avatar image Thumper Jun 24 '14 at 07:19 PM

I'm still having trouble avoiding gimbal lock. I've seen it on a few other posts but the answer seems to be using Quats, but the answer posted in this thread appears to contradict this. Is it possible to avoid gimbal lock by rotating a rotation in steps as suggested above or are Quats the only way to truly do that?

avatar image Thumper Jun 25 '14 at 07:00 PM

Can someone clue me in on which nodes are used for the answer in this post? I've yet to be able to Rotate a rotator, or convert a rotation to a vector.

avatar image KnightTechDev Apr 28 '15 at 04:13 PM

Gimbal lock.

avatar image shrike13 Aug 13 '16 at 11:44 PM

Really helpful.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question