Simplification of the loading process for rasterized tiles and mesh tiles by gchoqueux · Pull Request #2609 · iTowns/itowns

gchoqueux · 2025-10-06T15:28:21Z

Description

This PR proposes a possible simplification of the loading process for rasterized tiles and mesh tiles.

Summary of changes

TileMesh instances are now created directly in TiledGeometryLayer, without using commands or providers.
TileMesh.pendingSubdivision has been removed.
TiledGeometryLayer#hasEnoughTexturesToSubdivide has been removed.
updateLayeredMaterialNodeImagery and updateLayeredMaterialNodeElevation have been merged into a single lightweight method.
TileProvider has been deleted.
Texture loading is now handled by RasterTile#load.

gchoqueux · 2025-10-08T13:31:37Z

Rebased

gchoqueux · 2025-10-08T13:33:35Z

I’ve come up with a possible way to simplify this — what do you think of these changes?

jailln · 2025-10-10T14:20:04Z

It seems related to #2521 and #2525 which haven't been merged yet; but it goes a bit further, is that right? These PR where not merged because of #2530 . Do you have the same issue?

gchoqueux · 2025-10-13T11:36:34Z

It seems related to #2521 and #2525 which haven't been merged yet; but it goes a bit further, is that right? These PR where not merged because of #2530 . Do you have the same issue?

~~It doesn’t seem to have the same issue in the functional tests.~~
However, I did change the number of displayed tiles in the functional tests — maybe because this PR is not finished yet.

gchoqueux · 2025-10-14T09:21:09Z

My bad, there's a issue with VIEW_EVENTS.LAYERS_INITIALIZED, but it is not the same, it's called very late, it's almost the opposite.
I'll investigate solved

Neptilo · 2026-01-16T16:11:53Z

Hi! I'm starting to look into the loading processes to get familiar with them, in order to improve them after this simplification is completed. Thanks for the work done so far!
Do you need help fixing the remaining bugs?
What is the display bug you mention in ElevationLayer.anyVisibleData? I can see that changing the first current.source to current?.source already makes a big difference, but I assume you are referring to a deeper bug...

gchoqueux · 2026-01-20T17:09:53Z

Remaining work in this PR

finalize the method for verifying data visibility : anyVisibleData vs extentInsideLimit methods
rewrite some unit tests
finalize tiles property in RasterTile

FAQ

What is the display bug you mention in ElevationLayer.anyVisibleData?

I don't remember exactly i remove the commentary

I can see that changing the first current.source to current?.source, you are referring to a deeper bug ?

I think it's not a bug

the others bugs :

wrong tile visibility
wrong parent texture update

gchoqueux · 2026-01-27T15:35:19Z

Next steps to move forward on the PR

An initial code review by at least 2 reviewers on the architecture and the core aspects of the PR.
The main code of this PR hasn’t changed for weeks; only minor formatting changes and rebases have been made.

Assistance can be provided on the following points:

Validation and finalization of the development of anyVisibleData
Rewriting unit tests and improving coverage
Help testing this PR on the various itowns examples

Desplandis

The proposed changes are fine by me. It makes the code more easy to understand (e.g. no need to track the changes of layerUpdateState across 4 different files). I did some high-level comments on the code (and some low-level too sorry), those are some questions about the behaviour before and after this PR.

Note that I did not tested it across our examples, nor did I run the tests.

Could you please provide a list of the remaining things to address in this PR?

Desplandis · 2026-02-20T16:27:24Z

+        // [TEMP] find best place to update uniforms
+        node.material.layersNeedUpdate = node.material.visible;


This is similar to the old behaviour, but I agree that we should reconsider where we should request a new update of the material!

yes, it's not the best place, because node.material.layersNeedUpdate is true each time that tileMesh is visible

Desplandis · 2026-02-20T19:47:25Z

