Can someone explain to me what is going on?
After I’ve imported an animation (keys are created on every frame)… if I scrub the timeline manually the animation plays just like the original file in Softimage (or Softimage Mod Tool– free). But when I playback the animation in the timeline player (at any speed), I see the left knee area “wobble” but not flip.
So I turned on trajectory for the Dummy helper… and scrubbing the timeline manually it follows the trajectory– time is set as “Frames”. But if I set time to “Frames:ticks” or other format and then scrub manually I can see the anomaly– where the dummy is “bouncing away” from its trajectory over frames 6-8 of the animation.
How do I stop this sub-frame wobble???
I will attach a scene file later.
#1 try to render this animation
#2 assign linear controllers everywhere
Thanks Denis for your reply… attached is a zip file containing the original dotXSI 3.0 file and my Max8 imported result… My maxscript dotXSI importer that I’ve written is what I used to import the file– because the old Softimage dotXSI importer plugin and Crosswalk leave all nodes in the +Y up Softimage coordinate system… and I’ve done a proper coordinate transformation to import it into 3ds Max to +Z up coordinate system.
As you first suggested, I’ve rendered out the animation to an AVI and the sub-frame anomaly does not show up.
Hi Michael,
I’ve been playing with it a little more and I think I’ve found the issue, but I haven’t gone thru an extensive test.
When setting the Time Display to Ticks, Max does interpolate the animation between the keys when you scrub the timeline manually, so I suspect that the anomaly you see in the leg is cause by this interpolation.
If you render out the animation you don’t see it as the motion is based on the keys themselves, and as it is a per frame animation, there is no interpolation.
The “L_lower_leg” dummy inherits rotation from “L_upper_leg”, which seems to be the culprit of the problem.
I set the Rotation Controller of “L_upper_leg” to TCB and it seems the problem is solved. However I can’t warrantee the animation wasn’t modified so you’ll have to check it by yourself, but I suppose it is correct.
Perhaps you could try replacing all the Rotation Controllers by TCB Controllers in the Importer Script and see how that goes. Or try with Linear Controllers as Denis suggested, although Max needs to also interpolate the Linear Controllers and there is a little deviation from the source motion, but it is much less noticeable.
Hmm… curse that Euler_XYZ controller!? Well, I did import the animation using the Softimage Max6-8 dotXSI importer plugin… but it doesn’t import the skin weights or create skin modifiers– so the mesh is imported in the root skin pose and is static… but in playing the animation on the dummies I don’t see the anomaly with the legacy importer plugin– however, they specifically used “Linear Rotation” controllers on all dummies (the second point @denisT made).
Well, it is annoying to see that “wobble” when you play the animation– so I could consider replacing the default Euler_XYZ controller to either TCB or Linear… perhaps TCB would be better?
If the source animation uses Linear Controllers then I would use just Linear Controllers. There is no additional information in the source to build a curve based controller. As this animation is per frame, I also see no reason to use anything different than a Linear Controller.
However, there could be per frame animations with specific curve information to be used in a specific way in another application. For example if you have an animation that at some point will play in slow motion, and the engine will do the interpolation based on the by frame keys, and the motion needs to easy in/out in a specific way, then I would use a curve based controller.
I tried a “lazy” check in the Import Script and it seems to work. At the very end of these two functions ( Get_SI_AnimationKey() and SetAnimation() ) I just added:
o.rotation.controller = tcb_rotation()
It didn’t work when I set it to linear_rotation(), but it can be due to incorrect setup as I am not touching anything else.
For a proper implementation the functions would need to be reworked, but this little “hack” was useful for testing.
Thanks. Probably the easiest place would be to redefine the controller just after the Dummy is created.
if animation was exported as key-per-frame it doesn’t make any sense to use not linear controllers. if you need to reduce keys you can change to controller type which better fits reduction method.
Thanks @denisT – I would like to maintain flexibility… retarget onto another character rig… perhaps reduce keys or tweak the animation– but in the end it has to be exported back out as a dotXSI 3.x file with keys per frame for the old game model compiler to compile it back to a Ghoul2 format (It’s an older game engine).
it means that all controllers should be linear.
actually… here is a challenge:
>>>> replace all bezier float controllers used in transform of specified nodes with linear float preserving all keys <<<<<
Ok… I accept your challenge
FYI… changing the rotation controllers to TCB_Rotation() eliminated the “wobble”. Also, for my convenience, I simply redefined the Dummy helper controllers right after the line in my script where they are created– so before the animation is ever imported. I put Linear_Float() subcontrillers under the Position_XYZ() controller and changed scale to Linear_Scale()… in addition to TCB_Rotation() change mentioned above.
I’m pretty sure I tried that first and it didn’t resolve it… (I’ll give it another quick try).
EDIT: Yeah, Linear_Float() sub-controllers under an Euler_XYZ did not solve the wobble. But changing the rotation controller to TCB_Rotation did resolve it.
why do you love tcb rotation so much? ok. you can use linear_rotation… or you can use any rotation controller including euler if you convert three components you get from source data to quaternion before set it.