Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice

Problem creating animation based "look" movement

Discussion in 'Animation' started by ParkerP96, Dec 21, 2019.

  1. ParkerP96

    ParkerP96

    Joined:
    May 15, 2019
    Posts:
    6
    Hello, I rarely resort to posting into forums without a very deep search first or a lot of attempts but I am seriously losing my mind and a lot of time for this.

    I am making an fps game and I'm working on animating my character. (I am new to the unity animation system and i tried both the legacy and the mecanim systems).

    My character doesn't have two separate models for third person and first person, it's one model animated to look seamless in 3rd and first person.
    I want to make my character look up and down based on my camera rotation.
    For looking down, I rotate the first spine bone of my character down through code because it looks natural enough, the rotation is precise, perfectly on axis, no trouble at all.

    Now I want to be able to look all the way up and to aim down the sights.
    My plan is to create an additive animation for looking up and controlling the time based on the camera angle.
    So if the camera angle is 0 degrees, the "look up" animation will be at frame 1 or normalizedTime = 0. If the camera angle is at a specified point say 75 degrees, the animation will be at its last frame or normalizedTime = 1. Note: the x rotation of the camera (up and down) is controlled by MouseY.

    This works, except for the fact that for some misterious reason the bones don't follow the animation I created in my animation software, which causes the rifle that is attached to the wrist bone to sway left and right while aiming up and down, which is definetely not what I want. This also happens if I disable the other animations and use the lookUp animation as Override and not as Additive, because one might intuitively think: it's probably because the lookUp animation is adding position and rotation for each bone on top of other running animations because it's additive. But no, that is not the case. Yes, setting it to override does decrease the sway a bit, but it's still not 100% accurate as in my animation software (i made sure that in EVERY single frame, the rifle did not sway and remained perfectly on axis).

    I also tried unchecking all animation compression on the animation import settings and every other setting that might make the animation less accurate and surprisingly it made the sway even worse (the rifle started tilting up and down aswell because the wrist bones were doing weird stuff). So in my eyes it's definetely something that has to do with the accuracy for the imported animations.
    Here's some pictures to make it clear:

    This is the neutral position with the lookUp animation set to additive (the sights are not perfectly aligned because an idle animation is also playing):
    https://imgur.com/n2pruLv

    This is the distortion that happens to the animation while the animation is about 1/4 of the way up (the lookUp animation is still set to additive):
    https://imgur.com/BIltDcB

    This is the neutral position with the lookUp animation set to override:
    https://imgur.com/LvtG6PF

    This is about the same amount of the way up (about 1/4 of the way) with lookUp set to override:
    https://imgur.com/GlC05zY

    As you can see when the lookUp animation is set to override it is much more accurate when playing the animation but:
    1) the distortion is still noticeable when playing (there is some distortion, look closely)
    2) i don't want the animation to override because i want other animations to play at the same time.

    I also tried separating the animations i want to play in the background and the lookUp animations with avatar masks (lower body for moving around, upper body for looking up and down), but no luck, the weapon still sways left and right. Of course I did the same thing with the legacy system by using MixingTransforms and no luck there too.

    Before all of this I tried the legacy system because i like doing most of the stuff through coding.
    I tried fiddling with setting up the root bone and applying root motion on the rig import settings but:
    1) it didn't work.
    2) i don't even know what it does.

    If anybody who went through something similar can tell me how to achieve what i'm looking for (which is natural lookingUp movement through animation) I would be infinitely grateful. I just cannot find a solution, I've been actively trying to fix this issue for about 6 hours a day for the past week.

    I apologize for the length of the thread but at least I think I expressed my problem well enough. If not, I am up for a Discord call or to share the project with you.

    EDIT: just wanted to say that:
    1) the mouse x for the player rotation is locked so it's not like it's me moving the mouse left and right when also moving it up.
    2) i am also noticing inaccuracies in joint position in other animations as well.

    Thank you.
     
    Last edited: Dec 22, 2019
  2. ParkerP96

    ParkerP96

    Joined:
    May 15, 2019
    Posts:
    6
    Ok so I found the problem. The problem is not Unity, the problem is Maya not baking the animations correctly.
    This is how I found out:
    1) I baked the animation onto the joints
    2) I increased the fps on the Maya time slider so that i can see what happens between the frames of the original version (24 fps), and I can see that in between the baked frames the positioning of certain bones (both wrists in my case) is completely off.

    This explains why when disabling the animation compression setting in Unity (to make the animation closer to the original file) it just made things worse. Unity was trying to approximate the position and rotation of the joints by removing some keyframes in the middle and approximating the curves but it still wasn't 100% accurate because the curves of the warped bone positions were still affecting the approximation slightly.

    It also explains why the other animations are not 100% accurate. The same problem just kept repeating itself each time I was baking the animations onto the joints. I have no idea why the animations are not being baked correctly, but it is happening.

    I believe this is because of my very limited experience in animation. I may have deleted some history that stored important information (I'm animating in Maya).

    I'm sorry for the long answer again and for answering myself so quickly. I'll come back to the thread after I'll have redone the rigging and the basic lookUp animation.
     
  3. ParkerP96

    ParkerP96

    Joined:
    May 15, 2019
    Posts:
    6
    Ok I said I would come back. I have found out what the problem was and in doing so I learned an awful lot of stuff.
    So the problem was that I was having gimbal lock on my wrist joints because of improper joint orientation and rotation order.

    I have redone the entire rig from scratch and the lookUp animation with the new rig and with the right rotation order and joint orientation the situtation improved dramatically, but still not enough because some distorsion was still visible. So I went for the brute force way.

    I made the animation 4000 frames long so that the distorsion due to gimbal lock was going to happen in a super small frame range compared to the whole animation (only 4 or 5 frames had the wrist inaccuracy and even then the distorsion is quite minimal. Furthermore, Unity resamples the animation curves when importing animations so the chances of having it sample one of the distorted frames is about 4/4000).

    I'm certain this is not the way to correctly fix it and it is not mathematically 100% perfect in-axis rotation, but the rotation is close to perfect this way because no wrist rotation inaccuracy is visible. The resulting animation file is large (about 15MB) and doing this repeatedly is going to be very bad for optimization I guess so I'll have to do it only if the animation requires perfect accuracy, but it works.

    For anyone having this problem in the future (which I'm certain a lot of people are having because I can see that it is extremely easy to bump into gimbal lock) I would advise you to use my approach only as a last resort solution after you try and solve the problem in a better and smarter way (yes my tiny little brain couldn't come up with a better solution unfortunately lol).

    Thank you all for you attention.