I recall some time ago there was some discussion regarding disk caching for Babylon Native Kinda like browser caching works . Wondering if there has been any traction on that or if its on the roadmap. @sebavan @bghgary . If its not on the roadmap, Id love to know your thoughts on this and if we all agree it would be coo, what would be a realistic ETA ? Since network transition time is our largest bottle neck for our backend rendering which we do via Native and Azure instances, having disk caching would be a huge performance boost especially since for most requests we are using the same assets.
I think we were talking about caching shaders earlier. This request is a bit different. Babylon Native uses the OS APIs to download from HTTP. I would expect the OS to do some caching. Maybe we have to explicitly turn this on. You are running on Windows yes?
Ah yes thats the clarification, this is for assets (models/textures) not shaders. And Correct, we are on windows on an Azure CPU instance. One thing is for sure every time we see a request even for the same asset we are seeing new network traffic, it does not appear to be loading from cache. We were going to come up with our own system of dowloading the files to a local disk cache on the vm and loading from there for subsequent requests but it would be great if this was just part of Native. Kinda like how this works Babylon.js docs
The code for this is here: UrlLib/Source/UrlRequest_Windows_Shared.h at main · BabylonJS/UrlLib (github.com)
It seems like there might be a way to pass a constructor argument (maybe this) to tell this API to use the cache. If you have the bandwidth, you can try changing this to see if it works.
hmm interesting. I’ll look into this. Thanks Gary, we can try to give this a crack but wouldn’t mind if you guys gave it a shot too if it seems to be simple. 
found this. worth a shot.
-Anupam
I don’t have the bandwidth at the moment for new features. If this can wait a month or so, I should be able to do something, but I’m not sure if that timeframe is too slow.
Understood, we will try your suggestions and we can check back later with you on this.
-Anupam
1 Like
@bghgary curious if the ‘Babylon native shader caching’ part of this has had any traction or is on the current roadmap? Looks like BGFX after compiling shaders basically returns a binary which could be saved and read back from disk. Beyond some quick research i haven’t had the bandwidth to experiment with this. There is also the question of when shaders need to be compiled/recompiled and thats a source of confusion for me too.
Anyway, let me know if you have any updates. At asset load, most of our models take about 2000-3000ms to compile materials and I think there is an opportunity here for huge savings if we use disk cache . (again, native only not browser)
This is on the list, but we haven’t had time to look into it.
BGFX doesn’t do the compiling. Babylon Native does it directly through glslang and SPIRV-Cross. It then packages the compiled bits into a format that bgfx can consume. The savings would come mostly from the glslang and SPIRV-Cross parts.
I would guess we would hash the shader string and cache them that way (like a hash map).
At the moment, I don’t have the bandwidth to look at this and is probably true for most of the team. Hopefully that will change in the next month or two. If this isn’t fast enough, maybe we can look into other options.
1 Like
Appreciate the update, at this point we just wanted consensus that there will be a net positive benefit and sounds like there will be. Also thanks for the tip on glslang , I’ll have to look into it if for no other reason but to educate myself of how that pipeline works. Also its helpful to know where your team is at so we can refine our future term roadmap so again, appreciate the quick update. Right now, all we’re looking to do is get at least similar perf to our browser experience on that first frame and I think we’re getting really really close.
I’ll share your update with the team and provide any feedback.
1 Like