Also curious on the right handedness, since that is once again something that I use 
1 Like
Right-handedness is just a preference, not a showstopper for me. I’d rather a lean, fast engine than support for every use case 
1 Like
Yeah, same! Just poking to know how much I have to refactor 
1 Like
Babylon Lite seems to be a separate codebase from Babylon.js, and from a quick look, it feels like a fairly direct, agent-assisted rewrite of the class-based Babylon.js structure into interfaces and standalone functions.
For engine-level fixes or new rendering features, should contributors still target Babylon.js directly?
Or is the expectation that some work should happen in Babylon Lite first and then be ported back to Babylon.js?
I’m mostly trying to understand how Babylon Lite should be treated as a Babylon.js contributor.
2 Likes
There will be no RH. Again, same reason: that requires the engine to have bazillion of code to support both case. Lite is fast for a reason:)
3 Likes
For GL: there is absolutely no promise. We believe this should not be necessary but @sebavan is evaluating a minimal version just in case
2 Likes
We want to support both. But we do not put that burden on the contributors. If you want to only focus on one of the engines no problem. If the feature is important we will port it to the other one
1 Like
Yes a live list of features is coming.
For the agent we built the porting guide. Not an mcp or even a skill but a clear doc. I tested it and it worked well to automate porting
1 Like
Understandable!
Do you have any mechanism to convert gltf/glb models to left handed, or is it a manual process? I moved to right handedness back in the day to not have to do -1 scaling magic on every import… Or at least I remember that ir the case with gltf models?
that’s what we do, we add a negative -1 on x scale for gltf objects. so they are left handed from the get go
1 Like
If you have specific API question or asks, please start a dedicated post :slight_smile
It will help us making sure we are not missing something
So I’m at my desk so I can give you a better answer
1. Clone a mesh / transform hierarchy
Use cloneTransformNode(root) , not structuredClone(mesh) .
const assets = await loadGltf(engine, "props.glb");
const root = assets.entities[0] as TransformNode;
const copy = cloneTransformNode(root);
copy.position.set(10, 0, 0);
addToScene(scene, copy);
structuredClone() is the wrong contract: Lite objects are plain-ish data, but meshes/materials/textures contain internal GPU handles and dirty-tracked observable transforms. Browser cloning would not rewire those correctly. cloneTransformNode() is the tree-shakeable Lite API; it deep-clones the hierarchy and shares uploaded mesh GPU buffers.
2. Instance a mesh
Yes, in Lite the intended instancing path is thin instances:
setThinInstances(mesh, matrices, count);
setThinInstanceColors(mesh, colors); // optional
setThinInstanceCount(mesh, activeCount); // good for pooling
Classic Babylon InstancedMesh / parentNode.instantiateHierarchy() is not currently the Lite model. If the copies need independent materials, animation state, child nodes, or arbitrary per-node logic, use cloneTransformNode() . If they are many copies of the same mesh/material, use thin instances.
I will add the following API today so it will be easier for you:
const pool = createHierarchyInstancePool(templateRoot, capacity);
const id = addHierarchyInstance(pool, matrix);
setHierarchyInstanceMatrix(pool, id, matrix);
removeHierarchyInstance(pool, id);
Implementation will be a standalone import-only module that collects descendant meshes and drives thin-instance buffers for each mesh, with no scene-core changes.
3. Load a GLB hidden, then spawn only needed props
loadGltf(engine, url) already uploads mesh/material/texture GPU resources, but nothing renders until addToScene() .
For a hidden library anchor:
const library = await loadGltf(engine, "props.glb");
addToScene(scene, library);
const root = library.entities[0] as TransformNode;
setSubtreeVisible(root, false); // use this, not node.visible = false
Then clone a prop when needed:
const prop = findNode(root, "crate");
const instance = cloneTransformNode(prop);
setSubtreeVisible(instance, true);
instance.position.set(x, y, z);
addToScene(scene, instance);
The new design does not remove the need for bookkeeping. For clone-based props, keep your object pool and hide/reuse with setSubtreeVisible() . Do not use removeFromScene() as a pool operation; it is disposal and destroys GPU resources. For thin instances, your pool becomes matrix-slot bookkeeping plus setThinInstanceCount() .
cc @PirateJC for the need of a doc here 
2 Likes
Sweeeet
Can’t wait to try it (once I am done migrating to the “old” WebGPU Babylonjs, that is)! Thanks a lot guys!
1 Like
Love or live? So sad you fixed that typo
Yeah a proper brief is good enough. Is it share yet?
1 Like
@PirateJC is on it
1 Like
and here is the new API for your delights:
feat: add hierarchy instance pools by deltakosh · Pull Request #245 · BabylonJS/Babylon-Lite
1 Like
If it doesn’t hinder the Lite engine performance, I would say that GL should be a must. There are many devices that don’t run WebGPU, such as most linux devices by default. For my personal opinion, developing for only a subset of devices is a no-go. I understand that the engine is a fantastic solution for many people even with just WebGPU compatibility, just not for me. I do have to say that the rework looks amazing and I appreciate and respect all the hard work put into it. I’d love to switch to it!
I understand and this is why we will continue supporting and improving babylon.js
Lite is not for everyone. Babylon.js either. But both should cover everyone
1 Like
The webgpu linux support is something as a community we should push on Google!
1 Like
@Deltakosh do you know about wcandillon/react-native-webgpu? It would be great to see Babylon Lite running natively on iOS or Android.
Since the project is still new, adapting the API to run in environments beyond just the web could make a huge difference. In my opinion, Babylon Lite is a perfect fit for mobile because it is very small and has excellent performance.