3D skinned animation

[bosoni]

Hi.
I tried my engine's 3d animation character with KNI and it renders but bones are distored (but it works with MonoGame and FNA).

I updated XNAnimationMG and it works, convert that to KNI, I can see only fonts, but no 3d character.

Can you check and make minimal test case (and share it) where 3d animated character is working (if using blender, then .blend file too, and ofcourse exported .fbx)

[nkast]

Hello there,
There is a sample of Skinned animation here:

Live demo: https://nkast.github.io/Aether.Extras/wasm/Animation/
Code: https://github.com/nkast/Aether.Extras/tree/main/Samples/Animation

Could you replace Dude.fbx with your model to see if it's working?

I have some questions to understand if this is an issue with the content pipeline or not.

Also, did you used XNA to build .xnbs for FNA?
Are you using the Content pipeline and the stock ModelProcessor, etc?

Have you tried swaping the produced .xnbs between KNI and FNA?

[bosoni]

Some answers now, I will check Dude if it works (have some other problem now).

When using MG/FNA I use MG's content pipeline, and when using KNI I use KNI's content pipeline. Copied MG exported 3d character to KNI animation test, it does not render, no error, nothing.

That Aether.Extras animation works (but that font gives error, you might change that to Arial, I dont have that font which it wants to use nkast/Aether.Extras#4

[nkast]

Can you inspect for any differences between the Models, for example .XNB uncompresed size, number of Bones/Mesh/MeshParts. Num of vertices/indexes/Vertex types?
For example, do all VertexBuffers have the same IVerteType? Normals?

[bosoni]

I have problems with memory now but I finally copied stickman (I share it, stickmanM is that xnb which should have model+animation) to Aether Animation sample, it load it (1 mesh, 24bones) but does not found animation clips (animation null, should be Idle and Walk). And that was compiled with KNI content pipeline.

I share .blend and .fbx files, no xnb files, if you can get stickmanM (M is for model) to work, please tell how you did it
models.zip

[squarebananas]

Just tried your model with the skinned model sample (originally for XNA) and I can see differences as well between MG & KNI:

Screen.Recording.2025-09-16.181926.mp4

Screen.Recording.2025-09-16.183852.mp4

There are more keyframes present in KNI, but I'll have to compare more details. I can't try placing the MonoGame .xnb files in KNI because it throws an assembly name issue, otherwise that would indicate if it's a content builder issue or runtime issue.

MonoGame

currentModel.Meshes.Count: 1
currentModel.Meshes[0].MeshParts.Count: 5
0: NumVertices 3847: PrimitiveCount 7230
1: NumVertices 2856: PrimitiveCount 4449
2: NumVertices 3876: PrimitiveCount 6578
3: NumVertices 2273: PrimitiveCount 3807
4: NumVertices 274: PrimitiveCount 442

skinningData.AnimationClips: 1
skinningData.Bones: 58
clip.Duration: 00:00:01.2083333
clip.Keyframes.Count: 1628

KNI

currentModel.Meshes.Count: 1
currentModel.Meshes[0].MeshParts.Count: 5
0: NumVertices 3847: PrimitiveCount 7230
1: NumVertices 2856: PrimitiveCount 4449
2: NumVertices 3876: PrimitiveCount 6579
3: NumVertices 2273: PrimitiveCount 3807
4: NumVertices 274: PrimitiveCount 442

skinningData.AnimationClips: 1
skinningData.Bones: 58
clip.Duration: 00:00:01.2083333
clip.Keyframes.Count: 3942

[nkast]

It's normal to have more keyframes because KNI generates 60 interpolated keyframes per second. Just like XNA did. You can see how smoother dude's hands are.

Now the other model has serious issues.

[squarebananas]

It's normal to have more keyframes because KNI generates 60 interpolated keyframes per second. Just like XNA did. You can see how smoother dude's hand are.

Nice, don't know why I didn't notice the smoothness before with KNI. With the MonoGame one I recall thinking that dude's hands are glitching more than I remember.

Now the other model has serious issues.

"Had serious issues".

Screen.Recording.2025-09-16.222009.mp4

Seems to be related to the root transform differences with Blender export or something. There has been some discussions on MonoGame regarding this before where Assimp tries to correct for the root transform, but in some cases this breaks things although maybe not here. Previously @TheKrumpet found this which seems to be the breaking change: https://github.com/assimp/assimp/pull/5494/files

That would explain why this appears correct for MonoGame as that uses a later version of Assimp. It should be noted though that they are currently looking to add a property to revert that change as the default setting.

@bosoni For now it appears you can use the content pipeline processor parameters as shown in the video to get around this issue. In particular:

/processorParam:RotationX=90
/processorParam:Scale=0.01

[TheKrumpet]

@squarebananas the fix for that issue isn't yet merged: MonoGame/MonoGame#8963 so it's unlikely to be that (unless you're testing against that branch specifically).

[squarebananas]

@squarebananas the fix for that issue isn't yet merged: MonoGame/MonoGame#8963 so it's unlikely to be that (unless you're testing against that branch specifically).

I meant that because the fix isn't merged and the 3.8.3 / 3.8.4 root transform correction is still being applied, then when it is merged the MonoGame version may end up looking like the KNI version in the first video I posted. It may have been exported in a way that will look correct when that root transform correction is applied. I guess I can try out that fix myself to see though.

[nkast]

The KNI importer is Applying the FBX root tranform as well.

kni/src/Xna.Framework.Content.Pipeline.Graphics/OpenAssetImporter.cs

Line 950 in 149d29a

private static void MetaTransform(NodeContent rootNode)

I was expecting to see the model rotated with processorParam:RotationX=90.
It could mean that it doesn't apply the fbx root tranform correctly on animation tranforms and it's working only for mesh bones.

[nkast]

Here are some of my findings...

A) There is no problem with GlobalSettings/metadata.
Stickman and Dude have the exact same global settings. Because the model is exported as Forward: -Z, Up: Y. If I export with Forward: Y, Up: Z, which is the native coordinates of Blender then I think the rotation is corrected but the scale is still off.

B) The Stickman model has an additional node after 'RootNode and before 'Bone', that has a tranform that looks like a scale x100 and a rotation. That node isn't added in the _deformationBones because a bone is not found with that name, but it is identified as a _rootBone by FindRootBone(...).
That _rootBone is used as the parent node in the first call of ImportBones(...). And maybe the issue is in the transformations there.

Also, it's unexpected how RotationX and Scale in the processor fixed the issue. MeshHelper.TransformScene(...) should also rotate and scale the Bones/Animations, right?