+    anyVisibleData(node) {
+        const current = node.material.getElevationTile()?.layer;
+        return super.anyVisibleData(node)
+            && (current?.source == this.source || this.source.zoom.min > (current?.source.zoom.max || -1));


What is the meaning of -1 here?

it's for this.source.zoom.min > -1 would be always true

In that case, the data is considered visible if source.zoom.min < layer.source.zoom.max? Not sure to follow here.

I clarified this by refactoring the code

Desplandis · 2026-03-17T07:56:41Z

@gchoqueux Are you available for a session of peer programming on this PR tomorrow or the following monday? I would like to converge on this one. =)

Desplandis · 2026-06-03T13:39:50Z

I'm currently looking to the PR (hope we can finalise this), catched a regression on view_25d_map when moving or zooming out, we don't have textures (neither elevation nor imagery) when loading new levels. I'll try to investigate a bit during my review.

P.S.: misc_clamp_ground too

Desplandis · 2026-06-04T12:16:00Z

+                return layer;
            }
-            itowns.Fetcher.json('./layers/JSONLayers/IGN_MNT_HIGHRES.json').then(addElevationLayerFromConfig);
+            const p = itowns.Fetcher.json('./layers/JSONLayers/IGN_MNT_HIGHRES.json').then(addElevationLayerFromConfig);


I think a top-level await would be clearer. This comment applies to all examples of itowns per-se.

Desplandis · 2026-06-04T12:18:57Z

