Basically, yes 
Drawcalls are minimal.
1 Like
@labris @preact/signals - I am huge fan of this stuff! 
2 Likes
I hope you’ll like it too - Outline for GLB thin instances - Thin Instance Outline Gallery
The outline renderer uses one compact thin-instance draw per attached host and stores only highlighted IDs. Use createThinInstanceOutliner for ordinary meshes or raw Babylon Lite thin-instance indices. A host with a live Babylon Lite skeleton automatically shares its joint/weight streams with the outline and mirrors current bone matrices each frame.
The original idea for this outline feature came from increasinglyHuman/babylon-thin-instance-outline for Babylon.js. This package implements the approach natively for Babylon Lite and adds its own stable-ID, compact-pool, and live-skeleton workflows.
1 Like
Very very cool!
I wish I could switch entirely to WebGPU/Babylon Lite with my Digital Twin implementation, but support on iPhones requires the newest MacOS 26 (not just an updated browser) so unfortunately this would not happen anytime soon.
@roland Specially for you
Instancer for Babylon.js - https://www.npmjs.com/package/@litools/instancer-babylonjs
npm i @litools/instancer-babylonjs
3 Likes
Updated to Lite 1.31 with all breaking changes
Thanks! Can you also update @litools/instancer peer dependency in babylon-lite-explorer?
Done.
2 Likes
I need to start getting my hands on Babylon Lite and try instancer
1 Like
This is so good!
1 Like
Ag
Agreed. 
One thing makes me nervous though. I really appreciate lite’s clean design and commitment to allowing breaking changes when that’s best for the library’s goals. However, I’m quickly becoming dependent on add-on libraries like @litools/instancer, babylon-lite-explorer, and @litools/annotator. I don’t believe they are currently released in a coordinated way with breaking changes to lite.
Is there a path to having a set of “approved” libraries which are updated and re-released within some time horizon of a breaking lite release? Maybe 1-2 weeks? (Look at me volunteering other people’s time! Go me. 
)
My alternate approach would be to build in the parts of these libraries that I need, so I’m not dependent on the libraries themselves (or maintaining my own forked versions with patches). This path is consistent with lite’s philosophy of “build what you need”, so I wouldn’t be too disappointed.
1 Like
PRs are always welcome! 
1 Like
I don’t use lite at the moment (but I’d love to), due to WebGL2 compat requirements. The problem I think with maintaining our own solutions would be that we’d still need to maintain them as Lite udpates with breaking changes, at that point PR’s to the current solution seem more practical.
I hear your pain, but can’t think of another solution lol
1 Like
I actually did send a PR, and it got missed. It didn’t bother escalating because I was able to just use my own fork in the meantime. So, maybe part of the solution is just to ensure there’s someone on the other end listening for PRs.
Seems I completely missed your PR
Wrapping thin-instance matrix buffers behind an object-oriented proxy that supports per-instance raycasting, bounding-box queries, and visibility toggling solves one of the biggest headaches when rendering large mechanical CAD assemblies in Babylon.js!
When we load multi-thousand-part ISO 10303-21 STEP assemblies (NEXT_ASSEMBLY_USAGE_OCCURRENCE trees) where fasteners, bearings, and brackets repeat hundreds of times, converting repeated B-Rep solids into thin instances cuts draw calls from 4,500+ down to under 80 while keeping individual part picking responsive. Before tessellating and instancing those assemblies, we also parse the STEP header and instance tree using a client-side ISO 10303 STEP File Header & Assembly Parser so identical geometry definitions share a single base Mesh buffer from the start.