-
Notifications
You must be signed in to change notification settings - Fork 301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Granular progress tracking ? #906
Comments
For a few reasons I don't think this is going to get you the load detail you want. For one it wouldn't include the download time or time that an item is queued. The time from the beginning to end of I think using the lru cache, download, and parse queue fields can be used to calculate the load percent, though: const loading =
downloadQueue.itemList.length + downloadQueue.currJobs +
parseQueue.itemList.length + parseQueue.currJobs;
// or
const loading = stats.downloading + stats.parsing;
const percent = 1.0 - ( loading / lruCache.itemList.length );
console.log( `Percent loaded: ${ 100 * percent }%` );
This will still result in cases where the load percent will reach 100 (or near 100) and then jump back down to a low percent again even when not moving the camera since not all tiles-to-be-loaded are immediately added to the queue / cache. |
@gkjohnson Thanks! I will have a look at your suggestion. Note however that we have a problem since we share the queues and cache between renderers, so this would prevent computing per-tileset progress. |
Another issue: the ratio between downloading+parsing tiles over cache item list tends to asymptotically go to 1, which in turn will make the progress oscillate between 99% and 100% without moving on the whole 0-100% interval. To solve this issue, we have a utility class in Giro3D called |
Maybe we can keep track of the number of tiles added to the cache in the "stats" field, as well. So calculating progress will look like so:
To be clear there already are tiles-load-start and tiles-load-end that fire when loads start while nothing is loading or when the last tile geometry has finished parsing. Either of these could be used as indicators that a loading should be "reset". I suppose you'd still need to know when "new" items are added into the cache.
I'm assuming you mean a |
Yes exactly. We could have LRU Cache events so that we can create a new batch of "new items", then compare that to the downloading+parsing count. Or maybe we could leverage the |
#915 has added support for tracking per-tilesrenderer tile-in-cache count (as suggested in #906 (comment)) but I'll have to think through how to cleanly support "reseting" the load counter once it has reached 100% as you're suggesting. I think it's a good use case to support but I'd like to avoid littering the code with more events for just this use case and the user having to track that data themselves. Options
|
Is your feature request related to a problem? Please describe.
In Giro3D, we have an API to query the "percentage of progress" of a given object. The exact semantics depend on the object itself. For example, in the case of a tiled image layer, the progress is the number of downloaded tiles over the total amount of visible tiles.
To implement such an API for 3D Tiles-based entities, we need to know the "amount of total work" versus the "amount of work already done".
Describe the solution you'd like
For the
TilesRenderer
, this could be an API (typically an event) to know when the loading of a tile starts and an event to know when the loading has finished (this event already exists,load-model
).The simplest implementation would simply add the
load-model-start
event that would be raised at the very beginning ofparseTile()
.Describe alternatives you've considered
I tried dabbling with the
.stats
property, but it does not provide the information I need.The text was updated successfully, but these errors were encountered: