Hello, i’m actually starting to design and code the animation part of the pipeline for my studio. So if you have a given shot in a given version, you have a bunch of animations for all characters/props, and you can publish a version of your animation and rollback your animation to older versions.
I have two kinds animations exported : one “normal” and a geocache version also. For the geocache, I use Alembic and for the moment I’m pretty happy with the results.
For the “normal” version, i was thinking of using animImportExport module from maya. It seems to work fine, but then comes THE issue I remember having to discuss for hours in all the studios I’ve worked :  what about the constraints?
Here is my workflow: i have my character, for example Ogre_chr (group node) and i export all anim below that node and call it Ogre_chr_Shot101_v01.anim. But if there’s a constraint outside the ogre, it won’t be exported. I could take the anim of the object that is constraining and add it to my .anim, but imagine two characters interact with one same constraint : saving versions of both characters will cause issues when you play around with loading different versions of both characters.
I can’t recall how we dealt with this problem in my other studios.

Is there a good solution for this kind of problems?

thank you

The best way we found when exporting reusable animation which rely on constraints, was to bake them out with Edit -> Keys -> Bake Simulation.
Its not that pretty and the smart bake options can be crap, but a simple cleanup script normally does the job afterwards.
Its been a good workaround for multiple applications really.

Lee Dunham | Character TD
ldunham.blogspot.com

The thing is I already have a baked animation with my geocached files. What I want is allowing the animator to rollback to any version of his animation he wants. If i bake the animation, it’s not that interesting for him anymore… Well it might be if I clean up the curves as you said. I will try to find out a little more about it, but it’s already kind of problematic for me:
imagine a char that picks up a bottle. The bottle is constrained to the character I save the anim. Then i change the anim of the character and save it as v02. If i leave my constraint as it is in my file and rollback to anim_v01, since i didn’t bake anything, the constraint is preserved and the animation works. If it’s baked, the bottle will follow the hand only for the right versions of the animation for the bottle and the char. So keeping the constraints can be useful.

But now imagine an animated aim constraint (for the eyes of a char for example) : the character is moving his head down and the constraint is going from right to left. I publish my anim as v1. I change the anim so he’s looking up. Save it as v2. now i change the animation of the constraint, so it doesn’t move for ex. If i load v1, i don’t really have my v1 anim since the constraint doesn’t move anymore. If i had baked my anim, it would be fine.

So in one case baking is cool, in the other it’s not. Add to that that I have also a shot versioning system, the outcomes of changing the versions of the anims of my assets can get really really messy. And i don’t really know what to do.

When you say versioning of animation, do you mean exporting the animation out into files with an animation import/export tool, or so you mean resaving the scene file?

We have come across similar situations where our setup of versioning animation with an import/export anim tool, proved useful.

eg picking up/moving a bottle. Any props we use have simple skinning and controls, so using constrains is handy until anim is approved then we bake the constraints (then clean up) and export the anim for the character and the prop - with links to one another, so if an animator wanted to use the animation again, they load both in so it matches and if changes need to be make then it makes sense to simply reconstrain again (we have a setup to make it very simple and easy to make constraints and break them, without destroying any work prior to the breaking, makes it easy to pick up and put down props).

Im abit confused about the second example but a usual setup for eyes would be that they’re aimed to a control, what may or may not be constrained to an object so it follows what it needs to, which again would then be baked down (on the control) and cleaned up, if the animations being versioned (exported).

Does that help or am I getting the wrong end of the stick? lol

Lee Dunham | Character TD
ldunham.blogspot.com

yes actually it makes perfect sense for a prop and a char for example. now for two assets it gets more complicated (forgot to answer your first question: yes i’m trying to see if we’re gonna export only animation with an anim import/export tool).
my second example was not very good, because of course aim controls for the eyes are in the rig, so no problem about that, it was just to make a point.
The point is: if you have a same constraint for two assets in the scene, it neither belongs to one or the other, but to both at the same time, so it can only be reactivated if both assets are present. In the case of picking up things it works, but i’m pretty sure for certain cases there will be conflicts.
So i think baking only the constrained parts of an asset and exporting could be the easiest and most robust solution.
Because i could also build my own data format for constraints and save it along, and load it only if all assets participating in the constraint are loaded, but it seems much more complicated.
I’m also trying to see with my boss if we can only version the scenes and do a tool that in case an animator really wants to roll back an anim, it loads the versionned scene required, exports its anim baking the constraints, and loads it in the current scene. It’s just that since here we work on small scale projects, i’m not sure versionning the anim is indispensable (well only geocached versions of it for the lighting/shading dept).

Oh ok, i gotcha now.
I think perhaps I wouldnt really be able to make any decent suggestions unless i was familiar with the pipeline, as they can really vary, which I suppose is the whole point of TD’s to establish one thats right for the company and projects.

As for writing your own data format for constraints etc, I think its quite do-able if kept simple and do what it needs to do, which is simply recording the constraint’s connections and values, and then applying them to a newly established constraint upon having the right assets loaded, nothing fancy or complicated really needed.

For versioning the scene, that could work quite well, as long as space and corruption (mainly the issue with maya’s ascii writer) aren’t much of an issue, it would save time.
Unfortunately we kinda had those issues here so exporting the animation into a compressed custom format was a better solution for us.

Lee Dunham | Character TD
ldunham.blogspot.com

ah cool, and I know what you mean.
I recently done some integration with shotgun for our pipeline, nothing complicated, just to save out co-ord some time.
We intended to use alot of automation with it actually, but just not enough time. From the glimpse or two i’ve had, it seems to be very useful with alot of potential, so im looking forward to doing some more with it. I have been meaning to try alembic, and after seeing what houdini pulled off from following its development, it definitely seems to be the way to go, I guess I need to make some time to have a look.

Lee Dunham | Character TD
ldunham.blogspot.com