Animation and Rigging Tools: FAQ, Known Issues and Feature Roadmap

ernstAlert · December 11, 2014, 1:12am

yeah! absolutely! It’s so awesome that you can export from Mixamo to the UE4 skeleton now! If you just use the default mannequin configuration in ART, it’s the same skeleton as the UE4 one

ernstAlert · December 11, 2014, 1:24am

Drixil;190770:

So after a long battle with our art director (I haven’t touched an autodesk product since 3d max 9) he said that ART is awesome and we should use it because, well rigify isn’t really all there. Due to autodesk products being ridiculously priced and I can do most of the same stuff in blender I got a trail of maya to just use the animation rigging tools… mainly because spending a ton of time doing rigging and skeletal meshes when you have 30 npc’s slows dev time. I was quite annoyed to start with but nvida also has apex/physx tools for maya so i thought maybe it would be worth it (honestly I bet you more people who subscribe to UE4 use blender over a legit copy of Maya or 3d max)… I began a journey of epic failure. Yes maya installed fine… All was good, I followed the destructions on the unreal docs page to the letter… Fired up Maya (I think I might have vomited a little) and wallah the view port has some kind of over lap going on… IT just keeps going back and forth between one view port and or the animation viewport… I have an idea… why don’t you just put the animation rigging tools into the tool set… or port it to blender… I know most corporate programmers think that open source means free and a huge community of programmers but that is often not the case…

Okay, you’ve got a lot of stuff crammed in that paragraph, so I’ll try to answer the relevant stuff.
As for your issue, my guess is, it might be that you have a userSetup.py file in both documents/maya/scripts and in documents/maya/maya_20??/scripts. If so, remove the one in the maya version specific scripts folder. If it’s not that, it must be a vid card issue, which unfortunately I can’t do much for you there.

As for your other issues, I find myself reminding people this every so often, and it’s understandable as the tools come with UE4, but the tools are created and maintained for our animators at work. We release them to the community, because, why not! Maybe some will find them useful. Writing them for Blender though does nothing to help our animators and ship our games, quite truthfully. I’m know it’s a fantastic piece of software, and it being free and open source is great, but we’ve got an established pipeline that we’re not planning on upending any time soon If I had all the free time in the world, I would love nothing more than to try and find ways to port the tools over to Blender. It would be a fun challenge, but also a ton of work, so it won’t happen on my end any time soon unfortunately.

Let me know if the userSetup.py file solved your issue though. Thanks!

anonymous_user_07a5ccfe · December 11, 2014, 8:37am

Thanks for the quick response a few notes added alongside a few other things we spotted.

1.) For the FK/IK switch issue, are you doing this while in the T-Pose? If so, I’ve seen the 180 flip happen. If it’s in a normal pose though, it should work fine.
Works fine if not in T pose issue will occur on arms, legs & spine if in T pose. 

Would be desirable from an animators POV to have the offset between the pole vector and arm maintained rather than snap to the elbow, mainly so that the control is easily visible (not hidden inside the arm mesh) and also to maintain a clean visual ark/position between states.
Something else we noticed is if an arm for example is in FK mode, if the animator uses “Match FK rig to current IK pose” it causes the pose/wrist to partially match breaking the pose, also occurs if in IK mode and pressing “Match IK rig to current FK pose”. Its completely avoided if we always press the correct button which begs the question should the alternative option be greyed out? e.g grey out “Match FK rig to current IK pose” if the current frame is already in FK mode. Can cause some pretty horrible counter workflow issues if auto match is active.
Lastly can a control be added which specifically controls whether or not the arms and legs are keyed as FK/IK? There’s an attribute under rig settings however it makes the workflow a little slower if we want to copy/paste a pose to a different frame whilst also copying across the modes current state.
All of the above have workarounds, just some friendly suggestions 

2.) Not sure if I’v ever tested using the aim mode after having the T-Pose being auto-created. That certainly wasn’t the intent anyway. If you were to turn off aim mode before hitting ‘save pose’, it should work i’d imagine. I think the issue right now is that save pose probably isn’t checking for aim mode, and thus doesn’t know to run that function to clean it up.

