Playground: Babylon.js Playground
Version: 7.24.0
Engine: WebGL2
Loading HDRCubeTexture is slow, it takes ~5s for a loading a 1k texture, and takes minutes loading 2k ones. I’ve made some profiling on chrome to see if there are ways to optimize it.
Loading HDR to a 1k texture, ConvertCubeMapToSphericalPolynomial takes the most, ~54% of the cpu time, most of which is calculation, so it could, at least in theory, be possible to be gpu accelerated, via a post process shader in webgl2, or a compute shader in webgpu.
The same thing happen to CreateCubemapTexture, which takes ~30% of the cpu time, seems also could be gpu accelerated.
In case of webgpu, ConvertPanoramaToCubemap took ~27%, and ConvertCubeMapToSphericalPolynomial took 45%.
I don’t know if the solution is going GPU accelerated, but still I upvote this topic, and I’ll follow it.
On my apps, the only thing which can really freeze the main loop if this CubeMap loading.
For example on my Hovercraft game, I manage to load everything smoothly expect the sky texture which freezes the loading for a few seconds each time…
Also, I remember a conversation on the forum about the fact that JS is single threaded, which is the main problem for loading textures without blocking the main event loop… I hope one day we will have a fix for this
For the ConvertPanoramaToCubemap part, seems three.js have a gpu accelerated impl here. It should take at most 6 draw calls and 6 readPixels (or 1 draw call with multirendertarget). Also, since the algorithm of ConvertCubeMapToSphericalPolynomial does not use too much branching, looping, or read-after-write, it could be also rewritten in shaders.
To speedup loading cubemaps, babylon.js’s internal env format could be an option.
It’s very hard to use multiple thread in js, using it would suffer from limitations of browser, or copy the data to and from threads every time data needs to be passed cross thread.
