[Request/Question] Import FBX for static mesh & skeletal & animations

[Hevedy]

Is possible or already is here something to Import FBX files for static, skeletal and animations ? Because i only see something about Ogre like system ? and will be good to have a generic system working like in UE4 or Unity

[cadaver]

Our FBX import is as good or as poor as Assimp allows. (using AssetImporter). Would probably be good to import the newest Assimp head revision at some point to see how much it has improved.

[OldSnake22]

Yeah there's been plenty of bug fixes since the version used in the actual revision of Urho3D. It would be a good idea to update Assimp.

[christianclavet]

Checked Official URHO 3D 1.4 with FBX import:

• Support up to FBX 2013. (I convert most of them to FBX2013 and it work fine)
• Can import animated meshes with their animations.
• Materials so far are well supported.
• Will fail to import a FBX that don't have any meshes and only animation data on bones (Assimp issue)

Once you have imported the mesh, it will appear as a static mesh in the editor. Just remove it and get the converted .mdl as an animated mesh.

[JoshEngebretson]

I am currently having an issue with both Urho master (older AssImp) and Atomic (where I updated to latest AssImp master trying to figure this out).

The model is an FBX, however I have converted it to DAE as well with the same problem. I have also imported a different skeletal model which exhibits the behavior.

The attached screenshot shows the issue, the model is fine if it is at the origin and animations play fine at the origin as well. However, the further the model moves away from the origin the more distorted it gets... the screenshot below is maybe a few hundred units from the origin.

I've been banging my head into this for hours. Any thoughts? Thanks!

[HeadClot]

@JoshEngebretson -

1. Is it a floating point precision problem? That would be my first guess if things are getting messed up the farther you are moving away from the origin.

What you are describing mirrors exactly what was happening with other people when the cryengine FreeSDK was around. LINK

How far out from origin is your model?

1. It also could be a problem with the skinning of the model. So the weights are not right. On this I would advise you import your robot into an application such as blender or Maya and see what the skin weights look like.
2. It could be a problem with the import process as noted above.

Just curious, HeadClot

[JoshEngebretson]

I don't believe it is specific to the model. It could be the import process or some kind of precision issue with small weights, etc.

Here is a gif which shows the vertices "pulling towards the origin" as the model moves away from it.

I first noticed it with a point on the right hand that would pull away, which is noticeable at less than 10 units away from the origin. By 10 seconds or so of falling the mesh is getting pretty distorted.

[HeadClot]

Hey @JoshEngebretson - Looks like a precision issue at least in my humble opinion.

Can it be replicated with other models? Just curious.

[friesencr]

What happens if all the weights don't add up to 100%?

[JoshEngebretson]

@HeadClot Yes, other models exhibit the issue.

@friesencr I verified at import time that the weights are normalized. I can try some runtime checks as well.

It looks like Jack and the ninja in the repo went through OgreImporter possibly some time ago. If AssetImporter can take the xml, maybe can try importing it through it... or is there a source FBX or DAE around for Jack?

[cadaver]

Tested import of an animated scout DAE model from some Collada files package, no deformation at least at (500,0,0)

Jack may exist as a 3DS Max source file somewhere at www.realxtend.org, haven't personally seen it for some time. Otherwise it has only ever been an Ogre mesh.

[Stinkfist0]

Hi, I happen to have these in my DB, I think they should be ok to share: https://dl.dropboxusercontent.com/u/16413694/rex/realxtend_avatars_3dsmax.zip https://dl.dropboxusercontent.com/u/16413694/rex/realxtend_avatars_obj.zip

[Mike3D]

