Hey beloved Babylon.js team!
I’m building this game: Out 4 Blood
The scenes in this game are using binary geometries (.babylonbinarymeshdata files which are less heavy than JSON descriptions for geometries) and most of the meshes have LODs set to them. In other words, each geometry has its associated .babylonbinarymeshdata file. Because there are a lot of different geometries, the client has to load up to +1000 .babylonbinarymeshdata files which takes too much time and is a bit heavy.
I decided to pack all the geometries into a single .babylonbinarymeshdata file (and updating _binaryInfo object of each serialized mesh) which will be re-used by all geometries at runtime when parsing the meshes (using the Babylon.js file loader plugin). and it reduced so much the loading time compared to sending +1000 GET requests.
The problem here is that all geometries, while being parsed, register a new pending data for the .babylonbinarymeshdata so the same file is loaded multiple times.
Playground repro: https://playground.babylonjs.com/#WGZLGJ#11462
In this playground you can open the devtools and see that the same .babylonbinarymeshdata is loaded multiple times. The expected behavior would be that the geometry loader detects it’s already loading the file and should wait for the loading process to finish and use the same buffer as input for the geometry data.
I hesitated to post in feature request, but finally it looks more like a bug than a feature request.
Let me know if you have any question or if you want to discuss this behavior.
Thanks a lot 
@georgie I see the PR 
For the cross-origin issue you can serve on port 3000 or give me your port and I’ll authorize it if you want
@julien-moreau that’s okay i can verify using the PR playground link! take a look and confirm this fixes 
glTF Loader Demo | Babylon.js Playground
Thanks a lot!! That’s almost perfect!!
I updated the playground to re-scale it: https://playground.babylonjs.com/?snapshot=refs/pull/18570/merge#WGZLGJ#11463
If you increase the radius of the camera, it triggers new LODs which are loaded on the fly. This triggers new HTTP requests to load the heavy .babylonbinarymeshdata. That’s a problem because it would mean that you have to store the .babylonbinarymeshdata file in-memory until ALL LODs are triggered 
I have no idea for instance how to solve it but we can discuss it
On my case it’ll work because I preload all meshes (LODs included) so the .babylonbinarymeshdata file is loaded once. But for other users this might cause networking and performance issue at runtime
We can discuss it if you have any insight
Yes the PR is checked in now, will be released later this week. Glad it fixes your issue!
Coalesce shared delay-loaded geometry/mesh file requests by georginahalpern · Pull Request #18570 · BabylonJS/Babylon.js
Regarding your second finding: The PR coalesces requests that are in-flight at the same time — which is your preload case (all LODs parse together → one fetch). But as your said, a LOD triggered later, after the initial batch settles, re-fetches the shared file because the in-flight entry is already gone. Solving that means retaining the file in memory, and the engine can’t know when the last LOD will fire — so a naive retain would leak a multi-MB buffer for the whole scene lifetime.
If true in-memory reuse turns out to be needed, the cleanest shape would be an opt-in retained cache: a scene flag to keep delayed files, a manual “clear” once your LODs are loaded, and auto-cleanup on dispose — keeping the memory decision with the app, since only you know when you’re done.
That said, since your own setup (preloading everything) is already covered, I’d lean toward not building this just yet — it adds surface area and a real memory tradeoff, and I’d rather wait until there’s a concrete case that actually hits it. If you (or someone) run into the LOD re-fetch being a genuine pain in practice, let’s revisit 
It’s a good strategy, let’s go for it
Thanks again ! 