It’s rare that we want to adjust the T pose however if it is required using the aim feature seemed to be the cleanest and easiest method to re position the controllers e.g. legs with minimal counter movement.

3.) This makes sense. There is a part of the code that figures out what the scale factor should be when building the rig, so that the controls are appropriately sized for the character. This assumption is done in cm, because UE4 operates in cm. I believe a scale factor of 1 in the code is something like 180cm.

Changed default to cm which resolved all of those issues. Worth noting if you have a setting to auto set scenes to a different unit scale when creating new, during AnimRig generation the IK controls will be in undesirable locations due to the new scene reverting back to a different unit scale, changing the units during the initial setup isn’t enough.

4.) yep, have no idea how to even fix that, if it’s even fixable. Maya cmds module gives no control on tab order. The new version being done in QT does.

No big deal 

5.) I usually use the post-script section for this very thing. When publishing the character, you can slot in a post script that will scale all of your controls. If you’re not script savvy, simply copying the MEL output from the script editor and saving that out should work fine.

Thanks I had a feeling this would be the case. I’ll have a word with our TA. Do you have any useful premade post process scripts that can be bundled with ART?

6.) I did that intentionally, unless I’m not understanding the issue. It should still create the proxy geo, but it will be weighted to the hand.

Main reason was because our test character only had three fingers so the fourth pinky was always redundant, plus the proportions of the character were quite extreme so it stood out like a sore pinky.

I downloaded the latest dropbox version however I still get the same crash if files/projects is set to OS native with hide extensions on, no big deal as long as it’s off. Also is that link correct/up-to-date as it differs from the link on the first post?

Few new bits 

Inconsistency between FK/IK mode between rig and rig settings:
Rig settings, interface doesn’t update when switching between FK/IK modes e.g switch legs to FK not using rig settings then open the rig setting tab afterwards it will still be set to IK.

Pose mirroring:
Arms and legs will mirror opposite however it doesn’t currently work with central controls such as hips, spine, neck, and head. Could this be supported as it would be hugely beneficial being able mirror/flip and entire pose e.g walk cycle stride.

Clavicle rotation:
Clavicle/Shoulder controls can be rotated however channel controls for rotation are hidden which makes it difficult to reset the controls position even if using set all to zero. Assume these can be re added through channel editor, just wondered if rotation could be locked if it’s not required.

Add/remove sequence button:
There’s an add sequence button within motion export however there’s no remove sequence button if amendments are required.

FBX motion export:
Using the Epic “ART” exporter has been failing to complete when attempting to save FBX files in the 2014 format at the end of the baking process.

By making a change in “ART_exportMotion.py” at line 766 & 849 with the code below, the process can now complete the FBX write process in 2014 and 2013 FBX file formats. The first line is the original code commented out, the lower line is the new command.

                #cmds.file(fileName, es = True, force = True, prompt = False, type = "FBX export")
                mel.eval('FBXExport -f "' + fileName + '" -s;')

Thanks,

Lead Animator
UK based studio

AntonioE · December 12, 2014, 7:58pm

Hi. I’m animating a character and I have a weapon referenced in the scene. I’m trying to export the weapon’s animation with the ART tool, but when I open the “Export Motion” window I get this error:

Error: WindowsError: file C:/Users/MyName/Desktop/MyName/MyGame/maya_project/MayaTools/General/Scripts\ART_exportMotion.py line 1048: 123

and the weapon doesn’t show up in the drop down menu (where it says “no weapon”) althought it does have a namespace (which I understand the tool needs?).
If I remove the reference, the error goes away.
How can I make it work? Thank you.

ernstAlert · December 13, 2014, 2:20am

Davrok;191029:

Thanks for the quick response a few notes added alongside a few other things we spotted.

