Hallo,
I’m working with the Babylon.js Exporter for Maya 2018 at the moment, and it works very well for me so far. But recently I ran into a Problem concerning Animation groups.
I animated a Crane in Maya, baked the Animation and exported it as .glb using the Babylon Plugin. If I export one Clip for the whole timeline, it will play correctly. But if i split that animation in smaller animation groups, the extension booms of my crane are positioned wrong.
I’ve tried a view workarounds, but i’m slowly running out of ideas.
Also, I was wondering, if there is a way to export animated opacity of a Material from Maya, so i could have geometry “fade in”. It seems like I can’t even export keys on the visibility.
@Clms, we looked into your file and found an issue with the exporter. I have created a new issue for the problem, but we are in the process of hiring a new engineer to handle the exporters so this issue won’t be able to be resolved in our usual short turn around. Because of that, I have a couple of work arounds for you.
The issue is that when you are doing node animation and key the node’s transform (translation, rotation, and scale) to values that don’t change in an animation group (clip) the exporter writes out a dummy animation file to optimize for size and then reports the node’s transform as identity (the transform of the node when all TRS values are zero), which is where the error comes in. We want the exporter to report the transform as the keyed values in the group, rather than identity.
There are two things you can do to avoid this:
The first is to use a rig and rigid bind your meshes to each appropriate joint. Skeletal animation does not suffer from this issue, which is most likely why it wasn’t detected before now. Not a lot of complex motion being done with node animation.
The second is to add one keyframe of a slightly different value to one of the TRS values for each node that does not change its transform within an animation group. This can be a very small change like having nine frames of the animation group with a z translation of 0.0 and the tenth frame’s z translation at 0.001. This isn’t the best work around, as you have to manage a lot of nodes to make changes for each animation group that is still.
I did make this correction in the maya file for you so you can see what I mean, but it looks like this:
I changed one frame’s translation to -0.01 just for the exporter to register some sort of change. But you have to do that for every node in a clip that doesn’t move.
And you can see that in the sandbox, the extended clip now plays correctly:
I would strongly suggest looking into rigging your meshes to a skeleton, however, because you are getting into a place where you are having some more complex motion which could really hamper you with this issue in place. We will get it corrected as soon as we can, but need to hire an engineer into that position first.
For now, however, here is the Maya file and the glb that is working. Please let me know if you have more questions or run into anything else.
Thanks alot for the description and for creating that Issue. Thank you also for your suggested workarounds.
The files i uploaded are just a primitive rebuild of a more complex crane i’m using.
I am using a rig on that crane but since the booms can only move along one axis, i animate their translate with a driven key on custom attributes.
Also, if I’m trying to export that complex crane directly as .glb, it takes >10h. So I’m exporting it as .fbx first, and bake all animations in that step to reduce the final .glb export times to about 1h.
I’ll change my animations, so they all start with the same pose. That way I’ll have animations on each node.
I’m looking foward to getting this issue solved sometimes in the future.
@Clms, I just realized I didn’t answer your second question about animating material parameters. Right now, we don’t support animating material parameters in the Maya exporter, but it is on our road map for future development. What you can do for now is do a simple Babylon.js animation in javascript for your scene that ramps your alpha of the material when you need to.
You can find everything you need to create a Babylon.js animation in the animation docs.
Let me know if you have other questions or concerns.
@PatrickRyan@Deltakosh taking a quick look at BabylonExporter.GLTFExporter.Animation.cs , it looks like there is an issue with the optimization logic. I did a quick hack by setting the “optimizeAnimations” boolean variable to false and it was able to export the animation behavior to glTF. The optimization logic will probably need to be double-checked. Exporting to babylon file format seems to look more consistent with the expected result.
@PatrickRyan@Deltakosh@Clms I just merged a fix for the optimization logic. It was indicating that an animation group with only two key frames of the same value was not valid. Now, that case should be considered valid.
Hi, I’ve been updating to Babylon Exporter version 1.2.30 and now I’ve got a similar issue with animation groups again.
This time only one boom is placed wrong. (the 2nd)
But again, this only happens if I export Animation groups.
I wasn’t able to repro this issue quickly with the primitive crane, so i can only show a screenshot for now.
@Clms does the boom in the wrong place have any keyframes set? It may be another edge case, but a little tricky to pin down without a sample scene.
Version 1.2.29 created an animation for all animation groups with two frames, though this caused issues where scenes without animations were exporting with animations (the start and end frames of the timeline). Version 1.2.30 restricted the two keyframe animations to only translation, rotation and scale that were not the identity position. Is the incorrect boom at the origin position?
Hi, the whole Animation is baked, so there should be Keys on every Frame. The incorrect boom is not at origin. Origin is where it is supposed to be.
I’ve been trying to repro that issue today, reverted to 1.2.29 and back to 1.2.30 a view times, and now it’s not happening anymore for some reason. I’m very sorry for that wrong alert.
