Looks like others have replied, but yeah, the toolkit works in Z up, which is just a standard we use here on our projects, and of course, in the engine
As far as the reference path, that’s super annoying. Maya stores hard paths for references which means anytime you share files with others, if they don’t have the same directory structure, they’ll need to browse/replace the reference.
I’ve learned my lesson here, and V2 will not have the animation rig referencing in the export file anymore, so that will help with that!
If you’re in maya 2014 or later, something has changed with the UI code and the windows no longer build to the right size, so certain elements look clipped off, but you should be able to resize the window to access them. (I get around this in v2 by just not using Maya’s UI commands).
(to access that page, you just need to link your UE4 and github accounts https:///ue4-on-github)
However, nothing binary can be uploaded to github, so the joint mover file and icons are not up there, but those don’t change often at all.
Unfortunately, with the release cadence slowing down, using the versions that ship out with the releases usually means that they get behind rather quick. Dropbox was a temporary solution until we got the live github mirroring working, which it does now.
As for the skin_geo thing, do you have some repro steps for that? I tried everything I could think of to try to reproduce the error, but I wasn’t able to get it. If you have any steps to get to that error, that would be super helpful.
That’s very strange. I don’t think I’ve ever seen or heard of that one before. If you ever get a solid repro, let me know and I’ll try to at least work in a better dialog with some more information!
Glad you got it working again though! Sorry for the trouble.
Can you elaborate or show some screenshots of what you mean with the fbx export file issue? When you refer to animation being applied, do you mean the character rig now has animation?
For the other issue, are they opening the rig file instead of using the ‘add character for animation’ option? If so, that means the rig will not have a namespace, and the UI will not work. If that is the problem, you can easily salvage animation and transfer it via ATOM in Maya.
When you talk about reimporting the keys, are you referring to Unreal? What’s your process for getting the joints exported? You mention baking, so I’m not sure if you’re using the Export Motion tool or not.
Chains definitely don’t need to be children of the root. We have characters on Paragon with tons and tons of chains and leaf joints everywhere.
Are you trying to import an FBX as mocap using the Import Motion tool? If that’s the case, then I think I added a change some time ago where importing mocap on chains and leaf joints required the user to select those controls before importing, as it was requested from our animators here.
haha, Evans is working on it. We had some GDC projects come up that pushed that effort back, but I can see if he can write up a quick primer. It’s definitely not ‘user friendly’ right now.
Hey there!
Do you have any screenshots or additional information? There are a few reasons this could happen. The matching is not 100% perfect, though it should usually be pretty **** close. The tricky part is matching foot roll to FK toe controls.
This can happen if your rig pose is not ideal for IK. That’s usually the easiest way to get issues, as right from the start, your IK chain will have done something to compensate to solve right, which now puts it off the FK chain. If you have any more info, or screenshots to help narrow this down for me, I should be able to help you better.
This was most likely the case for our legs. Looking at the default rig it seems the issue occurs there too when switching the hands between FK/IK.
Are there any rules as to how far I can move bones around in the placement stage? It looks like this may be causing us to have some issues with what we are seeing in editor vs what we see in maya.
I’m a student also and have ran into a few problems with what I assume is the student version popups interfering with the toolset. (Maya 2016 SP5 student, epic tools from ue4 4.10 and have tried the dropbox version)
One problem is saving, it sometimes will not work because the student popups get in the way of however maya saves the scene after using the toolset.
eg. after creating a default character then importing mocap data or just animating it, it saves beforehand fine but after using it to animate refuses to save with just the simple error:
file -f -save -options “v=0;”;
// Error: line 0: Could not save file
We do have a custom save script to avoid the error but autosave is sometimes a lifeline for us that are forgetful.
Would really help us out if anyone knows of a fix which is available.
Thank you so much for your time and reply, you are a guy with a lot of people asking so I truly do appreciate it.
With re-import I was referring to bring the animation back into Maya. I made use of the art export motion tool and the import motion.
I took this issue down to a basics to try and isolate.
Using art tool I created skel with single custom chain. I opened this skel for animation. Keyed some frames to move leg and custom chain. I used Maya to key every frame for the custom chain. Export using art. opened a new file. Import using art. Leg moves but custom chain does not.
I am very new to Maya and Unreal, Blend Head in the past. I very much suspect this relates to one of the following a failure to clearing history, proper selection of hierarchy prior to export. or a limit within Maya in regards to FBX.
I have been doing some more reading and testing (sections prior to export) in the hopes of solving without using more of your time. I will post if I get it.
Actually Y-up is more likely prominent in film/vfx/commercial work because screen space is what is important. What you see on screen and where it is in the frame takes priority over layout of a 3d environment which games and architecture prioritize. There are a lot more of us Y-uppers getting into game engines with all the VR stuff coming down that pipe, that I’d find it extremely useful to make it easier to support a Y-up workflow. Just as I’m sure Epic maintains Z-up for their pipeline, it’s no small task to flip the y/z switch in film/vfx/commercial pipelines.
We do some pretty crazy stuff wit ART on the Paragon characters and haven’t run into issues, but I think there are some assumptions made, like the foot will be below the knee, and not behind the pelvis.
This is one of the ART skeletons for a Paragon hero:
In that example, you could run into issues if that foot joint was angled back further than the hips, the build would probably make the IK behave strangely.
Other than making sure child joints in a limb don’t go past their parent, I can’t really think of too many other rules. On the default rig IK/FK switch, if you switch while in Tpose, it will start acting up, because it will sometimes match, but put a -180 on a control (usually the FK), and then when the IK goes to match that, the elbow is now inside the arm instead of on the outside. When switching between FK/IK in tpose, it’s best to not use match, and just switch it via rig settings.
yeah, I’ve heard of this issue. The rough thing is, I don’t have an edu version to test on to figure out what is going on. I know the edu versions spam popups like crazy reminding you that you’re using a student version.
And that error! So useful Autodesk! haha.
Would be super great if they could say why it can’t save!
So, just so I can clarify for myself, even if you do not import mocap, you set some keys, and then try to save, it fails?
The mocap import I could at least see where that would be causing the issue, in that I’m probably forcing FBX to import without prompts which may be messing it up for edu versions, but just normal animating seems really weird.
Anyone else have this issue with student versions? I’d really love to solve it, as I’m sure it’s a quick fix, I just don’t have a student version to test on!
Thanks very much for the reply though I’m not sure what you mean by ‘behind’. It looks like the foot is in fact behind the pelvis in the default rig and, likewise, the hand is in front of the shoulder.
Is there a way to send you screen shots directly instead of in a post?
I went ahead and made a video today going over what we have so far:
There are still some bugs, and some UI elements that don’t work as expected, but you can get a finished face rig out of it!
Eventually, it will auto-project the weighting from the mask onto the mesh to get you a good start on the skinning.
We’re hoping to finish the thing off in the next month or so. And then we’ll port it to v2.
Ah! So, anything that is not a standard part of the body (any leaf modules, chains, etc) will not import motion by default.
To import motion on those controls, you need to select those controls first (or just select all controls in the anim UI), launch the import tool, then import (make sure your controls are all still selected before hitting import!)
That will bring in data on modules. This was requested by our animators, because sometimes the mocap data for the non-standard bones is bad, or they don’t want to use it.
