You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, some edits to raster overlays, cartographic polygons, etc, can result in a cascade of overloads. Starting from a product level, we should revisit the UX/UI with an eye out for the following:
Avoiding tileset reloads
Avoiding unused data request to external data sources
If and when a user should request tileset and raster-overlay refreshes
Potential debouncing techniques
Cesium for Unreal currently has some different approaches than Cesium for Omniverse. Listing these differences and deciding if they should be adopted provides a starting point.
The text was updated successfully, but these errors were encountered:
One idea for cutting down on tileset reloads is to hardcode a maximum number of raster overlays per tile so that the material doesn't need to be recreated each time a new raster overlay is added or removed.
I also wonder how feasible it is to add the visibility-toggle eye icon that USD prims have for each raster overlay. Changes to non-visible raster overlays could be batched until visible. Aside from being a way to disable reload, it also might make data exploration like comparison between raster-overlay datasets easier.
Currently, some edits to raster overlays, cartographic polygons, etc, can result in a cascade of overloads. Starting from a product level, we should revisit the UX/UI with an eye out for the following:
Cesium for Unreal currently has some different approaches than Cesium for Omniverse. Listing these differences and deciding if they should be adopted provides a starting point.
The text was updated successfully, but these errors were encountered: