search

3DBAG / 3dbag-viewer

https://3dbag.nl
GNU General Public License v3.0
34 stars 10 forks source link

Improve performance for very big (national) tilesets #10

Closed Ylannl closed 3 years ago

Ylannl commented 4 years ago

The performance is currently not very good with very big tilesets, eg the national one with 80k tiles. I believe it has to do with our current tiling hierarchy and some parts of the code that traverse the whole tileset for each frame. For example the update function of the WMS/terrain renderer.

Some possible ways to improve that I can think of:

  1. Tighter integration of WMS renderer with the 3Dtiles renderer. Eg have callback when tiles are made visible/invisible that load/unload the correspending WMS tile. This would eliminate the need for a loop over all the tiles inside the update function of the WMS renderer.

  2. A different tiling scheme. As far as I understand we are currently using a rather flat scheme. I can imagine It may help to have a quadtree like hierarchy of tiles (that are empty except at the leaves). This would make it easy to quickly decide not to iterate over big parts of the hierarchy that are not in view. I started working on a python script that creates such a hierarchy from the tileset.json.

  3. Split the tileset.json over several smaller json files. The current tileset is rather big (30MB). This would however only impact the initial loading time not the rendering performance.

Ylannl commented 3 years ago

I have made a few more observations regarding the performance (ie framerate during camera movement):

  1. disabling anti-aliasing make a huge difference is responsiveness on my desktop computer with a high DPI screen (perhaps we should only enable AA on low DPI screens?)
  2. On mobile devices (tested on iOS iphone/ipad) occasionally a page reload is forced by the browser. Probably because too many resources (memory?) are used?
  3. The difference in performance between the national dataset (~1 FPS) and the one of just zuid holland (high FPS, very smooth) is huge on my ipad.
liberostelios commented 3 years ago 
1. disabling anti-aliasing make a huge difference is responsiveness on my desktop computer with a high DPI screen (perhaps we should only enable AA on low DPI screens?)

That's interesting. We could have an option for that and then find a way to set it automatically from the DPI.

2. On mobile devices (tested on iOS iphone/ipad) occasionally a page reload is forced by the browser. Probably because too many resources (memory?) are used?
3. The difference in performance between the national dataset (~1 FPS) and the one of just zuid holland (high FPS, very smooth) is huge on my ipad.

I would speculate that these are due to WMS's really ugly implementation. Have you tried what's the case without a WMS?

liberostelios commented 3 years ago

I think with all the improvements we have implemented so far, this can be more or less considered as solved. The only last part left if probably to make the initial downloading of tileset.json faster (either through gzip or by dividing it to smaller parts).

Ylannl commented 3 years ago

Currently the biggest issue is the size of the b3dm tiles. Big tiles take a long time to download and parse. This can cause frame-drops in the viewer. This basically point 3 of the first post in this thread. We could solve this issue by using the tiling scheme that we also use for processing (it was designed to have approximately 3000 buildings in each tile). This would both reduce the total number of tiles as the maximum filesize for one tile by an order of magnitude.

It would probably require significant work on the pg2b3dm exporter that we use. In addition the script that we use to build the quadtree tileset would need to be changed (we should probably look a that together with the script to generate the processing tiles).

Ylannl commented 3 years ago

Currently the biggest issue is the size of the b3dm tiles. Big tiles take a long time to download and parse. This can cause frame-drops in the viewer. This basically point 3 of the first post in this thread. We could solve this issue by using the tiling scheme that we also use for processing (it was designed to have approximately 3000 buildings in each tile). This would both reduce the total number of tiles as the maximum filesize for one tile by an order of magnitude.

It would probably require significant work on the pg2b3dm exporter that we use. In addition the script that we use to build the quadtree tileset would need to be changed (we should probably look a that together with the script to generate the processing tiles).

This has been implemted now (thanks @jliempt !).