The ninja is from Psionic (http://www.psionicgames.com/free-stuff/free-3d-models/)

[friesencr]

@JoshEngebretson There was a time in Blender <= 2.7 where the fbx exporter was awful. I had major issues with weights but didn't have quite the behavior you are having. The new blender fbx uses a new binary version and works much better. You can try importing and reexporting or using fbx convert http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112&id=22694909 and if that fixes your problem then than your source files are suspect. If people are using any non open source tools like unity than the files will work.

If you want to read a humorous article my wife wrote on animation exports/imports. It demonstrates the limits of human will and how to prepare an old blender fbx to be used with the proprietary fbx convert tool http://teamfriesen.com/blog/2013/09/07/finally.html

[JoshEngebretson]

Thanks guys!

@cadaver Do you have any thoughts of places to start based of the gif above? The skinning and animations are perfection at the origin :/ Does the tested scout model have very complicated or subtle skinning?

@Stinkfist0 Thanks, max format it a bit of a challenge. I'll look for some more models that exhibit the problem.

@Mike3D Great, the ninja is very simple and may not show the problem though

@friesencr Good ideas, I do have the fbx tool and have tried converting it. I have also used it to convert to DAE. I've got around 10 hours into trying various things and stepping through the import code, ensuring weights, etc. Skinning math is kind of a kryptonite :) I'll have to read that article :)

I attached the FBX and a converted mdl using AssetImporter. The one thing is that assimp can't handle offsets. so it creates additional nodes to handle them. You'll see them as something like $Assimp_FBX$ and they won't have animation tracks.

One thing, the model works fine when imported into Unity. So, I am thinking maybe some kind of precision issue or maybe something at import time with assimp or something is being lost as there are 160 or so bones that are getting mapped, due to the new channels being created.

https://www.dropbox.com/s/wo7fqs93s9iu8ny/RoboModel.zip?dl=0

[cadaver]

The scout model's skinning is simple as hell, I'd imagine a max of 2 bones per vertex.

It looks like AssetImporter trusts the weight data blindly, so if it's receiving weights that don't sum to 1 then it would write a bad mdl file. I'll do a bit of checking with the robo fbx.

[JoshEngebretson]

The Roboman model would benefit from a cleanup pass by someone good with 3dsmax. For example, aiProcess_LimitBoneWeights is limiting some bone weights.

I did put a check in to verify weights were normalized. I also updated to the latest AssImp master to see if anything helped there.

The main thing that puzzles me is that he works on the origin.

[cadaver]

If the weights are normalized, then perhaps bone offset matrices could be bad, which means they "scale" the bones' skinning positions toward the origin, and the effect becomes more noticeable as you travel further away.

[cadaver]

The robot issue was some vertex weights not summing close enough to 1. Now AssetImporter (change pushed in master branch) renormalizes weights always if not exactly 1.

[JoshEngebretson]

Fantastic!

The change from a fatal error to warning with normalization is very good as in many cases a little weight being dropped is fine and will save artists in some cases significant effort. I think newer AssImp may be trying to compensate for this or something as I was asserting if weights != 1.0f

Verifying! :+1:

[JoshEngebretson]

Does it intend to warn here as well?

https://github.com/urho3d/Urho3D/blob/master/Source/Tools/AssetImporter/AssetImporter.cpp#L1944

Edit: Verified this fixes things locally, THANKS!

Edit2: For the dropped weights, are these guaranteed to be in order from most to least influence in the array?

[cadaver]

Not guaranteed at the moment. I'll rework that part of the code.

[JoshEngebretson]

Thanks Lasse, the update is solid and working great :smiley:

[christianclavet]

I've done some import tests with the importer but my meshes were really big (72 unit tall aprx), so I did not see any precision issue.

Not played much with them in the editor too. But when imported they looked ok.

Wow! Looked at the animated picture, and the vertices seem to align themselve with WORLD 0,0,0 and not LOCAL 0,0,0. If URHO has hardware skinning, the vertices must be processed by some kind of shader (GPU skinning)... Could the vertex shader take the wrong "base" for the transformation matrix as world and not local?

[cadaver]

The issue with the robot was skinning weights not quite adding up to 1, for example 0.9995. At longer distances from the origin this starts to skew the faulty vertices' positions toward world origin, as the math in the VS is worldPos = (skinMat1 * weight1 + skinMat2 * weight2 + skinMat3 * weight3...) * modelPos

This was already previously taken care in OgreImporter (.mesh.xml -> .mdl) utility, but now also done manually in AssetImporter, as it seems we can't trust Assimp in all cases to already normalize the weights for us.