Home Website Youtube GitHub

FBX Export / Game Tools

Support
#1

k, I want to make sure that I have a vague idea of what I’m doing here.

So I need to export an mGear rig with animation to an FBX which will be imported into Unreal 4. Currently we’ve just been exporting the bind skeleton and the mesh. That seemed to be “working”, but upon closer inspection from our animation lead I had failed to note that the bind skeleton has custom mGear nodes which resulted in a shearing issue with scaling when exported to FBX.

So there’s the gameTools.py which looks to address this issue under the shifter folder, but it looks like it still needs some work, so I’m trying to fill in the blanks.

  • Duplicate the bind skeleton
  • Disconnect the Parent Inverse Matrix from the joints of the duplicate bind skeleton
  • Scale and parent constrain the duplicate bind skeleton to the source bind skeleton
  • Bake the animation to the copy of the bind skeleton. Now that think about it this shouldn’t be needed if the FBX Exporter is baking the animation to begin with.
  • Export the duplicate of the bind skeleton as an FBX
    Am I missing anything here?

Having looked at the code again I think I understand the process you’re doing now, maybe.

  • Export a “clean” version of the skeleton without the Parent Inverse Matrix connections
  • Importing or Referencing that clean version back into the scene
  • Scale and Parent constrain the clean skeleton to the source skeleton
  • Export the constrained clean skeleton as an FBX?

K, I take that back, I’m not sure of the process the code is trying to do.
Why save out a copy of the Parent Inverse Matrix connections? It seems simpler to dupe the bind skeleton and break Parent Inverse Matrix connections and constrain the whole thing back to the source skeleton. That way you can just remove dupe later without affect the rig or animation. What is the benefit of saving that data? Am I dirtying up the scene duping the bind skeleton or something?

Problems with baking keys to skeleton
#2

What I’ve been doing is skinning to a “in game skeleton” and either direct connecting or constraining that skeleton to the mGear skeleton. This way I can control the names of the output bones, bypass the mGear component division limits, and cut the tip joints off. Probably not the best way, just how I’ve been doing it.

#3

How are you going about rebuilding the game bind skeleton when you make rig changes? I’m going to assume you have post process script. Also why cut the joint tips off when you can exclude them from your export selection?

#4

Yes, I have a post build script that builds and attaches the in game skeleton to each character. I wasn’t aware you could exclude tip joints during export though. In any case, it’s just personal preference to not have to look at joints that aren’t weighted.

#5

Just to clarify. The only things that need to be exported via FBX for unreal is bind skeleton, skinning, and mesh, right?

If I understand this correctly, should you not be able to just delete all custom nodes? Ensuring the separate joint structure is checked of course.

#6

Hi @hoover900

You are correct the game tools are not finish. That tool/functions was design for a specific project last year.

If you just delete the rig, some matrix multiplication nodes are still attached to the joints. and this can cause some issue with shearing etc.

The tool, when is finish will handle this disconnection to keep everything clean.

The process is not exactly like that
The split and re-connect idea using references, was a client request. And looks like a common practice (I am not expert here) so is easy to split the part to export to FBX and the Maya Rig that doesn’t export
The other advantage or reason is that is possible to update the asset without update the rig. i.e change UV or things like that(btw: I am not big fan of that part)

I was using constraints in this project because the final asset was not dependent of mGear solvers. In other words, the rig was done with Shifter, but you don’t need mGear or the solvers to use it.

I am talking with people with more knowledge than me in games and game engines (Unity and Unreal) to finish this tool and have a very easy workflow. But is taking time to finish.

If you have any proposal or advice of how to tackle this is very welcome :slight_smile:

Regarding the inverse matrix connections topic, if I remember correctly all the connections are meant to avoid using of the “scale section compensate” from Maya
image

This is not supported in Unity (not sure about Unreal) and doing the way is done now, the rigs can have squash and stretch without shearing

I hope this helps.

I will try to finish the tool. ASAP. and add some video tutorial of how to use it.

Cheers,
Miquel

#7

Im using mGear with unity for some projects and I can lay out how I transfer the animation over. First I export the character geometry and the jnt_org folder together as an FBX, this gives me a clean skinned character to use as a base in Unity. I then go into my animation scene and import any references I have (unity uses names to link all the bones between animation files). I then just bake the jnt_org tree and export that as its own FBX. In Unity I then just link that animation file to my clean character. Not sure if that helps on the Unreal side but its fairly quick process.

#8

Thanks everyone for your responses.

@Rafael, Using a flat hierarchy does resolve the scaling/shearing issue, but then breaks animation sharing in Unreal =/. The bind skeleton needs to be in a parent child hierarchy for animation sharing in Unreal to work correctly.