1.) For the FK/IK switch issue, are you doing this while in the T-Pose? If so, I’ve seen the 180 flip happen. If it’s in a normal pose though, it should work fine.
Works fine if not in T pose issue will occur on arms, legs & spine if in T pose. 

Would be desirable from an animators POV to have the offset between the pole vector and arm maintained rather than snap to the elbow, mainly so that the control is easily visible (not hidden inside the arm mesh) and also to maintain a clean visual ark/position between states.
Something else we noticed is if an arm for example is in FK mode, if the animator uses “Match FK rig to current IK pose” it causes the pose/wrist to partially match breaking the pose, also occurs if in IK mode and pressing “Match IK rig to current FK pose”. Its completely avoided if we always press the correct button which begs the question should the alternative option be greyed out? e.g grey out “Match FK rig to current IK pose” if the current frame is already in FK mode. Can cause some pretty horrible counter workflow issues if auto match is active.
Lastly can a control be added which specifically controls whether or not the arms and legs are keyed as FK/IK? There’s an attribute under rig settings however it makes the workflow a little slower if we want to copy/paste a pose to a different frame whilst also copying across the modes current state.
All of the above have workarounds, just some friendly suggestions 

2.) Not sure if I’v ever tested using the aim mode after having the T-Pose being auto-created. That certainly wasn’t the intent anyway. If you were to turn off aim mode before hitting ‘save pose’, it should work i’d imagine. I think the issue right now is that save pose probably isn’t checking for aim mode, and thus doesn’t know to run that function to clean it up.

It’s rare that we want to adjust the T pose however if it is required using the aim feature seemed to be the cleanest and easiest method to re position the controllers e.g. legs with minimal counter movement.

3.) This makes sense. There is a part of the code that figures out what the scale factor should be when building the rig, so that the controls are appropriately sized for the character. This assumption is done in cm, because UE4 operates in cm. I believe a scale factor of 1 in the code is something like 180cm.

Changed default to cm which resolved all of those issues. Worth noting if you have a setting to auto set scenes to a different unit scale when creating new, during AnimRig generation the IK controls will be in undesirable locations due to the new scene reverting back to a different unit scale, changing the units during the initial setup isn’t enough.

4.) yep, have no idea how to even fix that, if it’s even fixable. Maya cmds module gives no control on tab order. The new version being done in QT does.

No big deal 

5.) I usually use the post-script section for this very thing. When publishing the character, you can slot in a post script that will scale all of your controls. If you’re not script savvy, simply copying the MEL output from the script editor and saving that out should work fine.

Thanks I had a feeling this would be the case. I’ll have a word with our TA. Do you have any useful premade post process scripts that can be bundled with ART?

6.) I did that intentionally, unless I’m not understanding the issue. It should still create the proxy geo, but it will be weighted to the hand.

Main reason was because our test character only had three fingers so the fourth pinky was always redundant, plus the proportions of the character were quite extreme so it stood out like a sore pinky.

I downloaded the latest dropbox version however I still get the same crash if files/projects is set to OS native with hide extensions on, no big deal as long as it’s off. Also is that link correct/up-to-date as it differs from the link on the first post?

Few new bits 

Inconsistency between FK/IK mode between rig and rig settings:
Rig settings, interface doesn’t update when switching between FK/IK modes e.g switch legs to FK not using rig settings then open the rig setting tab afterwards it will still be set to IK.

Pose mirroring:
Arms and legs will mirror opposite however it doesn’t currently work with central controls such as hips, spine, neck, and head. Could this be supported as it would be hugely beneficial being able mirror/flip and entire pose e.g walk cycle stride.

Clavicle rotation:
Clavicle/Shoulder controls can be rotated however channel controls for rotation are hidden which makes it difficult to reset the controls position even if using set all to zero. Assume these can be re added through channel editor, just wondered if rotation could be locked if it’s not required.

Add/remove sequence button:
There’s an add sequence button within motion export however there’s no remove sequence button if amendments are required.

FBX motion export:
Using the Epic “ART” exporter has been failing to complete when attempting to save FBX files in the 2014 format at the end of the baking process.

