Skip to content
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

Refresh tileset should not re-download tile data #650

Open
r-veenstra opened this issue Jan 30, 2024 · 4 comments
Open

Refresh tileset should not re-download tile data #650

r-veenstra opened this issue Jan 30, 2024 · 4 comments
Assignees

Comments

@r-veenstra
Copy link
Contributor

Unsure if this is by design, however it is different to Cesium for Unreal at least.

When I click "Refresh Tileset" in a tilesets properties, this appears to trigger a full re-download of the tiles. In some cases (particularly Google Photorealistic 3D tiles) this could be ~100mb of data over my network for a simple view.

image

Cesium for Unreal for comparison does not appear to be downloading data over my network when refreshing.

Given Refresh Tileset is often used when working with custom materials, PolygonRasterOverlays, and other workflows it would be ideal if it reloaded the cached data from disk. This should improve refresh time substantially.

I have also verified my tileset cache is sufficiently large (bumped to 53687091200)

Data downloaded after a single click on Refresh Tileset
image

Data downloaded after a second click on Refresh Tileset
image

Unreal does not change here, and it also is significantly faster when a refresh is performed.

Local caching does appear to be working in OV when simply jumping the camera location from one place to another, and back again, as I don't get any data download then. Just when clicking Refresh.

@lilleyse
Copy link
Contributor

@timoore could you take a look at this?

@timoore timoore self-assigned this Jan 30, 2024
@timoore
Copy link
Contributor

timoore commented Jan 30, 2024

Cesium-Unreal is using CesiumAsync::CachingAssetAccessor, which delegates to the accessor class making the http requests. In cesium-unreal, that eventually calls Unreal's code for making http requests. cesium-omniverse isn't doing any accessor-level caching, as far as I can tell. I've used CachingAssetAccessor in vsgCS with UrlAssetAccessor and it works, although I don't provide any user interface to cache size. I think the caching @r-veenstra is seeing when changing location is the result of the cesium-native tile selection algorithm, which doesn't unload tiles immediately that are out of view.

I think it's best to get #634 merged before adding the CachingAssetAccessor to cesium-omniverse.

@timoore
Copy link
Contributor

timoore commented Jan 31, 2024

@r-veenstra What is the UI in cesium-unreal for the cache file and its maximum number of items?

Should these parameters be stored in Usd like the other tileset parameters? Probably, I would guess.

@r-veenstra
Copy link
Contributor Author

@timoore in Unreal these are stored in the Plugins - Cesium section of an Unreal Projects Settings.

image

As far as I'm aware there isn't an ability to specify a cache location on disk. On Windows it's naturally stored in C:\Users\Username\AppData\Local\UnrealEngine\5.3, where there is a single SQLite DB that appears to be shared across any Unreal Engine 5.3 project (at least when using via the editor - unsure what happens with built projects). If you have additional versions of Unreal Engine installed, they have their own caches.

We don't really have the concept of a "Project" in Omniverse, so the scenario is a little different.

It's probably worth a discussion to determine if this should be a per USD setting vs an OV application or extension specific setting. My initial thoughts are one of the latter options, given if I'm changing my cache size settings, it's probably unique to my system?

USD Composer has a number of similar settings in Edit > Preferences, which don't appear to be saved with a USD.

image

image

I wonder if we can do something similar?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants