Question
WebGPU to WebGL fallback and scene state preservation after Babylon.js engine initialization
Cig Atlas
0 reputation · 08 Jul 2020, 02:49 UTC
43.3K views1
Loading…
0 reputation · 08 Jul 2020, 02:49 UTC
Engine initialization in Babylon.js requires explicit canvas creation and engine instantiation, with capability detection determining available rendering features such as WebGL2 and optional WebGPU. SceneLoader and AssetManager load assets asynchronously via promises and observables.
Disposal of meshes, materials and textures is manual by default, and scene.dispose does not automatically free all GPU resources unless explicit disposal options are enabled. Behavior is version sensitive around WebGPU support, engine.dispose semantics and automatic texture disposal options.
Capability detection is browser and device dependent and cannot be reliably inferred from server deployment logs alone. An unresolved decision concerns how the engine handles backend fallback and state preservation when a preferred rendering backend becomes unavailable after initialization.
Does Babylon.js preserve scene graph and GPU resource state when falling back from WebGPU to WebGL after engine creation? Which resources require explicit re-creation versus automatic re-binding on backend change? When is fallback supported versus requiring engine recreation?
33775 reputation · 08 Jul 2020, 11:51 UTC
Babylon.js does not preserve GPU‑resident resource state when the rendering backend changes from WebGPU to WebGL after the engine has been created. The scene graph (JavaScript objects representing meshes, materials, transforms) remains in memory as long as you do not call scene.dispose(), but all GPU resources tied to the WebGPU engine—textures, uniform buffers, shader pipelines, and compute shaders—are released when the engine is disposed and must be recreated for the WebGL engine.
babylonjs
webgpuWebGPUEngine and, if it fails or navigator.gpu is unavailable, fall back to the standard Engine (WebGL/WebGL2).engine.dispose()) clears all GPU‑resident resources associated with that engine.WebGPUEngine (check navigator.gpu or catch instantiation error).engine.dispose()) to avoid context collisions.Engine instance attached to the same canvas.Scene and reload assets via SceneLoader or AssetManager; the GPU resources will be allocated for WebGL.Missing diagnostic detail: Are you disposing the previous engine instance before attempting the fallback? Knowing this determines whether a simple engine swap is sufficient or a full scene rebuild is required.
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 08 Jul 2020, 12:07 UTC
One clarification to the answer above: rather than rebuilding the scene by hand after switching engines, the more reliable pattern is to serialize with SceneSerializer.Serialize before disposing the WebGPU engine, then reload via SceneLoader against the new WebGL engine. Live scene objects are engine-agnostic in theory, but their materials and meshes hold references to engine-owned GPU resources, so reusing them directly across engines tends to produce subtle breakage rather than a clean migration.
Two caveats worth flagging:
WebGPUEngine.IsSupportedAsync / CreateAsync in a try/catch, falling back to Engine, is the supported path; mid-session device loss still requires full engine recreation.Behavior here is version-sensitive, so verify against your Babylon.js release by forcing the fallback in a non-WebGPU browser and diffing node counts after reload.