Hi all,
I’ve been working on some progress bar functionality for loading/updating some WMS tilesets, and noticed that the ComputeLoadProgress() function often returns 100 before the tiles have fully loaded. Please find some screenshots attached below:
When it returns 100
When it is actually fully loaded (several seconds later)
Am I misunderstanding this behavior? Is there potentially a workaround for this issue? Any and all advice would be greatly appreciated. Thanks!
Hi @alec_zhang1,
That sounds like a bug. Can you help us reproduce it? Does it always happen, or only with particular tilesets or when interacting in particular ways?
In my experience with Google tiles, I’ve had to add a delay of ~400ms before accepting the return value of ComputeLoadProgress() as valid. I had assumed that it takes a moment for Cesium to load enough metadata to know what it doesn’t have.
Did some more testing today and this issue seems to be tied to the WMS Raster Overlay – I’ve been using ComputeLoadProgress() with other global tilesets and it seems to work fine there.
A little more about my set-up: I’m currently pulling this WMS data from a proxy server which passes along the requests (doing this for auth purposes).
The LoadProgress value consistently reaches 100 a couple of seconds ahead of the tileset (seems to depend on network speed or some other latency) when pulling from this server.
I am also updating the WMS overlay URL and layers occasionally, so not sure if that might also be related to this issue.
Hi folks, do you mind giving yesterday’s v1.16.0 release a try to see if you still have this problem? We reworked the progress computation a bit in this release, which may (
) have fixed it for you.
Hey Kevin,
Thanks for the heads up!
Just updated to v1.16.0 and gave it a try, but unfortunately I’m still seeing similar things with the WMS layers 
not sure if there’s something else going on in the back…
I just tried to reproduce this with Cesium World Terrain plus a WMS server, but I wasn’t able to. ComputeLoadProgress only returned 100.0f after both the tileset and the WMS were fully loaded.
Here’s the WMS component I used for testing:
(this WMS has data for Australia)
And here’s the script I used to print the progress:
using UnityEngine;
using CesiumForUnity;
[ExecuteInEditMode]
public class Foo : MonoBehaviour
{
// Start is called before the first frame update
void Start()
{
}
float previous = -1.0f;
// Update is called once per frame
void Update()
{
Cesium3DTileset tileset = this.GetComponent<Cesium3DTileset>();
if (tileset != null)
{
float progress = tileset.ComputeLoadProgress();
if (progress != previous) {
Debug.Log(progress);
previous = progress;
}
}
}
}
Any idea what might be different in your setup?
Did some more testing with a super dumbed-down scene (with just a single tileset and a camera) and I think I may have stumbled on the underlying cause!
Looks like setting a higher Maximum Simultaneous Tile Loads value causes this behavior to occur – when setting it to 20, the progress value had no issues. However, when using higher values (100+), this issue begins to surface.
Not sure if this is intended or if there is a workaround outside of lowering this value, but hopefully this sheds some more light on the situation!
Well, I really wouldn’t advise setting the Maximum Simultaneous Tile Loads to such a large value. But, I tried it and I’m still not able to see a problem with the progress percentage. I tried setting it to 100 on both the Cesium 3D Tileset and on the Cesium Web Map Service Raster Overlay components.
Please share as much information as you possible can, up to and including your actual scene file if possible! The difference could come down to the specific tileset you’re using, or some other setting that isn’t obvious.
Strangely enough, when I tried again today it seemed to be working properly. Maybe there was a Unity bug and the package didn’t update properly?
Thanks again for all of the help – I’ll make sure to let you know if something like this pops up again.