HumanIK not compatible with ATOM? (2013)

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Display Modes
  04 April 2013
HumanIK not compatible with ATOM? (2013)

I've been using HumanIK on an experimental character recently. Overall I'm pretty happy with it, but today I realized that it's apparently not compatible with Autodesk's ATOM (Animation Transfer Object Model) format. Or I'm overlooking something entirely.

For example, I import a character from the HumanIK examples, then set a few keys. I select all the IK controllers, and go to Animation -> ATOM -> Create ATOM Template. Then I use ATOM -> Export Animation, which writes out an .atom file which appears to be based on the template. Then I delete the keyframes and attempt to import the animation based on the ATOM template and the .atom file. Basically, doing exactly what is performed in this video. When I skip the template part, and just export "Hierarchy: Selected", the progress window appears to export something, but...

It doesn't work, at all.

It works fine with a traditional, manually rigged character with various curve-based controllers, but not with a HumanIK rig. I want to know if this is a known issue and if there's a workaround. Maybe somebody with 2014 Beta access can give it a try. I haven't found anything mentioning this apparent incompatibility in the documentation. I have been playing around with the .anim format also, with limited success.

If anyone has a couple minutes, please try using HumanIK in combination with the ATOM workflow. If you know a workaround, it would be much appreciated.
  04 April 2013
Atom looks to be an internal feature for animation transfer within maya. It has nothing to do with the fbx file, it is if I'm not mistaken an xlm like file format

But theroretically you should be able to map your controller shapes to their humanik siblings so it gets recognized as a "custom rig" in maya's humanik. (Custom rig' not the generic rig) I haven't bothered with atom so it might be wishfull thinking, but the atom thing should work that way. And the data should transfer back to motionbuilder if it is on a valid custom/generic humanik rig. Maybe the animation must also be baked onto your skeleton to work before sending over.

Than again, I find that doing all your character animation within Motionbuilder, and than sending it back to maya and use it as your motion input is often times more convenient.

Layering, blending animation in motionbuilder and using the powerfull pose editor is so nice and fast. You can even get decent secondary and facial animation within motionbuilder. If motionbuilder would be able to export to alembic, studios would probably bypass Maya alltogether.
"Any intelligent fool can make things bigger, more complex & more violent..." Einstein
  04 April 2013
My understanding is that ATOM is a file format used for saving and transfering animation curves and static values to other files with matching rigs. The documentation states it's similar to the .anim format, but a bit more robust. I imagine it's compatible with Motionbuilder, but we don't have a license for that at this time. It's on the wishlist.

Your workaround involving the custom might work though, even though that would be a big pain in the neck. Hopefully it just works like it's supposed to in version 2014.
  04 April 2013
Have you tried plotting to skeleton. ATOM the skeleton data. Remove skeleton keys. Import Atom back to skeleton, then you have option to plot back to control rig.

Just out of curiosity, why do you need Atom?
  04 April 2013
No, I haven't tried that either. Do you mean baking my control rig animation to the skeleton, export to ATOM? I think that could work, but it could be hairy getting that animation back to the control rig from the skeleton when I import it.

I'm trying to use ATOM because I'm not an experienced character animator and want to learn more about common workflows. I've tried using clips and trax editor in the past, but my success was pretty limited. Frankly I found clips to be a pain in the ass for the most part. After watching the marketing info from Autodesk, ATOM looks pretty cool.

I am looking for the proper way to take all the animation of a character and export it to a library where I can reuse various sequences, convert them to clips and put together sequences with the trax editor if I want, or something to that effect.
  04 April 2013
the whole point of control rig is that you can plot between rig and skeleton.
Its like a bake I guess but its a specific option from the control rig drop down menu.
So like in motion builder you can import your motion on the skeleton, then because its characterised, you can plot to control rig.
I tend to do this in mobu, but I think it works the same in Maya.
  04 April 2013
the best tool for Nle clip blending is Story mode in motion builder. You simply drag your clips in there and its so easy. You can plot your new blends to a new take.
Trax tries to do it, you can get good results but it's a long way off Story mode.
Sounds like you need to finalize your anims as fbx on skeleton then you can drag and drop them into Story.
This would be my recommendation.
Get the mobu 30 day trial, try it out.
  04 April 2013
