Hello, I am trying to reduce the package size for Anu by switching to tree-shaking imports instead of importing everything from core. However I am running into issue with Engine.LastCreatedScene returns null, which prevents the optional scene syntax from working in meshbuilders and elsewhere.
For example
import { Engine } from '@babylonjs/core/Engines/engine';
import { Scene } from '@babylonjs/core/scene';
Engine.LastCreatedScene // returns null
VS
import { Engine, Scene } from '@babylonjs/core';
Engine.LastCreatedScene // returns the last scene
Its open source! You can see an example pre-tree shaking here. This code doesn’t call Engine.LastCreatedScene directly but as I understand it will be called whenever scene is not passed to a meshbuilder or transform node constructor. I also tried calling it to see the value inside these create functions and it prints null only when imported like the first example.
The library wouldn’t initialize the scene, but any code written with it would have already created a scene (e.g. this scatter plot example)
Yeah I see but then then Engine static would not be the same because your execution context and the execution context of the caller will not be the same. Try to check if scene.getEngine().constructor.LastCreatedScene is populated
If you mean in the caller code, then LastCreatedScene is populated, but the Library code won’t have scope into the scene unless it is passed. However, ideally, that stays optional.
Somehow the Engine is in scope globally from the calling code if it is imported from the core. Same goes for Meshbuilders. If they are imported from core not passing scene still works but imported directly from the source path, it no longer works without passing scene.
i’ll try reproducing it locally and try to understand what’s going on. It is most certainly a context issue, the question is how can we solve this for everyone.
I do not think this is supposed to be a bug. The user is importing the engine in their context and @dsaffo has a different context. Not sure it is not expected here
Unfortunately, this does not seem to have been fixed for my use case. This got lost in the holiday shuffle let me actually get you a repo this time, early next week .