Basic Tile Rendering

[GeraldKimmersdorfer]

Issue includes:

• Tile-Fetching port from gl_engine
• Load textures within webgpu
• Draw tile vertices instanced
• move vertex to final position by texture fetch of heightmap in vertex shader
• Pull and Merge from upstream

Goal:

• Rendering of a tileset (only ortho-image) based on the current camera.

Non-Goals:

• Texture Compression
• Working camera
• Atmosphere and other shading effects
• Deferred shading

[pkomon-tgm]

This seems to be done! 🎉

• implemented merge from upstream in e3df2e7ea3044ea81a39668b05a52a4f98657568
• implemented tile loading, texture upload and instanced drawing in ba42c448d3847d9e81cda0578c886a8bcb7e4f0e
• fix problems with maxTextureArrayLayers in 2d1f802ea18bdefbb0e76b6b7b484b7b3a17b0d5

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]

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

Fixed in d6cc110499498b6330ca4f116be1455718de60e1.