SceneSerializer vs SceneLoader: Verifying Restored Babylon.js Scenes

Direct Answer

Functional equivalence after Babylon.js scene serialization is limited to the static scene graph: mesh hierarchy, transforms, materials, lights, and cameras. Runtime state such as physics impulses, animation progress, particle emissions, and custom script variables is not serialized and cannot be verified.

Confirmed Facts

• Serialization captures meshes, lights, cameras, materials, and their basic properties.
• Physics imposters, animation progress, particle system emissions, and custom script variables are omitted.
• Some dynamically created node materials and post‑process chains may not round‑trip, causing silent differences.
• The .babylon file includes a version field; loading with an older engine can trigger warnings or drop unknown properties.

Steps to Verify Restored Scene

1. Serialize the original scene: const originalJson = BABYLON.SceneSerializer.Serialize(scene);
2. Load that JSON into a fresh engine instance using BABYLON.SceneLoader.Load or ImportMesh.
3. Serialize the restored scene: const restoredJson = BABYLON.SceneSerializer.Serialize(restoredScene);
4. Normalize both JSON objects by removing volatile keys: uniqueId, version, timestamp, and any auto‑generated GUIDs.
5. Perform a deep equality check (e.g., JSON.stringify with sorted keys or a library like fast‑deep‑equal). Log any mismatched paths.
6. Optionally compute a SHA‑256 hash of the normalized strings; matching hashes confirm structural equivalence.
7. During load, listen to SceneLoader.OnPluginActivatedObservable to capture warnings about unknown properties—these indicate version drift or unsupported features.

Version Drift Mitigation

• Pin the exact same @babylonjs/core version for authoring and runtime; record it in your asset pipeline.
• Read the version field from the loaded .babylon JSON and compare it to BABYLON.Engine.Version; warn or abort if the loader version is older.
• Include a CI step that serializes a representative scene with the current version and loads it with the previous two minor versions to catch regressions.
• For node materials and post‑process chains that may not round‑trip, keep the original .babylon file as source of truth and re‑initialize those assets in code after load.

One Diagnostic Detail Needed

Does your pipeline use dynamically created NodeMaterials or PostProcess chains that are assembled at runtime rather than authored in the editor? If yes, these will not round‑trip through .babylon and require a separate re‑initialization step after load, changing the verification scope from pure JSON comparison to a hybrid of static data plus runtime reconstruction.