Babylon.js: some materials on a glTf mesh animated through bones are randomly rendered or not

[Vinc3r]

Bugs

• Bug repro on this zip file: gltf-armature-anim.zip
• Expected result: all materials are rendered since the mesh is visible
• Current result: some materials disappears when the mesh coming at the border of the camera, video (check yellow and green materials)

Software used: Blender 2.79b with last gltf-exporter addon, BJS preview v3.3.0-alpha.9 (but also tested with v3.2.0)

The blend file is on the zip, as the BJS scene too.
In the blend side, it's a very simple scene, with one object animated through an armature, this one having a very simple animation. The object have multimaterials on it.
In the BJS side, nothing specials, just a basic gltf import.

[deltakosh]

This may be an expected result.if the animation moves the geometry out of the initial bounding box then the mesh can be clipped by the frustration

[Vinc3r]

Is there a way to avoid this, by forcing bounding box calculation for example?

[deltakosh]

Not directly because the bones are computed on GPU side (for performance reason)
But you can manually force the bounding box to be bigger in order to enclose the animation

[Vinc3r]

Here the same bug reproduce on a more complex mesh.
gltf-armature-anim.zip

Is it still the camera frustrum here?

So how can I force the bounding box to be bigger?

---

[edit]
By writing this post I've made another test, and adding these lines:

BABYLON.SceneLoader.Load("assets/", "tram-anim.gltf", engine, function (scene) {

    var camera = new BABYLON.ArcRotateCamera("Camera", 1, 1, 150, new BABYLON.Vector3(-1, 0.1, 0), scene);
    camera.attachControl(canvas, false);
    scene.createDefaultEnvironment();

    /** forcing the bounding box refresh of all scene meshes **/

    for(var i=0; i < scene.meshes.length; i++){
        scene.meshes[i].partitioningBBoxRatio = 40;
        scene.meshes[i].refreshBoundingInfo();
    }            

    /** **/

    engine.runRenderLoop(function() {
        scene.render();
    });

    window.addEventListener("resize", function () {
        engine.resize();
    });
});

It seems the bug is disappear \o/ Am I doing this right or is there a better way to force the BB refresh?

---

[re-edit]
In some case the bug seems to reappears :'(

[Vinc3r]

And it seems I don't have the bug when using the .babylon file format
.babylon_format_armature.zip

[deltakosh]

Pinging @bghgary if the bug only appears with gltf

[menduz]

Same here, it happens also with planes and GUI Controls (v3.3.0-alpha.9)

[deltakosh]

Can you repro on the PG?

[menduz]

@deltakosh I didn't understand your comment, can you expand?

Seems to be fixed on alpha.10, at least my disappearing plane issue

[deltakosh]

Can you create a repro case for your problem in the playground? (no need if already fixed :))

[Vinc3r]

I still have the bug on alpha10 (in both my worm and tramway test scenes).

It's weird 'cause my useless code concerning partitioningBBoxRatio & refreshBoundingInfo(); make a little attenuation of the bug in the tram scene (absolutely don't know why), but have no effect in the worm scene :-)

[deltakosh]

We checked with @bghgary but this is not a bug per se (your Babylon file example is not animated).
The bones are moving the geometry far away from the original bounding box

I suggest you check with the inspector and display the bounding box of your worm.

You will see that the box is smaller than the actual mesh due to bones

We cannot easily update the bounding box because all the bone processing is done on the gpu. So the idea is to scale the initial bounding box manually to make it larger than the larger possible position of the bones

Does it make sense?

[Vinc3r]

Erf, yep I see your point.

By manually scaling the bounding box, you talking about edit the gltf file itself, after export?
I think it's something which should be resolved, because, why not doing that for a personnal project when time is not an issue, but in a professionnal workflow it's not very convenient.
I was hoping something like:

var currentBounding = currentMesh.getBoundingInfo();
currentMesh.setBoundingInfo(currentBounding);

could be able to recompute the boundingBox, or maybe a new thing like boundingBoxcaling = 20 to set on scene launch on some objects?

(about my little scene using .babyon file, I have an animation with skeleton in it)

[deltakosh]

Well this should already be supported
I'll check tomorrow and report back here.

If not supported I will add an API to scale the bounding box

[Vinc3r]

Glad to read, thanks! ;)

[deltakosh]

Ok next commit will fix it
You will be able to do this:

sphere.getBoundingInfo().scale(2);

[Vinc3r]

You roxx, thanks!

[Vinc3r]

It's fucking works, nice job! 🥇