loading large scenes lags the game

[oli-obk]

each of our ca 800m x 800m tiles takes longer than a frame to load.

We need to debug what the bottleneck here is. Likely it's the upload from RAM to the GPU

• [ ] figure out a way to pre-load all textures with a loading bar or sth at the start

  • https://crates.io/crates/bevy_asset_loader should do the trick

• [ ] try out smaller tiles?

• [ ] figure out how to split tiles in the glb loader, so that every frame only uploads a smaller part to the GPU. This would probably look really cool with random parts of the tile showing up quickly after each other.

  • [ ] this will need to dynamically analyze how long it takes and adjust to smaller parts. This is necessary to make sure it runs smoothly on any machine, not just ours.
  • [ ] can we use https://github.com/gltf-rs/gltf to build a splitter?
  • [ ] can we teach https://github.com/asny/three-d-asset to be able to serialize glb/gltf?

• [ ] use https://crates.io/crates/meshopt to preprocess all tiles and thus shrink the meshes

• [ ] osm2world already generates a bunch of glts nodes per scene. It could instead generate a scene per node, so we could load them individually instead of all at once.

• [ ] The Linux application sometimes is so busy loading tiles, not only the control is disabled, also the application menu including closing the app.

• [ ] And other task on the notebook (Mac Air) get ugly slow.

[DerKarlos]

• Yes, we could preload the mostly used textures (each GLB may use different ones)
• I am sure, Tobias will make zoom 16/17 tiles for testing. On his server, we need to discus this.
• I think, a GLB could contain multiple scenes. So we could split a zoom 15 file in 4 or 16 sub tiles, I hope. Random is nice, but I did it controlled by priority :-) Running on ALL devices will be a challenge. We may analyse the type and alternate the rendering.
• I am sure, the meshes are optimised already. Texturemaps are not used yet => Contact Tobias
• Yes, splitting the tile in scenes just do "slowly" load them would be a way. Another one: Ask Bevy glb loader to build in a "slow mode": postpone further node loading to the next frame if the FPS is below parameter.

[oli-obk]

• Ask Bevy glb loader to build in a "slow mode": postpone further node loading to the next frame if the FPS is below parameter.

The glb loader could also be changed to do the splitting of scenes. I'll investigate if this can be done without having to edit the bevy crate. If not, we'll fork it and work on a fork for now so we can iterate and test quicker

[DerKarlos]

Small scenes: less lag but more draw calls = less FPS

An escape could be LoD: Near tiles are small and detailed, far giles are 4/16 times in arrea with less details. Very far only 2D bitmaps. (also having terrain in mind)

[DerKarlos]

The Linux application sometimes is so busy loading tiles, not only the control is disabled, also the application menu including closing the app. And other task on the notebook (Mac Air) get ugly slow.