Construire un monde ouvert dans le navigateur, partie 4 : le streaming avant les terrains sophistiqués

Par Oleg Sidorkin, CTO et cofondateur de Cinevva

Vous découvrez la série ? Consultez le guide de la série. Il explique ce qu'est un spike et contient des liens vers toutes les parties.

C'est généralement au niveau du streaming que les projets qui « ont l'air bien » s'effondrent.

On peut masquer beaucoup de choses dans une image fixe. Impossible, en revanche, de dissimuler un blocage de 40 ms lors du franchissement de la limite d'un chunk.

Nous avons délibérément testé le streaming avant de construire une représentation avancée du terrain. Nous avons ainsi obtenu des données claires sur le comportement du chargement et du déchargement.

Le Spike 6 a validé le renouvellement des chunks voisins avec du contenu simple.

Ouvrir le Spike 6 dans un nouvel onglet ↗ · Voir le code source

Nous sommes ensuite passés au véritable pipeline de terrain avec le Spike 11 : streaming des chunks d'altitude, décodage côté worker et raffinement progressif, avec des grilles de 17, puis 33 et enfin 65 échantillons.

Ouvrir le Spike 11 dans un nouvel onglet ↗ · Voir le code source

L'ordre des étapes a eu plus d'importance que nous ne l'avions prévu. Si nous avions commencé directement avec des chunks d'altitude compressés, l'origine de chaque blocage aurait été ambiguë : problème de décodage, de transfert des textures ou de mise à jour de la géométrie. Le Spike 6 a supprimé une couche d'incertitude avant que le Spike 11 n'ajoute de la complexité.

Une leçon pratique tirée de ce chapitre nous a accompagnés dans les spikes suivants. Les blocages causés par les transferts doivent être mesurés directement, et non déduits du nombre moyen d'images par seconde. La moyenne des FPS masque les pics de temps de rendu, alors que ce sont précisément ces pics que les utilisateurs ressentent.

Dans la partie 5, nous abordons le coût visuel, lorsque la végétation, les shaders de terrain et les ombres en cascade se disputent le même budget de rendu par image.

Technologies abordées dans ce chapitre

Streaming par chunks. Le monde est divisé en une grille de chunks indépendants, généralement de 64 × 64 mètres. À mesure que le joueur se déplace, les chunks situés à l'arrière sont déchargés tandis que ceux situés à l'avant sont chargés en streaming. C'est ainsi que fonctionne le système de cellules de Skyrim : une grille de 5 × 5 cellules est chargée autour du joueur et se renouvelle au fil de ses déplacements. Dans le navigateur, la latence réseau vient s'ajouter à l'équation, ce qui rend crucial le préchargement prédictif fondé sur la vitesse du joueur. Consultez notre guide de l'architecture de streaming.

Raffinement progressif des heightmaps. Le terrain est d'abord envoyé en basse résolution, puis progressivement affiné. Les dimensions des grilles ne sont pas arbitraires : chaque niveau utilise une grille de $(2^k+1)\times (2^k+1)$, si bien que $17=2^4+1$, $33=2^5+1$ et $65=2^6+1$. Le $+1$ conserve un échantillon commun à chaque limite afin d'aligner les chunks voisins, et chaque étape multiplie approximativement par quatre le nombre d'échantillons ($n^2$ augmente lorsque le côté double). Une grille de 17 × 17 — le minimum pour un chunk de 64 m avec un espacement de 4 m — pèse environ 200 octets une fois compressée et permet d'afficher instantanément une surface visible. On charge ensuite en streaming le raffinement en 33 × 33, puis la résolution complète en 65 × 65. Chaque niveau ajoute des échantillons sans remplacer les données précédentes. Cette approche correspond directement aux anneaux de LOD des clipmaps géométriques, dans lesquels le terrain lointain utilise des données en basse résolution et le terrain proche la résolution complète. Consultez le chargement progressif des chunks.

Encodage différentiel et compression. Les données des heightmaps se compressent bien, car les cellules adjacentes présentent des valeurs similaires. L'encodage différentiel stocke la différence entre chaque cellule et sa valeur prédite — la moyenne de ses voisines —, ce qui regroupe les valeurs autour de zéro. Associé à zlib ou brotli, il fait passer un chunk de 65 × 65 de 8,4 Ko de données brutes à 1–2 Ko compressés. Avec une précision réduite pour les chunks éloignés — 8 bits au lieu de 16 bits —, la taille tombe à 0,5–1 Ko. Consultez la compression des données de terrain.

Préchargement prédictif. Il consiste à charger les chunks avant l'arrivée du joueur. La distance d'anticipation doit couvrir la distance parcourue par le joueur pendant le chargement d'un chunk, $d_{\text{prefetch}}=v\cdot t_{\text{load}}$ ; elle varie donc avec la vitesse : à la vitesse de marche (5 km/h), on précharge 2 chunks en avant (128 m), contre 4 à la vitesse de course (15 km/h). L'anneau de chargement se décale selon la direction de la vitesse. Une file de priorité classe les requêtes en attente selon leur urgence et annule celles concernant les chunks dont le joueur s'est éloigné. Consultez le préchargement prédictif.

---

Partie 4 sur 12.
Précédent : Partie 3 — Les spikes peu spectaculaires qui nous ont sauvés
Suivant : Partie 5 — Budgétiser les éléments visuels
Guide de la série : /fr/blog/2026-02-25-open-world-browser-series-guide