Assimp-based model import and the MonkeyWrench library

Sounds amazing and very useful Stephen!! Thank you very much.
Today I’m putting quite a bit of effort in Blender to merge all the animations, resetting the Hips:Z to zero etc.
I just read the code, didn’t try it yet. I see in the comments:

Each animation should be downloaded "in place" (if possible) and without

In my experience most of Mixamo’s animations cannot be marked as in-place so the question is - can you programmatically enforce whatever animation provided to be in-place by default in that tool?

Again thaks for that tool - should be very useful

1 Like

ImportMixamo is a brand-new tool; I don’t have much experience with it yet.

It should work fine on traveling animations. I recommend checking the in-place box because I believe in-place animations are easier to use in JME games. (You doubtless know more about that than I do!)

For animations that can only be downloaded as traveling animations, the Wes library provides an algorithm to convert traveling animations to in-place ones. That algorithm is built into the Maud editor.

By the way, ImportMixamo expects one animation clip per file. It doesn’t handle Mixamo animation packs, which apparently contain multiple clips.

1 Like

Another new release, to fix a nasty bug that broke software skinning:

implementation 'com.github.stephengold:MonkeyWrench:0.5.3'

Also, there’s now bunch more documentation in the README file:

  • how MonkeyWrench searches for external textures
  • how to use the MixamoImport application

Hoping this is the last release for awhile…


I agree. It’s easier to use in place animations in games. what I wanted to say is that Mixamo not always allows you to check the in-place option so you need to do it manually using Blender or Wes/Maud

1 Like

very true

Thank you for putting that much effort into Mixamo, unfortunately it has its issue, but the assets would be nice to use during prototyping.

I tested the workflow and i noticed following “issues”:

When you download animations with the same name, you have to unzip → rename → zip the files.
The zip name and the .dae has to match.

Unfortunately the animations seems to not be in place for the “up part”. I guess thats where Maud comes into play. Is there any tutorial available on how to fix this issues?

Screenshot 2023-11-15 092732
Screenshot 2023-11-15 092757

But all in all, i was able to import the first model with animations and textures in like 10 minutes, and the next one is probably done in a single minute. Great work!


Good point. However, I don’t see an easy fix for this.

Unfortunately the animations seems to not be in place for the “up part”. I guess thats where Maud comes into play. Is there any tutorial available on how to fix this issues?

There’s a user guide for Maud and some old video demos. I should create some new ones. It may be possible to automatically convert animations to in-place. I’ll look into that also.

It’s unfortunate that Maud depends on LWJGL v2 and MonkeyWrench depends on LWJGL v3. Otherwise it would be trivial to integrate MonkeyWrench into Maud.


No need to fix. Maybe a notice in the how-to, but it is easy enough to do it manually

1 Like

Here’s the new text in the README:

All assets should be downloaded in Collada (.dae) format. Mixamo automatically archives each downloaded asset using “zip”.

ImportMixamo expects each zip archive to contain a .dae file with the same name. If any downloaded assets get renamed (due to filename conflicts) you’ll need to unzip them, rename the .dae files, and re-zip them. Other than that, it shouldn’t be necessary to modify downloaded assets.

It turns out this is somewhat harder than I expected. The translateForSupport() method in Maud was never adapted for the new animation system and was never added to the Wes library.