Pelvis rotations cause avatar to jolt (SL Bug?)

[Kylie Remsen]

Hello, I've been having problems more recently with pelvis rotations within blender & using avastar. I have made roughly over 500 animations in the past using the same program/plugin versions and I have never seen this happen before. What happens is when the pelvis is rotated with curves; the entire body of the avatar jolts once it is in SL, otherwise it looks perfectly fine in Blender. Here is what it looks like in Blender: https://gyazo.com/e745e52fc1abfad26dcec32c47c71001 and here is what it looks like once it is imported into SL: https://gyazo.com/c056342957fff3b2122b3441ab103532

As you can see, there is a major problem here, and I'm thinking maybe it's a problem with SL itself. I always export and upload in .anim format. The animation is running at 30fps (iv'e tried slower) and iv'e also tried exporting it with other settings, like; use translations.Also I had the avatar enabled with IK's set to 1.0. I even tried moving the avatar in certain positions from the origin, with still no luck. Has anyone at all got any idea why this is happening? I'm surprised no one else has reported this that I have not seen. Any input is deeply appreciated.

This issue is basically showstopping my work.

 

Versions used and tested: Avastar 1.0/Blender 2.69 and Avastar 2.5.1/Blender 2.79

Viewers tested on: Firestorm 6.0.2.56680, Second Life Viewer 6.2.3.527758

- Kylie Remsen @ Silent Motion

Edited August 20, 2019 by Kylie Remsen

[OptimoMaximo]

On 8/20/2019 at 3:18 AM, Kylie Remsen said:

What happens is when the pelvis is rotated with curves; the entire body of the avatar jolts once it is in SL

I might be completely off, and this would apply only if the avatar you're using is Bento.

Not everyone remembers that there are additional spine joints, just overlapping back and forth between mTorso and mChest. Also, Avastar has a targetless IK enabled on all joints. So what I'm thinking is that, perhaps, editing the curves is affecting the rotation on mSpine 1 or 2 through the targetless IK modifier. I've never seen that happen myself too. There are two possible solutions at this point: trying to remove any keyframe on all the mSpine joints if there are any, or disable targetless IK that runs through the mSpine joints (all of them) in case they don't have any associated keyframe.

[Kylie Remsen]

4 hours ago, OptimoMaximo said:

I might be completely off, and this would apply only if the avatar you're using is Bento.

Not everyone remembers that there are additional spine joints, just overlapping back and forth between mTorso and mChest. Also, Avastar has a targetless IK enabled on all joints. So what I'm thinking is that, perhaps, editing the curves is affecting the rotation on mSpine 1 or 2 through the targetless IK modifier. I've never seen that happen myself too. There are two possible solutions at this point: trying to remove any keyframe on all the mSpine joints if there are any, or disable targetless IK that runs through the mSpine joints (all of them) in case they don't have any associated keyframe.

Hi Optimo, I was hoping you were going to respond, so thank you! I really appreciate it. I tried this in avastar 1.0 and the latest version - It happens on both. The demonstration above was from avastar 1.0 pre bento, and i added key frames as i usually do on the default rig bones. I didn't seem to add any key frames for any other special bones.

 

Update: tried fiddling with tarketless IK on some bones (to be honest, I ain't got a clue on what i'm doing with that) and tried a few different positions - still problematic.

Edited August 21, 2019 by Kylie Remsen

[Kylie Remsen]

I have discovered what the problem was, and indeed it is a bug. Apparently if the pelvis is animated while the avatar is facing in the +Y direction in blender (back towards the default front facing view) then this problem will happen once you import the animation into SL, however - If you animate the avatar in the -Y direction (Avatar facing towards default front facing view) then there is no jerky or jolting movement to the entire avatar.

Sigh of relief! but I'm still a bit bothered why this is happening. I believe that maybe if your avatar is facing opposite of your Origin marker then somehow it's fighting eachoher -  i'll test different variations of this near future. If any future people come across this issue while they have already spent a lot of time working on a animation, select everything and all key-frames except "possibly" the origin and rotate the entire avatar/objects in the opposite direction, then export and upload that way.

I can safely say this has partially resolved my problem, but if anyone else needs to post anything to make things more clearer why this is happening, then please do. Thanks - 

 

- Kylie Remsen @ Silent Motion

Edited August 22, 2019 by Kylie Remsen

[OptimoMaximo]

8 hours ago, Kylie Remsen said:

select everything and all key-frames except "possibly" the origin and rotate the entire avatar/objects in the opposite direction, then export and upload that way.

ok so, just to get this more clear: you made the animation with the avatar facing back by rotating the Origin bone on the grid floor? Because that makes a bell ring for me.

It is most likely a Blender bug in how math is being performed. In the Avastar python code for anim export, rotations and positions are being calculated doing some matrix math in order to switch the reference frame (the world) to match that of SL anim format and retrieve the correct coordinates. The problem should arise (if i remember correctly, i have no time right now to check) because location data is being retrieved from the Origin bone as reference for the actual avatar position inworld (the character controller that moves the avatar around, which is the position reference point), while the rotation values are being calculated from the world coordinate system (i think for an easier reuse of the matrix calculation code), because quaternion rotations default to the world's 0,0,0 location and using the origin would have required a lot  more math on top of it, with the resulting risk of things not working properly (or at all).

Anyway, as a general guideline, the Origin bone should be used only for positioning the avatar somewhere in the scene (i.e.: next to a prop the avatar should interact with), while the actual movement around (including its rotations) should always be performed using the COG bone.

[Kylie Remsen]

18 hours ago, OptimoMaximo said:

just to get this more clear: you made the animation with the avatar facing back by rotating the Origin bone on the grid floor?

No Optimo, The avatar and origin need to be facing in the same direction for this bug to not happen. If i leave the origin and only rotate avi via COG in the opposite direction, then problems with pelvis will arise. So i'm thinking the glitch happens mostly within a small degree where the COG and origin face each other head-on and then the problem happens.

The attached image will show the setup which will cause problems if you do any rotations on the pelvis. (note: that the avi could also be standing inside the origin facing this way and it would still cause problems)

Edited August 23, 2019 by Kylie Remsen

[OptimoMaximo]

@Kylie Remsen ah i see, then it's a inherent issue with quaternion rotation curves in Blender, that in theory should not be present but that 3d apps deal with. When a rotation reaches 180 degrees, the direction of the rotation motion inverts (the object rotates the other way around) . If that rotation stays below 180, I'm pretty sure this glitch would not show up. This is a problem i addressed in my animation plug in, where the animation process relies on euler rotations and only upon export there is a quaternion extrapolation. If you open the side panel with N key, I'm pretty sure you should see rotations being set to quaternions. Delete all keyframes and change that setting, then animate again: the glitch should be gone

[Kylie Remsen]

4 hours ago, OptimoMaximo said:

Delete all keyframes and change that setting, then animate again: the glitch should be gone

Hi @OptimoMaximo x

I tried animating with the XYZ Euler option that you described and tried it in SL, and it's still glitching out.

Little update: Yesterday I rebuilt a problematic animation, but this time I had her facing in the same direction as the origin, there I just flipped her 180 degrees on the avsitter furniture and there's no problems at all now, it looks very nice and has no visible jolting motion.

Image: Using XYZ Euler on rotations.

Edited August 24, 2019 by Kylie Remsen

[OptimoMaximo]

On 8/24/2019 at 4:44 PM, Kylie Remsen said:

I tried animating with the XYZ Euler option that you described and tried it in SL, and it's still glitching out.

Then it's definitely a problem with quaternions evaluation in the entire scene.