I don't see any mention of the word 'plot' in the blue HumanIK dropdown menu. Is that the menu you're referring to? I searched the documentation for 'plot' and didn't find many results except that it's supposedly the same as baking. I'm on Maya 2013.5. Maybe it's a Motionbuilder-only feature.

One issue I have with baking is that it bakes even the empty keyframes as opposed to transferring the existing keyframes. It sounds like what you're describing avoids that issue.

So are you just exporting keyframed skeletons for your animation library? Then you import them and use the existing character's HumanIK to source from the imported skeleton? Thanks a lot for your insight so far, it's very much appreciated.
  04 April 2013
yep apologies, in Maya you do the blue drop down and 'bake' to skeleton. Then the control rig should be switched off. Here you can also bake the skeleton back to the control rig.
So in theory, you bring in your Atom anim on skeleton, then you could bake to control rig.
In motion builder its 'plot'.

Do the baking from that menu so it bakes the correct bits.
Im in hospital so not at my machine :(

I'm used to mocap, so its generally keys everyframe. So I tend to bake/plot the final anims out as clips in fbx.
  04 April 2013
Your bake-to-skeleton tip looks like it will work as long as my animation is completely final. I'm reluctant to do this with hand animation though, so may reserve this technique for mocap only. I'm still hoping it works like I expect in '14 or else I'll have to try using custom controllers with HumanIK. I'll post back if that helps. In the meantime, I'll start begging for Motionbuilder. Sounds like the right tool for the job. I hate the trax editor so much.

Thanks again. Hope you start feeling better.

  04 April 2013
no worries, yeah if your handkeying then you want to keep reduced keys I totally understand.
When you tried the Control Rig to Atom, you exported selected controls. Maybe try selecting the top node (look in the hypergraph) and export heirarchy below so you get everything. Im pretty sure it must be possible. I'll take a look when im out.
Good luck.
  04 April 2013
Okay so I still haven't had much luck with a custom HiK control rig, but I'm going to keep trying. The seriously irritating thing right now is that I can't even transfer a simple animation from one character to an exact version of that same character.

I've got some hand animation from an older file. I reference it to my current scene, and use the "Source" dropdown to assign the old animation. That works fine. But when I go to bake it to the new control rig, Smart Bake doesn't bake all the frames. If I use "Sample by: 1", then it works, but it bakes every single frame, as opposed to just transferring the individual keys.

How can I transfer hand keyed animation from one HiK rig to another without baking every single frame?
  04 April 2013
I think the idea with HIK workflow is you don't worry about the hand key stuff. It takes some getting used to when you have been doing hand keying, like I have for so long. But once you take advantage of the entire workflow, it all starts to make sense. Basically, once you hand key it all and you are more or less happy, you can send it over to the new character if that is what you need to do. From there just animate in additive layers if you want to make changes or override if you want to do something that overwrites it.

And I don't think story helps that much for this. At least I have not had much luck doing it that way. I think the workflow that is better for additive animation is layers. Now I have not done any of this in Maya. I work primarily in MotionBuilder. But I think the layer system is about the same.

Now having said that, you still should be able to have the character driven by another character in the scene by choosing that character in the source drop down of the target character.

At that point for all intents and purposes the animation is "transferred". You can hand key animate the original all you wan and it will move the target. Once you have what you want then plot "bake" to the control rig or skeleton. From there further changes can be done with layers.

That is pretty much how I work it in Mobu.

Just a process of refining and baking on top of mocap data. But it works on hand key stuff as well.

Maybe that does not help, but thought I'd chime in.
Richard Culver
Protfolio Facebook WIP1 WIP2
  04 April 2013
Thanks for chiming in Richard, I need all the help I can get. I'm pretty inexperienced with character animation beyond a single take, and I'm trying to get the hang of the standard workflow. It seems like a mystery to me, especially without MotionBuilder. I can't imagine building up a complex scene with various clips blending together. What you and jonmummery said about baking data and making refinements with animation layers is starting to sink in. I can still save my hand keyed animation files separately while I get more used to animation layers.

I can fix some issues on my character's upper body animation using additive animation layer, but I get left with a lot of harsh 180 joint rotation popping that is very difficult to resolve with additive layers. I've tried using the Euler filter with no luck. When I use Override, the damn joint snaps back to translate 0, 0, 0. My only 'solution' right now is to delete the keys and try to rekey it by hand, but that's tricky too. Maybe my mocap data just isn't clean enough. I'm using free BVH files from Cambridge to experiment with.

What's also killing me is foot sliding. Maybe I need to correct that better using the HumanIK IK Blend sliders before I bake it? They don't seem to do much of anything for me. I don't understand how I'm supposed to pin a foot controller to the ground if it's baked for 20 frames. Overriding is the same deal... the controller just snaps back to 0,0,0 in translate. Autodesk marketing videos sure do a good job of make it look simple.

I also can't seem to define a functioning 'Custom Rig'. I assumed I could place some custom curves near my joins, assign them to the corresponding 'affector slots' in the HiK panel, and my custom curve would drive the skeleton in an HumanIK manner. No, my curves are completely ignored for some reason. I must be misunderstanding the purpose of the Custom Rig panel. I'm guessing these curves need to be part of an actual, manually created full character rig, in which case they wouldn't be interpreted as full-body IK unless they were rigged as such, which would make me ask what the hell HiK is even for?

Here's an example of the animation curve popping I'm talking about. I'm sure any insight anyone can provide would prove useful.
Attached Images
File Type: png curvepop.png (5.9 KB, 4 views)
  04 April 2013
OK, I think I can understand what you are going through. There is a lot of information you have covered there. So lets break it down to simple to understand compartments.

First Control Rigs and Custom Rigs.

The entire HIK system is based on a control rig. The only way to modify this rig is to add Auxiliary Effectors and so on. It is basically a set thing. You don't customize it internally.

What you are doing when you characterize a skelleton, is you are just telling the HIK system which bones will be driven by the control rig. Same as when you define the skeleton.

Based on my theoretical understanding. I have not used this yet -A custom rig is one that you create with other controls already created for animation above the basic deforming bones. In other words, you already have a control rig you have built and use for other purposes in your pipeline. And you don't want to tear this apart. You just want to have the HIK system take over, lets say to retarget animation to this rig.

Quote: Custom rigs are typically driven by some combination of ikHandles, constraints and other miscellaneous nodes. The Custom Rig tab provides a visual interface for mapping your custom rig, and retargeting tools to transfer data from other HumanIK defined characters.

So rather than assigning the controls to bones, you are assigning the HIK controls you the controls you already have set up. That is the main difference.

That is why the definition panel looks like this:

And the Cutom rig definition panel looks like this:

Notice the similarity to the Controls tab:

Maybe this makes more sense now.

Now mocap source data:

I think you mean the CMU database correct?

Make sure you are using the MotionBuilder files:

And second use the later examples from the trials. The early experiments are of lesser quality.

And finally,I seem to remember there is a filter you can apply to fix those bad rotations. But now it escapes me. Otherwise, the best thing to do is first go in and simply clean up the channels by hand in the graph editor. I don't think you want to try and do that with the animation tools. Give yourself a good clean data file to start with. Then on top of that clean data make your tweaks and changes with layers.

Foot sliding can be just bad mocap data. And you can use an override on that if you want, but I think it is simply better to do it by hand in the graph editor.

In general that mocap database can be very strange to work with. It is not the best quality. So you may find yourself having to do a lot of tweaking and clean up.

I find some of the joint rotations to very strange, usually in the neck and head area. And for this it seems layers can help to compensate. But for limb flipping and rotation it is best to just clean it up.

Then Story and Trax, mixing animation in general is a way to simply join different clips together, and I have found it is best used just for that. Then use the Layers to do non destructive clipping on top of Story edits that I have plotted back to the control rig.

Now the idea is, assuming you have clean mocap data to start, you simply use that control rig and layers to refine and make changes. It is just another way to work other than hand keyframing.

Not saying it is better. But it is another workflow. And it is best to understand how to use it the way it is designed to be used. It does have many advantages.
Richard Culver
Protfolio Facebook WIP1 WIP2
Thread Closed share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 04:11 AM.

Powered by vBulletin
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.