Can anyone help with a 1 on 1 session to debug a problem!

Hi All,

I have tried to reach out to a few people on twitter but no response, my lead front end dev tried these forums but was asked to put the issue on Playground, it is not that simple am afraid to replicate.

As such, we need someone who is very close to the BB code base to help us for 1-2 hours. Just to jump on and see whats going on.

I will keep on searching but please if anyone can help, it might just be 15 minutes or so. But we really do not know what the issue is.

Here is a brief description of the problem

We have gltf meshes that are loaded and then disabled, then stored in a local variable. They are later used to create instances with various sizes at different positions using a json spec. Currently we are undergoing a problem where one of the mesh is not visible on the screen in spite being present in the instances logged when I test with scene.meshes. This problem only appears sometimes and disappears when browser is reloaded.

Have you tried to set alwaysSelectAsActiveMesh = true on all your meshes / instances and see if the problem still occurs? If not, it may probably be a problem with the bounding boxes.

Tried this and still no luck. @Evgeni_Popov can you please jump on a session with us, I am trying to reach out to everyone for help but seems hard to get someone to jump in, can you maybe recommend someone to us? it will be paid :wink:

Sorry, I already have a lot on my plate and such bugs that occur only infrequently could request more than a couple of hours to fix.

If you are able to share a live url some people may have a look.

Your description of the issue makes me think maybe something in the transformation gets set as NaN? :thinking:

Try logging position, scaling and rotation values when it happens :slight_smile:
also, a live demo would be gold :wink: even if it’s not a PG, live site with non-minimized files.

1 Like

Hi @abs - sorry for the “lost instance” issue. Good to see you again - hope you are well.

Let’s name this issue: MIBR (missing instantiation before reload)

Are you affiliated-with @DANIEL_S and his near-identical-sounding issue? (Also HERE.)

Wingy curious IF/NOT you are working on SAME project, or if IDENTICAL ISSUE (MIBR) on separate projects.

Both you and @DANIEL_S claim issue happens intermittently (sometimes) and claim “reload browser, problem fixes”, yes? nod.

@DANIEL_S included some code in his first report. Same/Near-same code for you, ABS?

Let’s talk cross-browser and cross-platforms, now. Can you (both) test with different browsers, different OS, and different versions of BJS/other-used-libs?

Lastly, IF you are both creating (master) mesh first, and LATER using JSON to create instance… IS another SPECIFIC instantiation of SOME MESH… performed just BEFORE or AFTER the missing instance?

In other words, could an instance made BEFORE or AFTER the MIBR… be causing the problem, and problem is difficult to locate BECAUSE too much looking at MIBR and not enough investigation of pre-mibr or post-mibr actions? Does instance before mibr… or after mibr… actually cause problems (bad instantiation pre-state or post-state)?

Can you “shuffle” the ORDER of the instantiations? Is the MIBR always the 3rd instance of a group of instantiations? Can you de/re-group/sequence… and then re-check symptoms? (& similar tests)

Does the MIBR always happen to the same “master” mesh? Still… only sometimes?

So many questions, huh? nod.

Yeah… good idea (hi aW!). AND setting them… from command line, ideally.

Sorry for butting-in… Wingy not really qualified… but… this is a puzzling and odd issue. This is an issue that likely has a…

“I never thought to check THAT! What an unusual situation!” -solution. :smiley:

SO… Wingy asks goofy investigation questions to possibly help find elusive cause. Ignore me, as needed. :slight_smile:


I have changed implementation from plugin.onMeshLoaded to success callback in the Import mesh function. It seemed to me that sometimes the plugin.onMeshLoaded was being called before the mesh is actually fully loaded which caused the bounding box to be 0 and hence leading to a NaN result when scaling. And it seems fixed now.

            (meshes) => {
                meshes.forEach((mesh) => {
                    if ( !== '__root__') {
                        console.log(`loaded model: ${}`)
                        const originalSize = mesh
                        // remove it from scene
                        // save model to be used for creating instances
                        this._sceneMeshes.set(key, { mesh, originalSize })
                        this.progress += 1
                        if (this.progress === this.totalModels) {
                           // start creating instances after all assets are loaded
                            console.log('Loading successful')
            (reason) => {

Thank you and Yes we are working together on this :wink:

Looks like it is now fixed. Happy days, and thank you very much for all your help


That’s good news, team! Yay!

aWeirdo… scores! Have you seen this before, aW?

Could this issue have been discovered with a try-catch structure? ABS/Dan… if you would like to test a try/catch on that (after-onMeshLoaded) scaling attempt… that would be good info for future.

Perhaps test a time delay between onMeshLoaded and scale-setting (in onMeshLoaded code)?

What is diff between plugin.onMeshLoaded and import success-callback? hmm.

Aw & other Experts: Does plugin.onMeshLoaded possibly need adjustment, or a note in the docs? Any ideas WHY this might (intermittently) happen? Plugin.onMeshLoaded != mesh.readyToAcceptScaleSetting?

Can anyone repro this in playground? Maybe build a test jig?

If BJS team could find the reason, future devvers like ABS and Daniel would not need to interrupt dev and search for hired guns. I am sad that they needed to do that. Can we somehow prevent that for future?

Sorry if I am butting-in, but these guys were somewhat desperate for assistance, and that is unfortunate, esp if they are in a time == money situation. Nosey, purposeless Wingnut… over and out. (thx for assistance from all)

1 Like

If someone can provide a repro I would be happy to check

Maybe the docs need an adjustement: the onMeshLoadedObservable observable is triggered when the mesh is created but some data may not be loaded yet because they are loaded asynchronously.

The end of GLTFLoader._loadMeshPrimitiveAsync is:



return promise.then(() => {
    return babylonAbstractMesh;

The promise returned comes from a Promise.all(promises) where promises is an array of promises that loads the data of the mesh asynchronously.

So maybe the end of the function should be something like this instead:



return promise.then(() => {
    return babylonAbstractMesh;

This way, the notification would come after all the asynchronous data have been loaded.

@Deltakosh @bghgary What do you think?


I like the idea!

That will break some scenarios. The observable is intended to return as early as possible.

Perhaps the documentation can be improved?

This is what it currently says:

Callback raised when the loader creates a mesh after parsing the glTF properties of the mesh.

Maybe we could add that additional data will be loaded later

1 Like

Tried it once or twice yeah :joy:

1 Like

PR for the doc on its way:


Am glad all this has helped improve BB a little more :slight_smile:

I am hoping to share with you all what we are doing once its all up and running. Very excited by the development.