Revert model to non-animated state

dwn

New member
It appears that I just lost several hours work on a model when I accidentally switched to an old animation take, which overwrote most of the model properties and scrambled everything. Undo apparently doesn't work on changes made by a take.

Is Cheetah animation actually a destructive process (i.e. overwrites the original model properties), or is there some way to clear/remove animation and revert to the non-animated model?

If it's destructive, what kind of workflow do you use to work around this problem? Is there a way to XRef a model so it can be animated in a separate file or something?

I expect to have to update animations when the model changes; I don't expect switching animations to destroy a model beyond recovery.
 
Just a wild guess:
You have an already rigged character and wanted to alter some geometry of it? That is not going to work by any chance. If you add/subtract polygons of a rigged object the weight-map goes haywire - simple as painful at the same time. If that´s the case I´m surprised that Undo (you can have up to 100) did not work. At least you could close the document without saving and return to the stage before you messed up things. ;)
How does the model look in the other take? Just in case it looks ok there - delete the messy one then.

Cheers
Frank
 
Last edited:
That's more or less it. I was scaling the model to make adjustments easier and reworked a few meshes in the process. I fully expect the animations and weighting to break when modifying the model, but what caught me off guard is there was no way back once the old animation take had overwritten the heirarchy. I'd actually just finished re-rigging the character before everything exploded.

The one (good?) take had no keyframes in it, so switching back did nothing. Closing the document didn't help, either, since autosave had already overwritten it by the time I'd figured out what happened. I'm also surprised undo didn't work. My guess is that switching takes is the equivalent of changing position in the animation timeline, and therefore not registered with the undo manager. Were such changes undo-able, then hitting 'play' on the animation would rapidly fill up the undo history.

Fortunately, I had a Collada export of the new version that I was able to import. I had to re-apply all the seams and whatnot, but that was likely faster than completely redoing all the new changes.

I feel like I'm missing something here. I've never before used a art package where animating (or even viewing an animation) was a destrucive action. Surely there has to be a way to get back to the non-animated form of a model.
 
Last edited:
It´s the first time I´m hearing from such an experience. Autosave don´t overwrite any file - it´s generating a new one aside the one you´re working on and will replace the last state in case of an app crash.
In essence it´s modelling (including UV-mapping/painting) - rigging - animating - in that particular order. I still don´t understand why "Undo" didn´t help.

Cheers
Frank
 
Then I'm not sure what happened with the file, since the saved version was still mangled. Either I accidentally saved while trying to fix the problem, or the saved version had stray keyframes that were getting applied on load.

The undo thing is easy to replicate, though. Say you have a model with two takes: take A contains no keyframes; take B has keyframes that modify something. In take A, change a visible property for which keyframes exist in take B. Switch to take B; the property is overwritten. Neither undo, nor switching back to take A will recover the changes you made.

From a technical POV, you would typically have a canonical model state (bind pose, T pose, whatever) and a visible state. Switching takes or playing animations would overwrite the visible state, but not the canonical state. Deleting FCurves (or turning off animation entirely) would return affected properties to their canonical state. Copying visible state to canonical state would require some kind of explicit "bake" action.

My guess is that Cheetah only tracks a single "current" model state, or that its animations are overwriting the canonical state.

Unless someone can suggest something better, my current workaround is to put an identity pose on the root node and obsessively keep it up to date. I may also use separate model and animation files, but that's fairly annoying to manage without xrefs of some sort.
 
I've mangled my files a few times with animation too. I now do keep a static version and then copy those models into a new scene for animation. I started with C3d though, so it wasn't too abnormal for me to get accustomed to that workflow. The majority of my models are mechanical based on our sign companies products though. So that may be why it's not as big of a deal to me?

I haven't done much animation in other 3d apps, even though I have a few.
 
Could you record a static "Take" and just keep that untouched? Then, do all your animations in other takes? In Cinema 4D, I used to keep a default pose saved at a -7 on the timeline, figuring I'd never go back there when animating.
 
Back
Top