Hey everyone. So I’ve tried looking this up on google, but the answers didn’t clear my doubt.
I’ve been wondering, what could cause a scene to load slow?
I understand that the reasons may be many, but if I could just get a few reasons, I can do research on them and then hopefully other reasons will make more sense to me.
I’ve been trying to create a really “heavy” scene, hoping that when I use,
AsyncOperatio ao;
void Update()
{
if(Input.GetKeyDown(KeyCode.Space))
{
ao = SceneManager.LoadLevelAsync(1);
}
if(ao != null)
{
Debug.Log(ao.progress);
}
}
I will be able to see a difference in the progress.
So far I’ve added three 2048x2048 textures to 3 separate materials which have been applied the 500+ GameObjects in the scene. The scene has 2.7k Active Rigidbodies. I also imported a high-poly model and made a couple of duplicates in the scene.
Yet, when I check ‘ao.progress’, it is 0 in one frame, and 0.9 in the next frame.
You’re basically solving a problem that hasn’t happened in your game yet. Sure the kitchen sink will fit in the station wagon for your road trip, but do you need the kitchen sink?
EDIT:
Build your game. Don’t worry about performance until you see that it’s a problem. Profile your game to investigate and identify what is actually slowing it down. Propose possible solutions doing your best to compromise the design the least or work around the problem. Implement chosen solution. Rinse repeat.
Sorry, I should have been clear about what it is that I’m trying to do. So, I’m trying to create a progress bar. A lot of progress bars run on fake timing. Since I can actually get the progress of the level load, I wanna create a progress bar that updates as the level loads, and hence, show real progress instead of progress based on fake timing.
But a simple scene with a Plane, a Cube and a MainCamera is not gonna take time to load. So I’m trying to set up a scene that would actually take time to load, even if it’s just a few seconds, so that I can see that progress in my progress bar. To see the progress I’m using AsyncOperation.progress.
This is the code:
AsyncOperation ao;
void Update()
{
if(Input.GetKeyDown(KeyCode.Space))
{
ao = SceneManager.LoadSceneAsync(1, LoadSceneMode.Additive); // This loads Level 2, the heavy scene
Debug.Break();
}
if(ao != null)
{
Debug.Log(ao.progress);
}
}
When in Level 1, if the user presses the Spacebar, SceneManager.LoadLevelAsync(1, LoadSceneMode.Additive) is called to load Level 2, and the game is paused, at which point I go frame by frame, so I can see the progress value in the Console.
But every time, it starts at 0, next frame 0.9, next frame 1.
So, I’m trying to set up Level 2 in such a way that loading it takes some time. Silly as it may sound, I’m trying to create a level that loads terribly slow. But I’m not able to do that.
That is why I’m trying to understand what causes a level to load slow.
Ah, that does add some valuable context to what you are doing.
Unfortunately, it still depends on what your game consists of. What if you estimate a large number of textures, and you end up with just a small amount of texture space? You’d end up with the same predicament. I think it’d be best to again, finish the game, profile the different sections of the load sequence, and then add progress messages accordingly. The profile part is essential. You’ll be able to simply set up timers for each section of the load sequence, and then divide the progress work accordingly, without relying on any guesswork. I still think what you are trying to do is just time wasted that you can otherwise be spent making your awesome game. =).
EDIT:
I’ll try to provide a more concrete example. Suppose you implemented these super-great AI algorithms for your bots, NPCs, whatever. Eventually, you have a crapload of these NPCs, and you realize that the algorithms are taking up too much run-time when you are actually playing the game to compute. So, to save on frame rate, you investigate that your algorithms are computing these tables of data that you can actually precompute in the load sequence. That’s essentially offloading the run-time into load time. But, once, it took 0.003ms to load at loadtime, the precomputed tables will now take 2.5s to load. You see, you wouldn’t have been able to discover this before your game was actually built. You had to build the game, play the game, to find out that you had this problem that needs to be optimized and will thereby affect your loading progress bar. So, it’s no wonder why progress bar loads are inaccurate all across any form of software…
This is just one example. Can you imagine how many other game systems undergo this optimization process? Other AI algorithms in use? Graphics? Physics? UI? Networking? Choose any other aspect of game development?..
EDIT 2:
Also, I don’t think inaccurate reporting of a loading progress bar has ever become a make-or-break feature of a game. In fact, it’s been somewhat ridiculed with joke lines, partially because of the very reason that you are having difficulty with right now.
That example definitely helped! Thanks @aer0ace !