Won't fix Major issues with smooth animation reset

[Spacedog]

I have been doing some animating for the first time since the new version and there is some huge issues with the new smooth animation reset.

The reset procedure is not nearly precise enough for detailed animation work, especially if you animate the hip. The way people reset means that while the animated node goes to the right place limbs don't return to the exact place they came from, breaking animations and causing endless hassle trying to reorder limbs and get them back in place every time.

While I can work around this by rewinding using the slider which actually returns limbs where they came from like the old system did, it gets even worse doing mocap with Timeline. Instead of using the shortcut buttons to clear or record mocap in Timeline, now to avoid glitching I have to manually go back to the animation window, stop the playback, rewind the slider by hand, clear animation data then go back to Timeline to record, and I may have to do this many times for every node of every animation I make.

I know this is late to the game but I literally can't build big scenes like this, there needs to be an option to override this smooth reset behaviour.

 

[Spacedog]

Just to illustrate how bad this is, try the scene Sofa Ride form my Best Laid Plans scene. If you skip the animation forward then back to the start she should be giving him a handjob but almost always her hand either misses completely or gets near and barely grabs it. If you quickly slide the animation slider back to the start she grabs it perfectly every time, just as she did with the old animation reset system. I have many similar examples, I simply can't work with the unpredictable behaviour of this current system. https://hub.virtamate.com/resources/jack-and-freya’s-best-laid-plans-remastered.182/

 

[meshedvr]

I assume you mean the SeekToBeginning action (which is also what the << does). The old behavior was problematic in many situations as well. If you have large movement of nodes, the SeekToBeginning would only move the control, and then it could cause the physical node itself to not properly align or get tangled with other objects on such a large move. Now the SeekToBeginning action forces the node to align with where the control is, but this can be a problem if your physics node is offset quite a bit from the control node at the start of the animation. Unfortunately there is no perfect solution in a physics-based world like this. When you scrub the playback counter backwards to beginning it would work much better because you are essentially playing all the steps in reverse and things have a better chance of not getting tangled. But big jumps lose the intermediate points and can cause issues.

I'm not going to be able to fix this for 1.X. 2.X will have a different physics system and for animation I might also store the physics node position/rotation along with the controls themselves. This will allow precisely accurate animation as an option (sometimes you want physics to be able to modify the animation), scrubbing, and fast seeking.

As an alternative to using SeekToBeginning trigger action (or the << button), you could set playbackCounter parameter to 0 directly. If you want to do exactly what the old SeekToBeginning did a plugin could do this with the following code:

MotionAnimationMaster animationMaster = SuperController.singleton.motionAnimationMaster;
animationMaster.playbackCounter = 0f;
SuperController.singleton.ResetSimulation(5, "MotionAnimation SeekToBeginning", true);

 

[Spacedog]

There is no perfect solution, but unfortunately we've gone from one which rarely fails in long scenes, which don't tend to need rewinding frequently and can be fixed with scrubbing the slider to one that fails completely in the ones that need the most.

It breaks the core of my workflow, and I think it will trip a lot of users up who don't know why their animations are breaking.

I will investigate your fix but I worry that it won't resolve the Timeline part of the issue, which is the most serious one. Building scenes is difficult enough as it is without adding extra layers of complexity.