90 Y Rotation on Root Motion after last keyframe, not sure how to change as 1st and last are the same

Hi,

thank you very much for your support request.

I tried to reproduce this behavior in a quick test setup, but the rotation looped correctly in my case. The issue you are discovering might be dependent on your current project/setup. May I ask you to send me your UMotion project file and the corresponding 3D model as a *.unitypackage, so that I can take a closer look? You can send it to me via the email support form (if file size exceeds the email limits, you can request a link to my Dropbox via said form).

Also please double check if your UMotion version really is V1.23 (in the Clip Editor click on Help --> About UMotion). Just to ensure where both on the same version.

Thank you very much.

Best regards,
Peter

Thanks for the quick response! 

I just sent a .zip of the FBX and project file, as requested.  I also verified the version is 1.23.

Thanks for sending me the *.zip. Looks like the included *.FBX is not compatible with the provided UMotion project (it has a different skeleton). Please send me the correct *.FBX of your character.

Best regards,
Peter

Sorry for the delay, I can never figure out how to easily export from Unity, as my projects are huge.  I think this has all the required files:

https://drive.google.com/file/d/1un3L3uBfpDVJWK8YCzHdcdxba17GuMsS/view?usp=sharing

The upload site didnt work this time.  No error, just didnt seem to accept this, so this is a "anyone with this link can download it" from Google Drive.

I found that it was not just the Animation, its something about the Model in the scene.  I have 2 videos of this.  One from inside my scene, where I make a new Clip1.anim (Exported as "Assets/_Assets/UMotion/Clip1.anim" file), and in the original scene I am working from, it rotates 90 degrees with every repetition of the animation.  Playing it once does not rotate it, only when I loop the animation.

When I made a NEW scene, and brought in the same model, and played the same Clip1 created in UMotion, it did NOT rotate 90 degrees on looping playback in the Clip Editor window.

So the specification of this error has changed.  It's not that a certain animation causes the 90 degree rotation on loop. 

It is now that IN my original scene, the Umotion playing this model in a loop (Clip1) will rotate it 90 degree if I playback on look in the Clip Editor.

In the same project, in a new empty scene, Umotion playing this model in a loop (Clip1) will NOT rotate 90 degrees on playback.

- The model is the same

- The animation (Clip1) is the same

- The project is the same, same computer, Unity version, Umotion version

- The scene hierarchy is different.  "Complex" FPS scene vs New Scene with model imported.

This is a video of the loop of Clip1 in the new scene, NOT rotating on playback loop:

Here is a video of the loop of Clip1 in the Original Scene (FPS game), where the model does rotate on each playback loop:

Thanks again!  Sorry for the delay and initial misleading report on the animation being the issue.

Let me know if I didnt export something you need to investigate, and I will get you what you need.

I did further experimentation, and if I take the model out of the FPS rig, it does not rotate 90 degrees per animation loop.

It did do that in a new scene too, if I left it in the FPS rig.

So this problem has nothing to do with Umotion, and is solely something to do with the FPS rig.  No idea what, but I can troubleshoot that myself.  Thanks!

Actually, that assessment is premature.  Making a new video to show what is going on.  Its bizarre.

This video explains the actual bug:

The problem is this:

- If, the Umotion Pose Editor Selected Game object is parented to another object

- And, that parent object has a non-0 rotation in the Y axis

- Then every playback loop of the animation, the model will rotate by the number of degrees in Y of the parent object's transform.

I dont know if that is a Umotion bug or what, but Ive never seen anything like that before.  I can get a workaround by just setting the parent object's Y rotate to 0, and then it does not rotate each playback loop.

I verified this by going back to my original scene, and playback with loop Clip1 with the base parent Transform at the original -96Y and at 0Y.  -96 Y rotates around each loop.  0 Y stays in place.

Thanks for your detailed investigations. You are absolutely correct, the issue is related to the parent GameObject's rotation. I consider this as a UMotion bug and am going to fix this with the next patch release. In the meantime, please zero the rotation on the parent object as a workaround.

Thank you very much for reporting this. I'm going to keep this thread updated about the progress.

Best regards,
Peter

Thanks!  Glad to help out.  Using the 0 rotation works fine, so not an urgent bug to me.  Not blocking.

There also appears to be an additive effect on Position.

I just recorded an animation in the scene, and then when it played, it moved my model up by the height of the offset.  So any sort of non-zero Position seems to effect the resulting animation.

It would make sense if the model moved during the animation, but is the same position the entire animation, but the transform is higher, so it exports with a raised position.

I only saw this on the Y position as well.  XZ looked stable.

UPDATE: Im not sure Im not having a different issue here.  I think I may be doing something wrong with generating keys from the Muscle Group editor into an Override Layer, and it is putting my model up higher.  This the above report may be wrong, and it may be something to do with how Im using the muscle group.  

When I create the muscle group initial key, I see my model go up.  If I delete the key, it goes back down.  Consider this new information to be incorrect for now.  I dont know what Im doing wrong, but it may not be the position transform at all.  Im not deleting it, just in case it is useful. 

Update on the position additive effect.  I was able to make more animations without this, so I think this was something I did that caused the position to be changed.  I dont understand what happened, but I dont think it's related to the container rotation issue.  So that can be ignored.