Creating new scene and gizmo after disposing previous gives error

Hi, I am trying to create and delete multiple scenes. I have 3 to 5 scenes in memory at one time but only one is being rendered. I can change scenes or delete them. When I delete a scene I do the following steps:

  • Remove pointerObservable of the current scene
  • detach camera control
  • dispose gizmoManager utilitylayer(which I create manually when creating gizmo manager)
  • dispose the scene

After the above process I assign a scene which I had already created before to render.
Then I do the following steps:

  • add pointerObservable to the current scene
  • attach camera control
  • create a new gizmoManger with new utilitylayer for the current scene

Babylon versions:

ā€œ@babylonjs/coreā€: ā€œ^5.0.0-alpha.27ā€,
ā€œ@babylonjs/loadersā€: ā€œ^5.0.0-alpha.27ā€,
ā€œ@babylonjs/materialsā€: ā€œ^5.0.0-alpha.27ā€,

Error:

@Cedric Can you please take a look at this. I donā€™t know who else to tag the error is being thrown when I create a new GizmoManger with utiliyLayer.

Hi @Hamid_Nawaz

Sure I can take a look! Can you try to repro the crash in a playground?

Sorry I cannot reproduce the error in playground it seems to be working there correctly I am not sure.

Do you have a sample somewhere so I can repro the crash ?

I am trying to reproduce the error in this playground. This can produce the same error but the obvious issue is that I am trying to load a scene which is already disposed.
https://playground.babylonjs.com/#MXCRPS#173

https://playground.babylonjs.com/#MXCRPS#175
In the above scene first press key ā€œ2ā€ to shift to scene 2. Than press key ā€œ3ā€ to shift to scene 3. After than press key ā€œdā€ to dispose scene 3 and shift to scene 1. Now after that when you press key ā€œ2ā€ to shift to scene 2 it throughs that error.

1 Like

Iā€™ve found whatā€™s going wrong.

If you dispose the latest scene created, then lastCreatedScene is null. lastCreatedScene is used to create the layer for the gizmomanager hence the crash.
To fix your issue, more a workaround, I suggest to create a dummy scene after scene1,2,3 are created. So lastCreatedScene is never one you will delete.

Ohhhh I wonder how we could address this one nicely ? any amazing idea @Evgeni_Popov or @Cedric ? mine is currently completely over engineeredā€¦

I would use an array of scenes and remove it when the scene is disposed.

We do have the list of the scenes in engine, so we should be able to set EngineStore._LastCreatedScene to engine.scenes[engine.scenes.length - 1]

My main guess is if the scene can be random, why not creating a dedicated one ??? (I am total n00b to this code)

Or the solution in the multi scene scenario is too let ppl know in the doc to create their own utility layer ???

I think itā€™s more global than just for gizmos.

Thereā€™s some code all over the place that is taking EngineStore._LastCreatedScene (or EngineStore.LastCreatedScene which is the same) if you donā€™t provide a scene yourself.

If you create scene1 and scene2 then dispose scene2, then EngineStore._LastCreatedScene will be reset to null and none of the code that is using EngineStore._LastCreatedScene will work anymore whereas we should have set EngineStore._LastCreatedScene to scene1.

I think we should do something like:

if (EngineStore._LastCreatedScene === this) {
    if (this._engine.scenes.length > 1) {
        EngineStore._LastCreatedScene = this._engine.scenes[this._engine.scenes.length - 2];
    } else {
        EngineStore._LastCreatedScene = null;
    }
}

Note that the current scene is not removed from engine.scenes yet, thatā€™s why Iā€™m taking this._engine.scenes.length - 2.

After some discussion with @sebavan, we think this PR should fix the problem:

However, you need to pass a utility layer renderer based on your scene for the keepDepthUtilityLayer parameter too. So, this PG should work after the PR is merged:

https://playground.babylonjs.com/#MXCRPS#179

2 Likes

Thank you so much guys for the quick fix. How long will it take for the changes to be available in playground.

It should not be long, either today or tomorrow I think.

3 Likes