weBIGeo / webigeo

Rendering system for weBIGeo.
GNU General Public License v3.0
4 stars 0 forks source link

Basic Tile Rendering #1

Closed GeraldKimmersdorfer closed 5 months ago

GeraldKimmersdorfer commented 7 months ago

Issue includes:

Goal:

Non-Goals:

pkomon-tgm commented 6 months ago

This seems to be done! 🎉

The last point maybe needs some clarification. webGPU imposes a limit on the number of elements ("layers") in a 2d texture array, which is called maxTextureArrayLayers. I noticed, the supported limits to be different when running our native build with Dawn (2048 in my machine) and our wasm build with Google Chrome (256). Only for <25% of devices, this is higher than 256 (according to https://web3dsurvey.com/webgpu/limits/maxTextureArrayLayers)

When exceeding that limit, we use a replacement strategy to replace old tiles with newly fetched ones. Sometimes this can lead to artifacts (see https://github.com/AlpineMapsOrg/renderer/issues/101) based on what tiles are replaced.

Regardless, we want to support more texture layers to be stored on the GPU and used during rendering. Three possible solutions are

  1. split into multiple texture arrays, do multiple draw calls with different texture array binding
  2. split into multiple texture arrays, bind all at once and do a single draw call
  3. use a 3d texture, since here the limit on the third dimension is more lenient 2048 on >99.5% devices according to https://web3dsurvey.com/webgpu/limits/maxTextureArrayLayers

For now, I opted to implement (1), as it was pretty straighforward to implement and seems like it would not incur much of a performance penalty (in fact, I didn't notice any difference in FPS when moving around a bit). In the browser, this effectively prevents artifacts based on the tile replacement strategy (by just having more space to spare and needing less replacement).

pkomon-tgm commented 6 months ago

Forgot to actually use the implementation with multiple draw calls :wasntme:

Fixed in d6cc110499498b6330ca4f116be1455718de60e1.