Delay loading screen while streaming in data

[dred]

Before 2.6  we used to check FileSystem::get()->getNumQueuedResources() during start up and wait until we saw 0s for a few ticks and would drop our loading screen.  during the upgrade to 2.6.1 I Changed the call to AsyncQueue::get->getNumQueuedResources().  Unfortunately this appears to not work the same way, It is always returning 0 and our loading screen drops way too early while stuff is still loading in.  any suggestions on how to wait until all the data is load in now?

[morbid]

Hello, dred!

We need some time to investigate this.

I'll write you right after our developers will give feedback on this issue.

Sorry for inconvenience caused.

[dred]

Hey,

Just curious if there has been any update on this yet? It would be good to know if its working as intended and I'm using it wrong, or if there is a possible fix, or even a workaround that can get me what i need.

[silent]

Dred,

Sorry for the late reply. Could you please send us some example code that you are using in your project? That will help us to identify the issue. After that we can give you more detailed answer.

Thanks!

[dred]

Silent,

 

the bulk of the code looks like this

int AppWorldLogic::update() {
	if (worldLoaded)
		return 1;
	else
	{
		//Unigine::Log::message("detecting %i resources left to load\n", Unigine::AsyncQueue::get()->getNumQueuedResources());
		if (Unigine::AsyncQueue::get()->getNumQueuedResources() == 0)
		{
			int target = 50 ;
			if (target > 0 && m_contentLoadCount > target)
				worldLoaded = true;
			else
				m_contentLoadCount++;
		}
		else
			m_contentLoadCount = 0;
	}

	return 1;
}

it basically waits for 50 ticks in a row where something isn't being loaded.  this worked well in the past but now getNumQueuedResources just returns 0 every tick.

 

I put this code into the oil refinery demo and it behaved the same way.  it doesn't seam to recognize things getting loaded via the world files.

[silent]

Dred,

Thanks for the code, we successfully reproduced similar behavior on our side. Currently we are not ready to tell if it's bug or intended behavior in 2.6.1.1 SDK, but clearly there is a room for improvement. We didn't find also any reliable workaround to this yet.

Right now we are in research phase and there is a possibility that we introduce some additional methods in 2.7 SDK for more convenient way of scene loading indication.

Btw, if you can provide us a screenshot  with show_profiler 2 enabled right after the splash screen is disappeared - it will be great addition to the already collected info (just to know how many meshes and textures are loaded) and if you can capture a short video what happens after splash is disabled in 2.x and 2.6.1.1 it will also help a lot.

Thanks!

[jsebens]

The timing proposed (2.7 at the earliest) is problematic for us. 2.7 will not be available in time for our next release. Also, updating the projects is always expensive for us.

Having a working loading screen is very important to the user experience. Could you provide us with a code diff as soon as a solution is identified?

[dred]

here is the profiler, the big spike is when the loading screen goes down, at the very far right is the start of a second large spike.  in 2.2/2.4 there were spikes but they were hidden behind our second loading screen.  I'll work on getting videos but they might take a bit.

[silent]

Dred,

Is there any objects / textures missing on a screenshot? As a small workaround, probably, you can monitor the Allocations number from profiler and when it will drop to the normal values you can disable splash.

Thanks!

[dred]

I'll give that a try, the other idea we were toying with was checking the fps and keeping the screen up while until it goes above 5-10 for a couple seconds.  For the most part on our development computers it stays pretty low when its loading up.  Its hard to say how that will work on all of the user rigs though.  Allocations would be more consistent.

How do I check that value? I assuming its safe to check when the profiler isn't visible?

 

Just thought about it, and we do have different aircraft and airports that can be loaded in and each one might be slightly different, we would have to get the allocation numbers for each aircraft and airport combination and check against that.   And it means any time we change anything in the scene we have the regrab numbers.

Edited March 1, 2018 by dred

[silent]

Dred,

In 2.7 SDK update we will add new method getNumLoadedResources() to AsyncQueue (yay, more methods!) that will show number or loaded resources, but not added into the world.

For example, you have 4 queued resources and you want to see if it's now safe to remove splash:

| getNumQueuedResources | getNumLoadedResources |
|            4          |           0           |
//loading begins:
|            3          |           1           |
|            2          |           2           |
// resources added to the world:
|            2          |           0           |
|            1          |           1           |
|            0          |           2           |
//everything is loaded:
|            0          |           0           |

The only thing is that getNumLoadedResources() can sometimes show non-zero values - it's totally normal and if you see that number is no changed for a while and there is no queued resources - it's now safe to remove splash :)

Thanks!