Hi there, I’m currently using the following function setup to load in my models from my cloud provider:
public async loadAsset(modelID) {
SceneLoader.ShowLoadingScreen = false;
const result = await SceneLoader.LoadAssetContainerAsync(
“https://my_glb_file_url/”,
modelID, //name of model + “glb”
this._scene
);
The model is about 73MB and ~200,000 poly.
The resulting load time I measured at over a minute. (about 100 loops of the loading spinner UI).
This is pretty long and kind of a turn off for users. Are there any best practices to speed up load times of content hosted on/returned via cloud providers/CDNs?
yeah I’ll try to add one as soon as I can. The wait time on my local machine for the load is vastly faster than loading it over a CDN. So it’s most likely not a code issue. It seems to be the loadAssetContainerAsync function that’s just taking a while to load it. I’ll try the draco compression and texture compression, as suggested.
Quoting the poly count in relation to the file size while being a contributing factor, is not really the cause of massive file sizes generally. For example a recent .fbx model I exported with ~700k poly was only ~20mb , which roughly means a 200k one could have been ~5MB. Mostly it is always textures that push up file size.
I dont know much of.ktx , but I normally use jpg to reduce load times. (except normal maps , jpg does not work well for this in babylon and other real time renders , produces blocky artifacts ) Let those with more comparative knowledge chime in here
That said, a jpg does not always win vs png. A texture with two tone colors like a clipping mask or text decal can actually be smaller in file size than a jpg
Also be clever with repeating patterns. If you can use a smaller tileable texture and just scale the UV it can create huge savings on texture size. eg a 4K image vs a 64px image.
If a surface is not very important in the scene , either because of subtle textures or objects that are not going to ever get close to the camera, reduce the texture dimensions or even drop some channels, eg a subtle roughness texture could just be a uniform roughness value here instead of a texture.
reuse textures where possible , many times optimization can be achieved in this manner using multiple uv channels on an object.
So that is some things to think about with texturing.
For the model , does everything in the .glb display all at once? if so nothing you can do there. If not and you are hiding showing things , then you should look at splitting the model up and only loading those meshes on request.
@shaderbytes I assume here that we are in normal development environment, with no bandwidth problems
From my experience some cloud providers are actually very slow (or sometimes they have good download speed only for some countries, for example).
In the last project which I was involved in we changed 3 providers in USA before we were satisfied with results.
If somebody wants to test - here is the PG with 129 Mb draft model hosted at Dropbox. In my current environment I couldn’t get more than 19-20 seconds, usually around 15 seconds load time (see console) - https://playground.babylonjs.com/#0JC454#10
google speed test says im at : 53.0 Mbps download , which is my average speed i get currently. So worse than you and that is my normal. Even so , I sometimes deal with American clients who dont even have as fast internet as me. Of coarse I know some clients have blazing fast connections as well , hence why I mentioned you cant just state a result as “normal” or shared because that is too subjective.
( ps… they just laid fiber in my town a month ago , so im looking forward to that getting up and running as I might be able to get 100 Mbps with that , yay )
so I figured I’d drop in a PG to show you the kind of typical model I’m working with and how long it takes to load from our CDN. I don’t think we’ve implemented Draco compression yet. But have a look and please let me know any thoughts you have about it. This one is 77.0MB.
it took roughly 20 seconds for me. which is consistent to the speed it took for labris 129mb model based on the size difference.
Anyway , a scene can be made to look really good with smaller textures/ different compression. This is the most common error artists make with real time web targeted 3D. Textures are almost always the culprit and in most all cases they are over kill sizes and lossless png compression and could have had jpg’s instead.
im sure labris model suffers from texture bloat as well because I really cant see anything in his scene that warrants that sort of file size ( i know its just a sample , was just pointing it out )
You can look at my current project i showed a demo of in here :
the total size of every .GLB that loads in the scene is 15mb ( not all at once , lazy loads based on selections ) , ok it is a small scene but that is just geometry … most loaded textures are optimized to use jpg and as can be seen in the screenshots, they still look great.
This draft model is OK with texturing (we did texturing specially for Babylon) but it really suffers from the excess polygons. The original 3D files (computer cases, mouses, tables) were in STP format, highly detailed (also a lot of invisible details inside) and with no textures. For example, the simple GLB export from STP file for this mouse was more than 30 Mb in size, so our task was first to reduce polygons - so for the mouse it is now less than 2 Mb with textures (https://playground.babylonjs.com/#UKNERM#300).
yeah i know I mentioned it is normally not the biggest issue compared to textures but in parametric model exports geometry bloat can add up and as you said , such models then need to be optimized for real time display. I have had to do that many times myself , I hate parametric model exports haha
Speaking about texturing I have to say that for many cases it is enough just to use properly tuned PBR materials instead of textures, and it saves a lot of space.
yes you will see I mentioned this to the OP up above. For example in my scene , the tubs dont use any textures. Sure it would look more real with some sort of subtle roughness variations , but such visuals are not worth the trade off of loading times.
You will also notice the books in my scene have very low res textures as well , this I also mentioned to the OP, as I dont expect them to really ever be focused upon up close so it was another trade off for faster loading etc.
Such decisions always have to be made when working with online 3D apps.
