I am being tasked to make a large scene load faster by tomorrow.
It is a single .babylon file with embedded textures, totaling roughly 23MB, hosted on Azure CDN. It is used in an web app, and mobile users are the priority target.
My tracks so far:
- delete redundant texture data present in both ‘url’ and ‘base64String’ parameters,
- enable server-side compression for .babylon files,
- downgrade texture quality for most (if not all) textures to the next mipmaps level,
- further eliminate redundant data that results from the fact that several texture channels use the same picture, i.e. store the same, large inlined data.
Some thoughts / questions regarding the above:
- regarding 1: @aWeirdo wrote that on load, if base64string exists, url is ignored. I intend to just try deleting data and see what happens, but any insight is welcome
In particular, I’m curious why this data gets duplicated in the first place. - regarding 2: gzip, not surprisingly, does a great job at compressing the redundant data, and will probably still be helpful after removing the waste. Just need to figure out how to enable compression on Azure. Do you see any reason why I should stay away from server-side compression in my scenario?
- regarding 3: I’ve tried doing this in the Sandbox so far, but I hit a bug (reported here). That’s a nice option to have in the sandbox, but I have several dozens of textures to deal with, so ideally I’d like to have a few more options. If not for this project, for the next. Like batching quality downgrade operations. If you are aware of some script that already does something like that somewhere, I’ll take it. And if learning how to use Blender is the answer, well… I guess I’ll accept that as well
- regarding 4: most materials in the model have an Albedo and an Emissive texture channels which contain the same inlined data. Is there a way to share inlined data between textures instead? Or is it just better to split the scene into one .babylon file containing references to a bunch of image files loaded separately?
Long term I’ll have a closer look at glTF, Draco, KTX…
But let’s start here!