-        if (this.shouldWriteTextureAtIndex(index, texture)) {
-            this.level = (texture && texture.extent) ? texture.extent.zoom : this.level;
-            this.textures[index] = texture || null;
+        if (texture && this.shouldWriteTextureAtIndex(index, texture)) {


Is there some places where we could pass an undefined texture there? Shall those undefined be filtered before at the call sites?

If we filter out undefined textures, we lose the indexing needed to assign them

Desplandis · 2026-06-04T12:20:41Z

+function refinementCommandCancellationFn(cmd) {
+    const { requester, view } = cmd;
+    const child = requester.children[0];
+
+    // to do remove useless
+    return !cmd.force && (!view || !requester.parent || !requester.material || !requester.material.visible || child?.visible);
+}


@gchoqueux Are those points addressed?

Desplandis · 2026-06-04T12:22:04Z

-        colorlayers.sort((a, b) =>
-            this.colorTileIds.indexOf(a.id) - this.colorTileIds.indexOf(b.id),
-        );
+        if (this.layersNeedUpdate) {


Prefer an early return with the !this.layersNeedUpdate condition.

Desplandis · 2026-06-04T12:25:12Z

-
-            node.material.visible = true;
-            node.material.layersNeedUpdate = true;
+        if (node.visible && this.subdivision(context, node)) {


There are some issues with the freshly subdivided tiles which have no terrain and no imagery (e.g. view_25dmap and misc_clamp_ground issues are flagrant). Re-adding the hasEnoughTexturesToSubvide condition seems to fix the problem, however I think the problem is more profound.

may be add hasEnoughTexturesToSubvide for the first tile ?

and refactor hasEnoughTexturesToSubvide to LayeredMaterial

I add a new wip commit :

5a42809 fix(TiledGeometryLayer): [WIP][PROPOSAL] avoid to subdivide node mesh if raster tiles aren't loaded

Desplandis · 2026-06-04T13:08:01Z

Looking at it, I think the problem is two-fold:

Since we are not blocking subdivision with hasEnoughTexturesToSubvide, we do not trigger parent texture loading
Since everything is synchronous, when we call initFromParent, the texture is not loaded on the parent and we don't have a mechanism to notify descendant tiles of a loaded ancestor texture.

BREACKING CHANGES: remove pdateLayeredMaterialNodeImagery, updateLayeredMaterialNodeElevation

… if raster tiles aren't loaded

gchoqueux added the refactor 🏭 label Oct 6, 2025

gchoqueux changed the title ~~Simplification of the loading process for **rasterized tiles** and **mesh tiles**.~~ Simplification of the loading process for rasterized tiles and mesh tiles Oct 6, 2025

gchoqueux force-pushed the refacto/simple_loading_tile branch 13 times, most recently from 489581c to afdfc01 Compare October 8, 2025 13:13

gchoqueux force-pushed the refacto/simple_loading_tile branch from afdfc01 to 6f64fdf Compare October 10, 2025 09:24

gchoqueux force-pushed the refacto/simple_loading_tile branch 4 times, most recently from 2cec783 to 15dfa04 Compare October 13, 2025 11:12

gchoqueux force-pushed the refacto/simple_loading_tile branch 4 times, most recently from c7b4635 to 4bd5c32 Compare October 14, 2025 09:13

gchoqueux force-pushed the refacto/simple_loading_tile branch from e9aab85 to 3d3be67 Compare October 14, 2025 15:48

gchoqueux force-pushed the refacto/simple_loading_tile branch 2 times, most recently from eecc503 to 4c86123 Compare December 15, 2025 14:53

gchoqueux force-pushed the refacto/simple_loading_tile branch 3 times, most recently from 5235375 to 7a3ea9a Compare January 7, 2026 15:34

gchoqueux force-pushed the refacto/simple_loading_tile branch 2 times, most recently from 7a07fe7 to 47507b0 Compare January 20, 2026 16:54

gchoqueux force-pushed the refacto/simple_loading_tile branch from 47507b0 to 5b6ea96 Compare January 30, 2026 14:02

gchoqueux force-pushed the refacto/simple_loading_tile branch 8 times, most recently from 92e8c4c to a9618c4 Compare February 16, 2026 16:23

gchoqueux force-pushed the refacto/simple_loading_tile branch from a9618c4 to c581383 Compare February 17, 2026 14:59

Desplandis reviewed Feb 20, 2026

View reviewed changes

gchoqueux mentioned this pull request Apr 15, 2026

Refacto Source methods #2747

Merged

Desplandis requested changes Jun 4, 2026

View reviewed changes

gchoqueux added 4 commits July 1, 2026 14:58

refacto(RasterTile): simplify raster layer loading

c2514ea

BREACKING CHANGES: remove pdateLayeredMaterialNodeImagery, updateLayeredMaterialNodeElevation

fix(test): issues from refactoring and rebasing

78e9038

refacto(examples): use await top level to fetch

fd50220

fix(TiledGeometryLayer): [WIP][PROPOSAL] avoid to subdivide node mesh…

f49e3f3

… if raster tiles aren't loaded

		// [TEMP] find best place to update uniforms
		node.material.layersNeedUpdate = node.material.visible;

Uh oh!

Conversation

gchoqueux commented Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Summary of changes

Uh oh!

gchoqueux commented Oct 8, 2025

Uh oh!

gchoqueux commented Oct 8, 2025

Uh oh!

jailln commented Oct 10, 2025

Uh oh!

gchoqueux commented Oct 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gchoqueux commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Neptilo commented Jan 16, 2026

Uh oh!

gchoqueux commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Remaining work in this PR

FAQ

Uh oh!

gchoqueux commented Jan 27, 2026

Next steps to move forward on the PR

Uh oh!

Desplandis left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gchoqueux Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Desplandis commented Mar 17, 2026

Uh oh!

Desplandis commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gchoqueux Jun 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

gchoqueux commented Oct 6, 2025 •

edited

Loading

gchoqueux commented Oct 13, 2025 •

edited

Loading

gchoqueux commented Oct 14, 2025 •

edited

Loading

gchoqueux commented Jan 20, 2026 •

edited

Loading

gchoqueux Mar 6, 2026 •

edited

Loading

Desplandis commented Jun 3, 2026 •

edited

Loading

gchoqueux Jun 16, 2026 •

edited

Loading