By making a change in “ART_exportMotion.py” at line 766 & 849 with the code below, the process can now complete the FBX write process in 2014 and 2013 FBX file formats. The first line is the original code commented out, the lower line is the new command.
                #cmds.file(fileName, es = True, force = True, prompt = False, type = "FBX export")
                mel.eval('FBXExport -f "' + fileName + '" -s;')
Thanks,

Lead Animator
UK based studio

Dat Wall of Text! Pretty intimidating haha.

1.) Everything you said here is correct and great suggestions. The only real tough one is the elbow vector maintaining the offset, yet still matching. I’ve known about the pressing the wrong button bug for ages, just haven’t gotten around to fixing it (sorry!). For the version of tools currently out, this stuff likely won’t get addressed only because I’d rather spend that time adding these suggestions to the version I’m currently working on (modular version). The two versions will be compatible with each other though!

2.) I’ve got some pretty big plans for the rig pose in the new version. It was a really last minute implementation in the current version and it’s just not that great. In the new one, each module will have what it knows to be the “ideal” rig pose. There will be an interface that lists each module and has a slider. the zero position of the slider is the model pose. The end position is the ideal rig pose. If you make any manual edits to the character, that becomes that control’s new rig pose. Each major joint of a module will also have a slider so you can easily create your rig pose. Reset options for each module will be available too, so you can get back to the module’s ideal pose. (This would work better with an image haha). This will actually be started pretty soon. Also, the other big change is that you don’t create the rig pose until the end, right before you go to publish the character and build the rig. This way, you’re creating the rig pose on a deformable model

5.) I will take a look! Let me know what sorts of things you may be looking for, and I’ll post some examples. Most of them are very specific to the character on the project.

6.) Oh! I was misunderstanding that one. Ok, I just tested and confirmed. This is indeed a bug. I’ll see what I can do about getting a fix in next week.

Inconsistency between FK/IK mode between rig and rig settings:
Ok, so this is if you set using the channel box? I think there isn’t anything watching to see if the attribute changes on that node. With using the UI buttons, it will trigger an update.

Pose mirroring:
Have you tried the mirror ghost pose option?

Clavicle rotation:
Is this with the clavs in IK mode? If so, whoops!

Add/remove sequence button:
Right click on the sequence and you should get an option to remove. sorry, it’s hidden.

FBX motion export:
Interesting. We use 2014 here and have not run into that. No idea. I’ll give it a look!

ernstAlert · December 13, 2014, 2:28am

Heya!

I did some tests and found the issue! Save your weapon/prop in a folder in your project folder. For example if your project location is:
MayaTools\General\ART\Projects\MyProject

Make a folder in there called Weapons, like so:
MayaTools\General\ART\Projects\MyProject\Weapons\

Now reference that in and it will show up in the drop down.

Indrid_Fhtgan · December 14, 2014, 7:41pm

That worked a treat, thanks very much!

I did forget to update the rig file so for a second it looked like it’d been stretched on a rack, but it’s fixed now thanks again.

Vaei · December 14, 2014, 10:22pm

Hi ,

Noticed something the other day while animating, I switched stretchy legs on for a moment while he was in a pose and the entire leg stretched while maintaining the rotation, shouldn’t the leg only stretch outward when straight?

This is caused by the incorrect joint being used to calculate the end point of the stretching distance locator / node.

Probably you have it set to the IK ankle joint, when it should be the reverse lock ankle joint (or node, depending on how you’ve set it up).

Cheers

AntonioE · December 15, 2014, 2:53pm

Thanks! now it shows up in the drop down menu. However, when I try to export, the character’s animation exports fine but for the weapon I’m getting this error:

Error: TypeError: file C:/Users/MyName/Desktop/MyFolder/MyProject/maya_project/MayaTools/General/Scripts\ART_exportMotion.py line 793: ‘NoneType’ object is unsubscriptable

