It is quite literally a node of type unknown. It is the skeleton settings cache node. It needs to be converted to something like a network node. I have a python script here at work I use to hack around that. I’ll track it down.
Edit: Found it:
def convertSkelSettingsToNN():
orig = 'SkeletonSettings_Cache'
if cmds.objExists(orig):
if cmds.nodeType(orig) == 'unknown':
new = cmds.createNode('network')
for att in cmds.listAttr(orig):
if not cmds.attributeQuery(att, node=new, exists=1):
typ = cmds.attributeQuery(att, node=orig, at=1)
if typ == 'typed':
cmds.addAttr(new, longName=att, dt='string')
if cmds.getAttr(orig + '.' + att):
cmds.setAttr(new + '.' + att, cmds.getAttr(orig + '.' + att), type='string')
elif typ == 'enum':
cmds.addAttr(new, longName=att, at='enum', enumName=cmds.attributeQuery(att, node=orig, listEnum=1)[0])
convertSkelSettingsToNN()
So the export from the animation UI only exports animation. I never wrote a mesh exporter because I was the only one exporting meshes so I just did it manually by selecting the mesh and the geo I wanted and exporting selected (from the export file, not the rig file). V2.0 has a swanky fbx exporter for meshes and animations. soon!
Definitely sounds like a feature that rotted with time. I’ll look into that 60fps issue asap. What it was supposed to do was double your frame range and bake a key on every frame, then export at 60fps. We found internally that only exporting at 60fps while having your timeline set to 30 meant the engine was doing a lot of interpolation for the animation that wasn’t wanted. I’ll write myself a note to look into this. sorry about that.
The second issue just sounds like the rig needs to be rebuilt with the latest code. Sounds like you’re animating on a rig that’s probably 6+ months old, or at least from code that is that old. There were improvements made to matching that called for some changes and that’s where that error is coming from. Do you have access to the export file to be able to rebuild?
The 3rd issue is likely because the weapons aren’t in the project folder, which was something that came after the docs were written (really should update those!)
I made this video for another person on the forums that covered this (I was troubleshooting in the video, so pardon that): https://dl.dropboxusercontent.com/u/10939513/WeaponAnimExport.wmv
Also, thank you I’m glad it’s helping you out. Hopefully we can sort those issues out and have it work 100% for you!
So if I got that right the 60 FPS setting is not meant for animations that are animated with 60 FPS, but rather to export 30 FPS animations for a 60 FPS game. Since I already have Maya set to 60 FPS I don’t need to double the frame range before exporting, so I’m using it a bit differently. Maybe I should just set Maya to 30 FPS and double the playback speed in Maya and UE4?
As for the second, more important issue: Rebuilding the skeleton worked! I didn’t even have to rebuild the rig file - simply going back to skeleton placement in the export file already did the trick. I should probably rebuild the control rig either way just to get everything up to date, but that’s going to reset the changes I made to the rig and in turn mess with my animations. I guess for situations like this it would be good practice to keep track of all changes I make so I can replicate them easily.
Placing the weapon file in the project folder solved that problem as well, but for some reason it doesn’t export any scaling in the animations. There are keys on scale in the exported FBX, but they’re all at 0. Exporting the weapon animation manually keeps the scaling intact, so I guess it’s not because of my FBX exporter settings.
Thanks again for your support , it’s much appreciated.
I’ve ported the ART Toolkit over to OS X. If there’s interest in this, I would like to know, if not, I’ll just keep it to myself. I need to get permission from and Unreal Engine about the possibility of releasing it via Github if there is interest. It’s not my property, and technically it comes within the paid software bundle so I don’t want to step on anyone’s toes by releasing it.
In addition to the port, I’ve been working on making the ART system agnostic so that it’s usable for either operating system in the future.
awesome! I never ported the current version just because it made more sense to make sure the new version was cross-platform and put time into that instead. I’ll have to check with legal here about the github stuff. I think if you only redistributed the scripts and nothing else, it would probably be ok, but let me get clarification.
It actually didn’t take much time, that took a few hours yesterday.
Is there an ETA on the new version? I still have stuff to do to get everything back to working order, and don’t really think it’s worth it if there’s a new version due out in a few weeks.
Also, is the newer version going to keep with your same method of parsing UI stuff into the self.uiElements dictionary, or are you going to use PySide/Qt?
yeah, it was basically just handling the paths and slashes, and the bmps needed converting to png. I think that was pretty much it. A few hours is a lot when you’re backlogged I appreciate you doing that though. Fired off an email to the appropriate people to see what they say about redist. If all you did was change how paths were handled and dealt with the bmps, I could probably just ingest it here for 4.7. Was there anything you did specifically that would make it no longer work on Windows?
ETA on new version:
-It won’t be a few weeks, but likely, a few months. I got sidetracked with GDC stuff at work, so I’ve had no time to work on it since December. It is using pyside for the interfaces.
There wasn’t much that was changed, a tiny bit with how everything gets built. However, formatting came over pretty horribly, resulting in me going through the scripts and fixing indentation everywhere. And then I changed stuff to work a little more “pythonically,” but it was preferential stuff. ie: instead of opening with f.open, f.readline, f.close, I substituted
with open(file, ‘r’) as f:
mayaToolsDir = f.readline()
And then I was working on creating static methods for different areas. Stuff here and there. And I don’t think I need to convert the bmps, they load fine into Maya. But I find I do need to do that, I can run an imagemagick conversion on the folder and then output them, shouldn’t take more than a minute.
And I don’t think there was anything that I did that would make it not work. I’ll obviously test it first.
My plan is now that I’ve got parts of it up and running to write a script that will just batch convert the things that I’ve found. I do find that I need to figure out a way to get clean indentation coming in(I can attach a screenshot later tonight when I get home of what I got when I opened it up initially) - Is there a way you can send me the original scripts? This is what it looks like when I open the files that I pulled out of the Windows version of UE4(looks like this on both Windows and OSX)
It’s hugely spaced and indentation is messed up - it gets really bad a bunch of for loops down - so I’ve been manually cleaning. Regex edits help, but only so much.
No need to send the files, . I figured out a solution which I’ll e-mail to you once I package up the scripts and send them to you. It has to do with how Wing exports python files with mixed indentation and spaces.
If I am interested in using the UE4 support for 2 joint IK feet with an ART created skeleton / rig - how is this done? I’m animating the legs in Maya using IK but this seems to always get baked during export. The IK feet seem like they are additional joints that would need to be manually added to the skeleton before export or maybe even added to the character after import into UE4. Can anyone point me in the right direction for handling this?
Well
I pretty much gave up on using this tool. it has not been updated for like ever and alot of issues are still there. it still crashes when used in maya 2015 when trying to build control rigs. and eventhough it was mentioned at the beginning of this thread, yet there is no instruction on how to install it on Mac OS.
now it’s time to look for another auto rig application
That’s because it doesn’t work with OS X currently. I’m building a port to OS X, if you’ll look just a few posts before yours, after which I will send it to and he can do whatever he needs necessary to verify it. One of the reasons it would be crashing is potentially due to deprecated flags by Autodesk, though I can’t be sure as I haven’t gotten there yet.
I’m still kind of new to the ART tools, so could you please let me know exactly WHERE it’s crashing, and what processes you’re doing, so I’ll know what to look out for when I’m testing on OS X? I’m running tests on 2014 and 2015.
First, this isn’t a technical question - I suspect this is maybe a grey area, but does Epic have any problem with using the ART tools for non-Unreal projects? We are a small company that mainly does character modelling and animation for games and we’re finding the ART tools to be immensely more useful than rigs we’ve used in the past, but not all of our clients are using Unreal. (At present we’re using Unreal mainly for visual prototyping.)
Second, this isn’t even a question, but we’d like to second (or third or fourth or whatever) the request for y-up support. I realize you’re insanely busy and I know you mentioned it’s pretty involved, so I may look into it myself…
Here’s a question for alexwidener: Does your version happen to address y-up? I’d hate to duplicate any work you’ve already done.
well, that sucks. The only thing I could say to try would be maybe delete prefs (after backing them up!) and let maya create default prefs to see if that fixes it. Sorry you’re running into that
I’m assuming the nodes that keep them in that space must be under the offset anim in the hierarchy. I just took a look and yep, that’s the issue (sorry!) Not sure how our animators haven’t called that out, though I don’t think they animate offset/master controls often for their cycles. If you move the head_sys_grp located under the ctrl_rig group(which is under the offset_anim), and reparent that group to the master, that should do the trick for ya.
thanks! #4 is a known issue. The sets command got moved under the top arrow button instead of the button designated originally for them (animation request). The others I’ll have to look into.
I’m glad it’s helping you out. Hopefully we can sort those issues out and have it work 100% for you!
