Hi there, everybody:
In order to automate (without using a redundant data structure made of “toExport” flags) the exportation of a scene to GLB, where the users can enable and/or disable nodes at will, I’d like to use something like this so only enabled nodes are exported:
...
var options = {
shouldExportNode: function (node) {
return (node.isEnabled());
}
};
BABYLON.GLTF2Export.GLBAsync(_scene, assetName, options)
.then((response) => {
...
}
};
...
Sadly, it raises an exception. Any advice on the proper way to use this approach? Is it even possible?
Thanks for your time.
1 Like
Hello! What kind of error it is raising? Can you share a Playground reproduction of the error with us?
Hello, @carolhmj:
My scene is certainly not a very simple one and, moreover, contents are under a NDA, so I must think about how to simplify it in order to be translated to a PG.
Anyway, the node.isEnabled approach should work, isn’t It?
Thanks for your time.
Hello, @carolhmj:
Finally, the problem doesn’t have to do with the disabled nodes. The GLB is indeed exported without them, and I’m able to visualize it with BJS Sandbox (by the way with a lot of severity 3 errors).
The case is that I’m using Google’s model-viewer to show that exported GLB in AR, and is that web component which is raising the exception.
Maybe the animation-groups, that I’m not using but are still in the scene, referring to not exported nodes (as they’re disabled) have something to do with it. How can I filter the animation-groups in shouldExportNode, in order to not being exported?
Thanks for your time.
It’s not possible to exclude animation groups with shouldExportNode, but I’m going to work now on an option to exclude anything that references a node referenced by this function.
1 Like
Hello @carolhmj:
Thank you very much, maybe it could make the trick. I really hope so.
As a more in deep explanation, I have a wardrobe with one, two, three, or four “pieces”, so when the user selects a three-piece wardrobe, the fourth one is disabled, and so on.
As all the wardrobe pieces have an open/close animation attached (by means of an animation group) I’m thinking that perhaps the orphan animations, that is, the ones pointing to not exported (as they are disabled) wardrobe-pieces, may be the origin of the crash in model-viewer.
Indeed, if I don’t disable any wardrobe-piece, the exported GLB (with all the four wardrobe pieces) is shown by model-viewer without complaint.
Thanks for your time.
Do the disabled wardrobe pieces have skeletons? I did some testing around and found out that “orphan” animation groups aren’t considered invalid GLTF, like this example file: AnimationGroup demo | Babylon.js Playground (babylonjs.com). If you drag it to the sandbox you’ll see that the validator returns that it is a valid file, despite having some warnings. I’ve tried in other viewers and they weren’t able to open the file, but that’s technically not following the spec since it’s a valid file 
However, trying to export the Alien test file, which has some skeletons Available Mesh BoomBox | Babylon.js Playground (babylonjs.com), and dragging it to the sandbox did generate an invalid file as per the validator, as “orphan” joints are indeed invalid per spec. So I’ll be pushing a PR that doesn’t export joints if they nodes they point to have not been exported, which fixes the invalid file issue.
EDIT: PR has been added Don’t export bones of nodes that are not exported. by carolhmj · Pull Request #13604 · BabylonJS/Babylon.js (github.com)
Hi there, @carolhmj:
My GLTF file doesn’t have skeletons at all, only baked animations. So I think the PR are you submitting is not going to solve the issue in my case.
As said:
-
I have a file with several wardrobes (two-pieces, three-pieces and four-pieces). The doors are animated, so you can open and close (open played backwards) them;
-
that file is opened without problems by BJS engine (both by code and with Sandbox) and model-viewer web component (both by code and by using its Model Editor);
-
in my webapp, I let the user enable and disable groups (transform nodes) in order to show the wardrobe he/she wants to configure;
-
I export the scene to GLB by using the BABYLON.GLTF2Export API, excluding the not enabled nodes;
-
in order to be showed in AR I load the exported GLB on model-viewer. Sadly, this web component raises an exception, complaining about nodes that can’t be downloaded/found (at last line of the following abstract):
/**
* Specification: https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#nodes-and-hierarchy
* @param {number} nodeIndex
* @return {Promise<Object3D>}
*/
loadNode( nodeIndex ) {
const json = this.json;
const extensions = this.extensions;
const parser = this;
const nodeDef = json.nodes[ nodeIndex ];
// reserve node's name before its dependencies, so the root has the intended name.
const nodeName = nodeDef.name ? parser.createUniqueName( nodeDef.name ) : '';
...
I suspect something in the exported GLB is trying to address a node not in the file already. And I think that is something related with animation-groups, because by using the same file with several wardrobes, but without the doors animations (that is not animation groups at all), in my webapp I can disable node groups and export it to a GLB, and the model-viewer components opens the file without problems.
Best regards.
Hello again, @carolhmj:
After a battery of tests, now I can assure you that the problem comes from the not exportation of nodes that are indeed referenced by the baked keyframes in animation groups. Of course that animations should not be exported as they’re referring to not exported nodes.
As a really-dirty workaround, I’ve managed to have the exported GLB working in scene-viewer by exporting all the wardrobes pieces, but scaling to 0 the ones that should not be not exported. Of course, this is not admissible in a production code.
So, do you think that a proper fix of this can be available soon?, namely;
-
automatic: I mean as in the PR you’re submitting for approval, but including also baked keyframes, not only skeletons issues;
-
manual, by means of an additional option for GLTF2Export, where you can pass a list of animation-groups to exclude from exporting.
In the meanwhile, maybe a workaround would be to disconnect all the animation groups before the exportation of the GLB, reconnecting them after. How can this properly be done? (without disposing the animations, I mean). Again, we’re coming to the “don’t export animations” option (automatic or manual) in the exporter as the more clean and elegant approach to solve this exporter malfunction.
Best regards.
Hello! Apologies for the wait, we’ve decided to go with the manual approach, so now there’s an shouldExportAnimation function on the exporter options that works like shouldExportNode: Add shouldExportAnimation option on GLTF exporter to filter out animations by carolhmj · Pull Request #13659 · BabylonJS/Babylon.js (github.com)
1 Like
Hello, @carolhmj:
It sounds like a great improvement for the exporter. Do you think that new functionality is going to be released in a short period of time?
Thanks for your time.
As soon as the PR is merged it will be in the next version released. I don’t think it will take long.
Thank you very much, @carolhmj. I’ll take a look at this new method as soon as today in the afternoon.
1 Like