Le moteur

De la donnée OpenStreetMap au pixel à l’écran

OpenStreetMap fournit la donnée. Tout le reste, nous l’avons écrit : le pipeline qui découpe chaque tuile, le service qui la pousse en direct, et le moteur qui la dessine.

La planète est découpée en cellules, pas en carrés

La plupart des cartes web découpent le monde en grille Mercator, qui déforme lourdement les surfaces à l’approche des pôles et vous impose un choix de projection. CityMap3D découpe la sphère elle-même en cellules.

Une cellule est une région d’une vraie sphère. Près de l’équateur comme près du pôle, elle couvre une surface comparable : la tuile qui arrive à votre caméra porte donc le niveau de détail que la distance justifie, pas celui qu’une projection lui aurait imposé. Le sujet est développé dans OpenStreetMap en globe 3D, pas en carte plate.

Chaque tuile est de la géométrie, à tous les zooms

Le pipeline ne produit aucune image précalculée. De près, de loin, en orbite, une tuile contient des polygones, des hauteurs et des couleurs, jamais une image toute faite.

C’est ce qui permet à une palette de tenir jusqu’à l’horizon. Une carte que vous avez recolorée ne se dilue pas dans des tuiles génériques dès que la caméra s’éloigne : il n’y a aucune image précalculée sur laquelle elle pourrait retomber.

Les tuiles transitent dans un format binaire conçu pour ça plutôt qu’en texte, et le décodage tourne hors du thread principal : la carte reste fluide pendant le chargement.

Le détail suit la distance réelle, en trois dimensions

Chaque tuile visible reçoit un niveau de détail calculé à partir de sa vraie distance à la caméra, pas à partir d’un niveau de zoom, ni d’une approximation à plat qui ignore l’altitude de la caméra.

Au-dessus du sol, les objets sont regroupés en instanced meshes mutualisés sur toutes les tuiles chargées : des milliers d’arbres, de lampadaires et de marqueurs atteignent le GPU en une poignée d’appels plutôt qu’en milliers.

La charge s’adapte à l’appareil

Une boucle fermée chronomètre chaque image et ajuste au vol la quantité de travail engagée : elle allège la charge du moteur tant que l’image est trop lente.

Vous n’avez plus à parier sur le matériel de vos utilisateurs, ni à choisir un niveau de qualité à leur place.

Le ciel est calculé à partir de votre date et de votre lieu

La position du soleil vient des coordonnées et de l’horodatage que vous fournissez. La lune affiche la phase de cette nuit précise, avec son terminateur et sa rotation parallactique. Au-dessus, 1 660 étoiles réelles et les 88 constellations classiques tournent comme elles le feraient pour un observateur placé à cet endroit.

Le soleil pilote ensuite toutes les lumières directionnelles de la scène : les ombres, la teinte de l’air, le halo autour du soleil lui-même, la couleur de chaque pixel. Réglez la date sur l’heure dorée et toute la carte suit.

De quoi l’image est faite

Le rendu repose sur un pipeline à haute plage dynamique (HDR). Concrètement, à l’écran, cela donne :

  • Des ombres en cascade qui restent nettes près de la caméra et tiennent à distance
  • De la profondeur ambiante, pour que les ruelles, les porches et les recoins s’assombrissent comme ils le feraient dans la réalité
  • Du brouillard atmosphérique qui voile le lointain sans aplatir un canyon
  • Un halo de soleil et de lune calé sur la position réelle du soleil
  • Un tonemapping filmique, puis un étage d’étalonnage qui aligne tout le rendu sur votre palette

La chaîne est composable et rien n’y est caché : remplacer un bloc de shader est une opération prévue, pas un fork. Voir recolorer la carte à chaud, sans rien régénérer.

Les tuiles arrivent pendant que vous regardez

Une tuile pas encore générée répond 202 ; le client s’abonne par WebSocket et est averti dès qu’elle est prête à être téléchargée. Sans polling, sans rechargement : comment fonctionne la mise à jour en temps réel.

Ce sur quoi tout cela repose

Le monde est compilé en amont sur notre infrastructure et servi sous forme de tuiles ; le moteur de rendu tourne en WebGL 2.

Les données cartographiques viennent d’OpenStreetMap et de ses contributeurs, sous licence Open Database. Notre travail est de transformer cette donnée en carte 3D : quels tags OpenStreetMap deviennent de la géométrie 3D.

À lire ensuite : ce que vous branchez : canvas, scène et caméra.

Dans cette section

  • OpenStreetMap en globe 3D, pas en carte plate

    Pas de Mercator, pas de déformation de projection, pas de pôles cassés. Une seule caméra continue du pas de porte à l’orbite, sur un monde qui est une vraie sphère à toutes les échelles.

  • La carte se met à jour sans rechargement

    Une tuile pas encore générée répond 202, pas une erreur. Le client s’abonne par WebSocket et la tuile arrive dans la scène dès qu’elle est prête, sans polling ni rechargement.

  • Recolorez la carte à chaud, sans rien régénérer

    Changez les couleurs de la carte en direct, sans régénérer de tuiles : la palette s’applique au moment du rendu et toute la scène se met à jour immédiatement, à tous les zooms.