@Miquel, From my understanding Unreal will take whatever animation data is supported in FBX 2016. Currently FBX doesn’t support scale compensation or non-orthogonal matrices, which I’m pretty sure I have both going on with my rig at the moment.

As for exporting to Unreal or Unity would be best without the mGear solvers. How you where saying the rig is done with shifter, but doesn’t need mGear solvers to use it. I do remember reading in the docs you’re using those solvers because they evaluates faster than the constrained setup no? With that in mind, my ideal would solution would be the animations goes through some sort of validation(pyblish), the bind rig would be stripped from the control rig, the inverse parent disconnected, then re-constrained back with scale and parents constraints, exported as FBX, then imported into Unreal by calling a command line function. Supposedly Unreal support some kind of python scripting, but I’ve yet to figure out to get outside python to talk to Unreal.

@Ken_Pellegrino Adding a picture to better show what all the issue is. The way you’re describing your workflow isn’t too far off from our studio’s soon to be changed workflow. If you’re not non-uniformly scaling your characters this may not be an issue for you, but our animators demand squash and stretch.
shearing

Thanks again everyone.

#9

Hi @hoover900

I check to export to Unreal with squash and stretch. I did some test in the past with Unity, and I didn’t see the shearing issue. But I will try again to be sure.

I will use my model, but is is possible can you send me a PM with some sample data to test?

Thanks,
Miquel

#10

This was done using some components that are not public (Mainly because are not clean and a little buggy). But this is only for use inside Maya. At export time should no be difference. Is just a matter of clean the rig to export.

and in this case the “solver” is just a matrix multiplication node.

let me a few days to research this, because I am also very interested in have this workflow clear and easy :slight_smile:

1 Like
#11

Hola Miquel,

any updated on the FBX export workflow?

#12

Not yet. I am on vacation now.

However this will take some time. Since is not a priority for our current project, and I will do it on my spare time

Thanks for understanding

#13

Hi @hoover900 and @all
I have been adding some changes to help FBX export and general Game pipeline

The new game tools is done:
image
Basically splits the asset in rig and model (geometry and joints) and help to re-connect referencing the 2 new filles. This will facilitate to separated clearly the part to export to engine and the part that is only for Maya.
I will record a video on this ASAP.

Also some changes/options for the joint scaling.
image
This force to have uniform scaling in all Joints by using only one axis to drive XYZ. For the moment is hard coded to Z axis. Not sure if optional axis are needed.
With this if we scale the FBX error log of non orthogonal axis should be solved.

Also updated arm_2jnt_01 and leg_2jnt_01 to have optional elbow and knee support joints:
image
by default is on so the configuration stay the same as before for backwards compatibility.

here is a capture of the result diferences:

image
image1058×690 14.8 KB

NOTE: with this option off, the elbow need axis will have full rotation, not 50% like before.

Also is possible to set the joints division to 0. So we get super basic chain

image
image1072×706 25.3 KB

OPEN CALL for BETA Testers!!!
I need to check this and export to Unreal and Unity to be sure everything is stable. Please post here or send me PM if you want to test the tools

What I need from the testers?

  • test deformation with and without this option side by side in characters
  • test exporting to Unreal Engine with squash stretch animation
  • test exporting to Unity 3D with squash stretch animation
  • provide sample data, images and feedback

Thanks,
Miquel

1 Like
#14

Hey,

I am interested in testing this, but its not for Unity or Unreal, its for my companies internal engine.

Can we sync the develop branch to test?

Thanks
Dave

#15

@Miquel

Once I get a chance to I’ll grab this and test it out.

#16

This looks great Miquel - we’re working on quite a bit of app / web / engine stuff at the moment - would love to give these additions a test.

Love the fact you can set the divisions to zero now, and the remove the optional def joints around the knee / elbow.

Cheers,

Geoff

#17

Thanks for the help @hoover900 and @Geoff I will prepare the Beta this weekend and post here the download link

#18

@Geoff @hoover900 @floppyDJ and everybody interested :slight_smile: The beta is available here: https://github.com/mgear-dev/mgear_dist/releases/tag/untagged-e7cebf090ad3b8a2d954

Just download the .zip file

Remember:

However any other feedback or advice is very welcome :slight_smile:

Here is a video with some explanations (crash included ;))

As I comment In the video. I will update the default precision for the elbow and knee joint.

Thanks, for the feedback!
Miquel

#19

The new beta and future releases will have a new repository structure. with all the modules in is own repository.
The new distribution repository is the one that sync everything and final structure: https://github.com/mgear-dev/mgear_dist
But at this point there is only master branch, and you need to deploy with scons to get the working structure that Maya needs.
Not sure if this info is useful for you. But I will do some tutorials and overview of the framework for developers when the next release is more consolidated.

#20

No luck with re-building my rigs on my Mac, but I do have a somewhat questionable python environment. I’ll let you know the results I get from my work PC on Monday.