Tile caching tests

[r-veenstra]

Following on from the findings in #650, I performed some additional comparisons for tile loading and caching scenarios between Cesium for Omniverse and Cesium for Unreal

Some of these might not be 1:1 comparisons in terms of behind the scenes activity, but are comparable from a UX point of view at least.

The first loads of Unreal were performed by removing clear cesium-request-cache.sqlite.

Unreal - Google 3D Tiles Manhattan First sesion, first load - 37mb First session, second load - 0mb Second session, first load - 0mb

Unreal - CWT Manhattan First sesion, first load - 10mb First session, second load - 0mb Second session, first load - 0mb

Omniverse - Google 3D Tiles Manhattan First sesion, first load - 130mb First session, second load - 130mb Second session, first load - 130mb

Omniverse - CWT Manhattan First sesion, first load - 35mb First session, second load - 35mb Second session, first load - 35mb

Observations

• Unreal is clearly reloading data from its disk cache on subsequent sessions of the Unreal Editor, this is resulting in fast load times for users
• Omniverse never seems to cache between stage loads or between sessions, resulting in excessive downloads and slow performance
• I'm not entirely sure on the download size differences between OV and Unreal, disregard this for now but I will investigate to see where the discrepancy is (I was using the exact same camera location / fov / screen space error so it should be similar). There is potentially some other setting I'm missing but I'll test separate to this.

[kring]

If you have a high-DPI screen, Cesium for Unreal uses a lower effective resolution for tile selection on Windows only. This is similar to how CesiumJS works, except CesiumJS does it on all platforms because browsers make that easy, while Unreal does not. There's an option to control this per-tileset and also globally in the project settings.