My weapon rig is just the geo and a joint that is parent constrained to a curve.
What could be the problem?

TheOneWolf · December 16, 2014, 9:35am

something in the userSetup is causing Maya 2014 & 2015 to constantly load and unload the scene every .5 to 1 sec. Alot of flickering going on in the viewport and the console is lit up with it showing what folders its reading.

anonymous_user_a8afb2ca · December 16, 2014, 7:46pm

Hi , I have been noticing that when I export the mannequin that I create using ART, it comes with neither ik_foot_root not ik_hand_root, is there a way to fix it or i’m exporting in some wrong way (I’ve been following your guide)

ernstAlert · December 17, 2014, 2:28am

I just put a fix in for this about a week or so ago. If you get the latest dropbox code and rebuild your rig, you should see a StretchBias attribute on the feet and hands that allows you to determine stretch behavior. Couldn’t outright change it due to tons of content already being done with it the old way here at the studio.

ernstAlert · December 17, 2014, 2:30am

Not sure. Can you turn on stack trace in the script editor and paste the new error you get? Or just attach your copy of ART_exportMotion.py. Line 793 is a blank line in the latest files, so I’m not sure what it’s actually trying to do

ernstAlert · December 17, 2014, 2:32am

You have a duplicate userSetup.py file in your documents/maya/maya2014/scripts and documents/maya/maya2015/scripts folders. Delete that file and you should be good to go!

ernstAlert · December 17, 2014, 2:36am

You’re all good! It’s something I actually add in the post-script of the character. If you’re interested in adding that as well, I’ve attached the post script. You just slot that in when you go to build
https://dl.dropboxusercontent.com/u/10939513/ikBonesPostScript.py

Mr_SquarePeg · December 17, 2014, 6:00am

Hey ,

Just curious will Modo be supported with the ART tools?

I just picked up MODO Indie and just thought I would ask

TheOneWolf · December 17, 2014, 7:11am

I found I had a third userSetup under Maya/scripts. Thats what was causing the issues. Thanks

AntonioE · December 17, 2014, 7:55pm

I turned stack trace on. This is what I got:

Error: ‘NoneType’ object is unsubscriptable

Traceback (most recent call last):

File “C:/Users/Antonio/Desktop/Antonio/ZombieCount/maya_project/MayaTools/General/Scripts\ART_exportMotion.py”, line 793, in exportFBX

parent = cmds.listRelatives(joint, parent = True)[0]

TypeError: ‘NoneType’ object is unsubscriptable

anonymous_user_a8afb2ca · December 17, 2014, 8:15pm

Sir…I tip my hat to you.

PS: Do you have any other interesting script to share?

Drixil · December 18, 2014, 2:17am

;190944:

Okay, you’ve got a lot of stuff crammed in that paragraph, so I’ll try to answer the relevant stuff.
As for your issue, my guess is, it might be that you have a userSetup.py file in both documents/maya/scripts and in documents/maya/maya_20??/scripts. If so, remove the one in the maya version specific scripts folder. If it’s not that, it must be a vid card issue, which unfortunately I can’t do much for you there.

As for your other issues, I find myself reminding people this every so often, and it’s understandable as the tools come with UE4, but the tools are created and maintained for our animators at work. We release them to the community, because, why not! Maybe some will find them useful. Writing them for Blender though does nothing to help our animators and ship our games, quite truthfully. I’m know it’s a fantastic piece of software, and it being free and open source is great, but we’ve got an established pipeline that we’re not planning on upending any time soon If I had all the free time in the world, I would love nothing more than to try and find ways to port the tools over to Blender. It would be a fun challenge, but also a ton of work, so it won’t happen on my end any time soon unfortunately.

Let me know if the userSetup.py file solved your issue though. Thanks!

Ya that was it… I put it in the wrong place…

As far as ART and blender it really doesn’t matter that much. If it becomes a issue and I feel I really need it I can always write one for our company for blender that is comparable. It is python after all… I think it would be cool if it was included in the engine itself… But that is just me…