refactor(LayeredMaterial): migrate to TypeScript

[HoloTheDrunk]

Description

Converted the LayeredMaterial class and eponymous file to TypeScript.
Took this opportunity to do some internal cleanup and refactoring of things like the way the layers (or more precisely RasterTiles) were stored, the uniforms and defines, etc... This means the internal API for the material has changed since we now keep RasterColorTiles and the one RasterElevationTile separate internally. A convenience getLayer method has been provided matching the previous API for cases where the exact type of RasterTile is not important.
Whether we should rename the "layer" fields to "tile" to match the actual data type is up for debate. I'm all for it, but I'm not aware of how dependent people might be on those names.

Also planning on making the new uniforms/defines convenience TS-specific functions available to the PointsMaterial class and nuking src/Renderer/CommonMaterial.js out of existence in a coming PR.

Motivation and Context

This PR fits into the larger motion to migrate iTowns to TypeScript.

Tested on Ubuntu 22.04.5 LTS x86_64 using Firefox 126.0.1 (64-bit)

[jailln]

Thanks for this PR :) It really makes this material clearer!

I would be down for renaming layer to tile since using layer is really confusing with itowns layers and I think no one is using this API outside of itowns.

I noticed a few bugs though:

• terrain is not displayed anymore: see view_3d_map.html for instance. Also, it seems that now you only let the possibility to have one elevation layer. Even if multiple elevation layers support was not totally implemented (especially when having tiles at the same zoom level or because sometimes we used the first elevation layer by default), it was possible to have two elevation layers.
• debug tiles are always displayed:
  
• zoom is broken:

LayeredMaterial.mp4

[HoloTheDrunk]

Hi, yes this is still a WIP and I'm tracking down the source of these issues.
I'll be on holiday until early January though so this isn't gonna move much until then.
Happy holidays!
Update: back from holidays, working on this again

[Desplandis]

Good work! I made some suggestions while debugging/reviewing the code.

[Desplandis]

I think it would it be better to just assign the properties directly into defines. This would remove the need for type assertions and ease the readability of the code. Something like

        const defines: typeof this.defines = {
            NUM_VS_TEXTURES: nbSamplers[0],
            NUM_FS_TEXTURES: nbSamplers[1],
            USE_FOG: 1,
            NUM_CRS: crsCount,
            initModeDefines(),
            MODE: RenderMode.MODES.FINAL,
            DEBUG: __DEBUG__,
        };
        this.defines = defines;

You would need to change the initNodeDefines to output the key-mapped object for both ELEVATION_MODES and RenderModes.MODES. Such mapping could be done with

Object.fromEntries(
        Object.entries(ELEVATION_MODES).map(([key, value]) => [`ELEVATION_${key}`, value])
    ) as { [K in keyof typeof ELEVATION_MODES as `ELEVATION_${K}`]: typeof ELEVATION_MODES[K] }

P.S.: I didn't find a way to do such mapping without explicit casts
P.P.S: Forgot to use DefineMapping in my suggestion

[Desplandis]

Why not adding an override for uniforms too?

Something like MappedUniforms<LayeredMaterialRawUniforms>? uniforms would be correctly typed in the whole module.

[Desplandis]

In the same vein as my suggestion for defines, why not have a single call to initUniforms which could return all uniforms and assign the uniforms property directly?

[Desplandis]

@HoloTheDrunk You could fix the zoom and picking bug by correctly assigning the objectId uniform in the constructor of TileMesh.

material.setUniform('objectId', this.id);
// instead of
material.objectId = this.id;