how to manage the challenge of a large scene size v3d file

Hey Visualizer
Having large scenes is a problem I hope will one day be easier to manage. Until then the limiting factors are always the device or devices you have to make your experience work on.

If you are stuck making this work on a web server you may run into browser memory limitations. Depending on the user, their settings etc. the average advanced desktop browser user tab will handle about 2 GB. Loading more than about 2 GB in a browser is risky at best and just probably wont work in most cases. However, if you throw in mobile and the general population, that limit is drastically reduced…closer to 50 MB. All of the above is not an issue if you are not releasing it online. But since you seem to be you are in a bit of a bind.

We are often faced with large loads in our projects. As KDV stated above, loading with light textures and replacing them after load is an option and a good one if the textures file sizes are significant. We heavily rely on atlas maps to reduce textures count so we have already done the heavily lifting of texture optimization. In cases where we have run into very large bin files that take way to long to load due to geo….we go back into the model and fix the geo. We find we may have to break the experience up a bit to allow us to load the initial portion and then background load the remaining sections.

A great example of this is Pollantor Park: https://ecenvcommpublic.env.dataplatform.tech.ec.europa.eu/pollinators-vr/index.html. No, its not my work but where I got the inspiration on how to address massive assets online.

Often we will play a video while we are loading in additional assets or require the user to do an action like go through a brief navigational tutorial or explore the main product while other stuff loads.

Downloading time is not typically the real issue anymore for 200MB file sizes. It should only take a few seconds for most desktops.
Here is a download time calculator:
https://www.gigacalculator.com/calculators/download-time-calculator.php

The problem we have seen is that the browser just consumes a bunch of time processing during the download. KDV has also mentioned in another thread of just loading a blank scene in first. Then loading in the necessary GLTFs as needed. This will get the user into the app faster and away from the dreaded loading bar as quickly as possible. Once in you can download the next anticipated section or sections. This technique may or may not be useful based on your apps startup needs.

One day it would be great to have a nanite or nano tech similar function for webgl…and once our browsers are multithreaded I think this option will come to us. We are so very limited to what we can do with a single thread.

visualizer wrote:

How do we achieve the loading of a blank or minimal scene at the beginning & then gradually multiple GLTs load in one by one. Is there any puzzle settings or sequences to be set for this?

So what’s the problem? Load your minimal scene and then use the append scene puzzle(s) to load the rest content.

sorry for the late reply, but do you guys also think that lots of materials and shaders can also contribute to large file sizes as well?

Pollinator Park is really a great example! Agreed!!!! but not done in Verge3D.
There are actually great resources online how this application was built and what apps were used to create it. But the scene transitions and loading is very well done.

The environment holds three scenes for lack of a better term….the scene you are in and the one before and the one after….there is not alot of branching going on. There is also a transition area where depending on your internet speed you are in this walkway between rooms…and this is where last minute loading is ocurring. No progress bar…just reduces your speed to get through the hallway.

They also implemented LOD. Something V3D has sort of implemented but not to the level some other game engines use that makes scene loading much faster. The LOD is based on Camera distance and priority. Very cool stuff. Not only does it use LOD for the models but LOD on textures. Gotta love that.

The load unload we currently have does allow us to do just what you would expect…the LOD thing….well…thats another issue. LOD does exist if you want to dive into the JS of it. But nothing in puzzles yet. And what we have in code is well… described here:

https://www.soft8soft.com/docs/api/en/objects/LOD.html#:~:text=for%20common%20properties.-,%23,-.autoUpdate%20%3A