Closed ssbucarlos closed 1 year ago
Is compensate_scale set to false on export? I'm pretty sure we bake that into the scale when importing since this setting only exists in Maya.
I'll need to double check as previously the intended behavior was to keep track of the the scale options and re-export those scale options along with the same values set from import. The recent push i did was to re-export the scale options if they are set, however if scale is now baked in on import im not sure when that was done.
I remember you suggesting that the scaling should be baked in and we can just export with the default scale inheritance behavior (i believe thats inherit_scale=True and compensate_scale=False), and the more i think about i do think thats the better option overall.
If it renders properly in Blender on import, then we're baking the scale compensation into the scale value. We should be able to link the inherit_scale property to the Blender bone inheritance scale setting. The defaults should be inherit_scale=True and compensate_scale=False like you mentioned.
I think it renders okay in blender because there's a driver on the bone's scale inheritance. However it only considers 'inherit_scale', and it only toggles between 'Full' and 'None' for scaling inheritance
Ah i see the baking for scaling when compensate_scale is present was implemented, good work im sorry i didnt notice till now
I did some more testing and found that the ScaleOptions.inherit_scale
field doesn't seem to have any effect on scaling inheritance. I can reproduce in game tests for bone chains with different scale options just checking if compensate scale is enabled. It may be related to how they handle non uniform scale in game. Importing Sonic's fsmash in Blender gives me what looks like shearing issues regardless of how I treat the scale compensation.
I'll keep looking into accurately replicating the scaling behavior in ssbh_wgpu (SSBH Editor's renderer) and let you know if I find anything. There may be other unrelated scaling issues in Blender that need to be handled separately. It makes the most sense to fix things in the order of ssbh_wgpu -> Blender import -> Blender export.
This won't have any impact on the move to 3.1+ since we can just handle any potential inaccuracies with ScaleOptions
field names internally in the addon. You can find the ssbh_wgpu_tests starting from here: https://github.com/ScanMountGoat/ssbh_wgpu/blob/d2c3e1a6f5d89d5e553cc8b187ff40e63198f743/ssbh_wgpu/src/animation.rs#L1045
thank you for looking into this. pls lmk what u find and i can port the fixes to blender. ill take a look at ssbh_wgpu as well to see how its currently implemented
Changing where the scale compensation is applied when creating the transformation matrices seems to fix the issue. It's most noticeable on the length of the arm and wrist. Once I have the test cases finalized for ssbh_wgpu, I'll try and port this fix to Blender.
SSBH Editor (0.6.4):
ssbh_wgpu (WIP):
oh wow this is big actually, thank you. Im actually in the middle of re-writing anim import, so i can take care of the porting myself once im done with it. Im trying to massively speed up import by writing directly to the keyframe points in the bones fcurves rather than setting the bone matrix every frame and inserting a keyframe every frame and updating the scene each frame.
Scale compensation is applied while creating the transform matrix from the rotation, translation, and scale. You can find the ssbh_wgpu code here: https://github.com/ScanMountGoat/ssbh_wgpu/blob/f740f0d5a846527baadeee078773444d131b8293/ssbh_wgpu/src/animation.rs#L81-L88
ah ok, now that i got the 3.1 update merged and the fast anim import done i will take a look at fixing this now using the ssbh_wgpu code as reference.
Allright im getting around to porting the compensate_scale logic. My first pass of the implementation gets results that look pretty close for sonic fsmash (but its noticeably wrong on the wrist area) but its terrible for his jumpf anim so i think i may be close i just messed something up somewhere
ill let you know when i figure it out or get stuck
Beautiful
After doing some investigation in #157, it looks like we don't have to key scale compensation or scale inheritance. We can just set both values to false on export. Imported anims should always have scale inheritance enabled for now.
The exported animations match what plays in Blender now for scaling and the flags are being set appropriately on export. It's weird that the compensate scale baking doesn't work properly despite being almost identical to ssbh_wgpu. I've moved that discussion to #174
Imported vanilla animations with scaling dont always export correctly. Tested using Sonic's fsmash.