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?
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.
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
Hello,
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?
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.
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.
Version 0.8.1 of the Wes library (released on Monday) adds a translateForSupport() method for the new animation system, among other things.
I used ImportMixamo with translateForSupport() post processing to generate an “Erika” character model, which I uploaded to the characters-for-jme project. Vanguard, who didn’t get any post processing, appears to hover in many of his animations. Erika, on the other hand, stays in contact with the floor no matter what she does.
I’m noticing that different animations need different post processing. Some animations return the character to its starting pose, but translated; those animations should probably be treated with convertToInPlace(). Animations that show the character jumping or falling should probably be treated with translateForInitialSupport() instead of translateForSupport().
I think this points to using a interactive tool like Maud for post processing. Upshot: I still plan to do video tutorial on using Maud.
Hi @sgold , I look forward to trying out the new version of the library! In the meantime, I noticed that there is a bug in the transparency of Erika’s model’s eyebrows. What could be the reason for this?
The eyelid visibility issue is a bug. (Drat!) However, Erika’s eyelids are opaque in JME. (If you’re not convinced, simply hide or remove her eyeball meshes!)
This looks to me like a positioning issue. Either the eyeball geometries are too far forward, or else the body and eyelash geometries are too far back. I remember seeing a similar issue with Zophrac; it might or might not be related.
I’m unsure whether this indicates a bug in Assimp or something specific to MonkeyWrench. (It could even be a bug in Mixamo’s DAE conversion, I suppose.)
I’ll investigate further.
EDIT: After experimenting with various online Collada viewers, I’m convinced the issue is in the downloaded DAE, not Assimp or MonkeyWrench. Tweaking bind-pose transforms (of the eye bones) is the sort of thing that Maud ought to be able to do, so that’s where I’ll focus my effort.
Hi Stephen,
I would like to convert all my game models to j3o files.
Can I use MonkeyWrench for converting the loaded models to J3O file? if so, which test app if any has a sample code for doing so?
I would like to convert all my game models to j3o files.
Can I use MonkeyWrench for converting the loaded models to J3O file? if so, which test app if any has a sample code for doing so?
Yes, once you’ve loaded a model using MonkeyWrench you can easily write it as a J3O.
Writing a J3O is a simple matter of instantiating a BinaryExporter and a writable File and then invoking binaryExporter.save(savable, file).
The Heart library contains a utility method that I used in the ImportMixamo app:
If your game model references external textures (that have their own asset keys) you may need to save those separately.