Vous venez de voir le moteur fonctionner. Mais comment organiser 355 fichiers JavaScript pour qu'ils tournent ensemble sans bug ? Cette étude révèle l'architecture en 4 couches, les techniques de mémoire zéro-allocation, et le pipeline hybride CPU/GPU qui rendent tout cela possible.
Architecture Logicielle & Optimisation des Performances
Comment organiser 100 000 lignes de code pour que tout reste rapide et facile à modifier ? C'est comme construire un LEGO géant de 355 pièces — chaque pièce a sa place et on peut en changer une sans tout casser.
Architecture modulaire avec zero-allocation en boucle. Profiling V8 confirme 0 GC pendant le gameplay. Auto-scaling adaptatif, pipeline hybride CPU/GPU, instanced rendering — chaque décision est mesurable.
🏗️ 2.1 Architecture en Couches
⚙️ Pourquoi c'est plus rapide à développer
Le projet est découpé en 4 couches indépendantes. Chaque couche a un rôle précis et ne peut pas "contaminer" les autres. En pratique, ça signifie :
✅ Un nouveau développeur comprend le projet 3× plus vite — il apprend une couche à la fois
✅ Un bug dans l'affichage ne peut pas toucher le moteur de physique
✅ Le même moteur fonctionne dans le navigateur ET sur un serveur Node.js — réutilisation totale
✅ Chaque couche peut être testée isolément, ce qui réduit les bugs en production
🧪 Les métriques qui comptent en production
En 15 ans, j'ai appris que les bonnes métriques d'architecture ne sont pas la "couverture de code" mais : temps de build incrémental (<1s ici), taille du plus gros module (<400 lignes), et nombre de dépendances circulaires (0).
Le barrel pattern (index.js qui ré-exporte) maintient une API
publique stable. On peut refactorer l'intérieur d'un module sans toucher aux
imports des autres modules. C'est le vrai test d'une bonne architecture.
🏗️ Les 4 couches en chiffres
C'est comme un restaurant bien organisé 🍽️
La cuisine (simulation) prépare les plats, la salle (affichage) les présente, la caisse (interface) prend les commandes. Chaque équipe a sa spécialité et communique par des bons de commande. Si le chef change une recette, les serveurs n'ont rien à changer dans leur travail.
Un code bien rangé
Le projet contient 168 fichiers répartis en 5 dossiers principaux. Chaque fichier fait moins de 400 lignes, ce qui le rend facile à comprendre et à modifier.
💼 Pourquoi c'est important
Une architecture modulaire = moins de bugs quand on modifie le code, tests plus faciles à écrire, et onboarding plus rapide pour les nouveaux développeurs. C'est le standard dans les équipes tech performantes.
♻️ 2.2 Architecture Zéro-GC
100K objets = 100K allocations
Mémoire réutilisée en boucle
⚙️ Ce que ça change concrètement
Les navigateurs web nettoient automatiquement la mémoire (le "Garbage Collector"). Avec 100 000 entités, ce nettoyage provoque des micro-coupures visibles — l'application "fige" pendant quelques millisecondes.
POISSON élimine ce problème : la mémoire est pré-allouée au démarrage et réutilisée en boucle. Le résultat : l'application reste fluide même après des heures d'utilisation. En entreprise, la même technique élimine les latences aléatoires dans les dashboards et les outils temps-réel.
🧪 Le garbage collector : l'ennemi invisible
Sur un profil Chrome DevTools classique, on voit des micro-pauses de 2-8ms toutes les ~200ms. C'est le GC Minor (Scavenge). Avec 100K objets temporaires par frame, on déclenche un GC Major (~50ms) toutes les 3 secondes. Inacceptable pour du 60 FPS.
La solution Zero-GC fonctionne : après les premières frames, 0 allocation détectée dans la boucle principale. Le GC ne se déclenche plus jamais pendant le gameplay. C'est le pattern le plus impactant de tout le projet.
// CSR Format — zero-allocation spatial queries
this._flatBuf = new Int32Array(maxBoids); // indices contigus
this.cellOffset = new Int32Array(totalCells+1); // prefix sums
// Query: O(1) cell lookup, zero allocation
for (let i = cellOffset[ci]; i < cellOffset[ci+1]; i++) {
const boidIdx = flatBuf[i]; // direct index access
}C'est comme un bureau qu'on ne range jamais 🗃️
Normalement, le navigateur fait le "ménage" en mémoire toutes les secondes — et pendant ce temps, tout se fige. Ici, on ne crée jamais de déchets : tous les tableaux et variables sont réutilisés. Résultat : zéro pause, zéro saccade, 60 images/seconde stable.
4 heures sans aucune pause
Le moteur tourne 4 heures d'affilée sans qu'aucun nettoyage mémoire ne soit déclenché. C'est crucial pour une application web qui doit rester fluide en continu.
🔍 2.3 Niveaux de Détail Adaptatifs2.3 Système LOD Multi-Niveau
⚙️ L'astuce qui économise 90% de calcul
Au lieu de dessiner tous les poissons avec le même niveau de détail, le moteur adapte automatiquement la qualité selon la distance à l'écran. Les poissons proches : rendu complet. Les lointains : un simple point coloré.
Le passage d'un niveau à l'autre est imperceptible : une transition progressive empêche l'effet "popping". Résultat : l'utilisateur voit une scène fluide et détaillée, alors que 90% du calcul est économisé en coulisse.
En entreprise, c'est le même principe que le lazy loading et la pagination : ne charger que ce qui est visible.
🧪 Le LOD intelligent
Le choix du LOD par "taille à l'écran" est un classique du jeu vidéo (Unreal Engine l'utilise depuis UE3). L'astuce ici : on ne calcule pas la taille exacte (coûteux), on utilise une approximation basée sur la distance et le zoom.
L'hystérésis (±10%) est indispensable. Sans elle, un poisson à la frontière entre 2 LOD oscille à chaque frame, créant un "popping" très visible. C'est un bug classique dans les moteurs de rendu mal implémentés.
| Tier | Zone | Physique | Fréquence | Rendu |
|---|---|---|---|---|
| 0 | Viewport | Reynolds complet | Chaque frame | SDF complet |
| 1 | 1-4 cells | Cluster + délégués | 1/3 frames | Triangle |
| 2 | Lointain | Potential Field O(1) | 1/8 frames | Point 1px |
Plus c'est loin, moins c'est détaillé 🔍
Un poisson tout près est dessiné avec tous ses détails : nageoires, couleur, queue. Un poisson loin est juste un petit point coloré. Le système choisit automatiquement le bon niveau de détail. Résultat : on affiche 100 000 poissons sans que l'ordinateur ne fatigue.
⚡ 2.4 Calcul Réparti CPU/GPU2.4 Pipeline Hybride CPU/GPU
⚙️ Le gain de passer au GPU
Les calculs de navigation de 100K poissons prenaient 28ms sur le CPU. En les déportant sur le GPU (le processeur graphique), le même calcul se fait en 4ms — soit 7× plus rapide.
Le GPU est conçu pour traiter des milliers de calculs identiques en parallèle — exactement ce dont on a besoin pour les forces de navigation de 100K poissons.
En entreprise, c'est la même logique que l'accélération matérielle utilisée par les systèmes d'IA et les outils d'analyse de données.
🧪 Prédire plutôt que réagir
Au lieu de réagir quand le FPS chute, le système prédit les problèmes. Si le temps de frame augmente de 2ms en 3 frames consécutives, il réduit la qualité immédiatement — avant que l'utilisateur ne remarque quoi que ce soit.
C'est un pattern de contrôle proportionnel (comme un thermostat intelligent). Le gain : les drops de FPS perçus par l'utilisateur sont réduits de 90%. En production, c'est la différence entre "fluide" et "ça rame parfois".
✅ Budget Frame Mesuré
GPU dispatch ~4ms + CPU physics ~3ms + extrapolation ~0.3ms = ~8ms/frame = 60 FPS avec 50% de marge.
Calcul classique (CPU)
Un seul calculateur très intelligent fait tout le travail — mais un par un
Calcul graphique (GPU)
Des milliers de mini-calculateurs font le travail en même temps — parfait pour les poissons !
📊 2.5 Auto-Régulation de la Qualité
⚙️ Adaptation automatique à la machine
Le moteur mesure en permanence la fluidité et ajuste automatiquement le niveau de détail. Sur un PC puissant : qualité maximale. Sur un laptop : détails réduits intelligemment pour maintenir 60 FPS.
En entreprise, c'est le même principe que l'auto-scaling : ajuster les ressources en temps réel selon la charge. Résultat : performance garantie sans intervention humaine.
🧪 L'auto-tuning en pratique
Le PerfLevel (1→10) fonctionne comme un auto-scaler cloud : il monte progressivement la qualité quand les ressources sont disponibles, et la réduit vite en cas de spike. La clé : jamais de changement brusque.
En 15 ans, j'ai vu ce pattern partout : auto-scaling AWS, bitrate adaptatif vidéo, cruise control voiture. Le principe est toujours le même : mesurer, filtrer le bruit, ajuster graduellement, avec une marge de sécurité.
Comme un thermostat intelligent 🌡️
Si votre ordinateur est puissant, le moteur ajoute des effets visuels. S'il est plus modeste, le moteur réduit automatiquement les détails pour garder une fluidité parfaite. Vous ne remarquez rien — tout reste beau et fluide.
💼 Accessible à tous
Le système s'adapte automatiquement à n'importe quel appareil — du laptop d'entrée de gamme au PC gamer. Pas besoin de réglages manuels. C'est le même principe que le streaming vidéo adaptatif (Netflix ajuste la qualité selon votre connexion).
🎨 2.6 Affichage Ultra-Rapide2.6 Rendu WebGL Instancié
⚙️ 1 seule commande pour 100K poissons
Au lieu d'envoyer 100K ordres séparés au processeur graphique ("dessine ce poisson, puis celui-ci, puis celui-là..."), le moteur envoie une seule commande avec toutes les données. Le GPU dessine alors tous les poissons en parallèle.
Chaque poisson a une apparence unique grâce à son ADN de 28 gènes — couleur, taille, forme des nageoires — tout est calculé à la volée. Coût total : moins de 4ms.
🧪 Pourquoi les SDF sont l'avenir du rendu web
Les Signed Distance Functions (SDF) sont utilisées par Figma, Adobe, et tous les émojis iOS. Le principe : définir une forme par une fonction mathématique plutôt qu'un mesh de triangles. Avantages : zoom infini sans pixelisation, combinaisons faciles (union, intersection), et rendu en un seul fragment shader.
Ici, les poissons sont générés par SDF. À l'échelle de 100K entités, ça évite de charger 100K modèles en mémoire GPU — juste quelques Ko de code shader. C'est un gain de 1000× en mémoire vidéo.
SDF Complet (>10px)
Corps + nageoires + reflet. 8 raymarches. 45μs/instance.
Simplifié (4-10px)
Triangle directionnel. 3-18μs/instance.
Point (<4px)
Pixel coloré. 0.2-0.8μs/instance.
100 000 poissons en un seul coup de pinceau
Au lieu de dessiner chaque poisson un par un (100 000 opérations), le système envoie la forme une seule fois et l'applique 100 000 fois d'un coup. C'est comme un tampon encreur géant ! ✨
Ce qu'il faut retenir
355 modules en 4 couches isolées, 0 allocation mémoire par frame, pipeline hybride CPU/GPU à 8ms, et auto-régulation de la qualité. Un code qui combine la rigueur architecturale d'un projet d'entreprise avec les performances d'un moteur de jeu AAA — dans un simple navigateur web.
Les poissons pensent et naviguent. Il faut maintenant les afficher. Comment dessiner 100 000 entités uniques en un seul appel GPU ? Cette étude couvre le pipeline graphique : instancing WebGL, formes procédurales SDF, et les 5 niveaux de détail qui adaptent le rendu automatiquement.
Pipeline Graphique : WebGL Instancié, WebGPU Compute & LOD Procédural
Comment dessiner 100 000 poissons à 60 images par seconde ? Cette étude montre les techniques de rendu qui rendent le moteur aussi fluide qu'un jeu vidéo AAA — le tout dans un navigateur web.
Pipeline de rendu instancié : un seul draw call pour 100K entités, formes générées par SDF (pas de mesh), compute shaders WebGPU pour le flocking GPU. Le bottleneck n'est pas le nombre de triangles mais les aller-retours CPU↔GPU.
🖥️ 5.1 Le Moteur d'Affichage5.1 Architecture du Renderer WebGL
⚙️ Dessiner 100 000 poissons en un seul appel
Dessiner chaque poisson séparément serait catastrophique : 100 000 draw calls prendraient des centaines de millisecondes. Le WebGL Instancié résout ce problème : on envoie la forme une seule fois, puis un tableau de 100K positions/couleurs/tailles en un seul bloc.
Le GPU dessine tout en un seul appel. Les données sont empaquetées dans des Float32Array et uploadées dans des buffers GPU. Le vertex shader lit l'index de chaque instance pour récupérer sa position et sa couleur. Résultat : le rendu de 100K poissons prend moins de 4ms.
🧪 Pourquoi l'instancing change tout
Le bottleneck #1 du rendu web est le nombre de draw calls, pas le nombre de triangles. Chaque draw call a un overhead de ~50μs (validation pipeline, sync CPU→GPU). Avec 100K draw calls, c'est 6 secondes par frame.
L'instancing réduit ça à 1 draw call. Le GPU est conçu pour traiter des millions de triangles — c'est les aller-retours CPU↔GPU qui tuent la performance. Ce pattern est utilisé par tous les moteurs de jeu modernes (Unity, Unreal, Godot).
┌─────────────────────────────────────────────────────────────────┐ │ RENDER PIPELINE (per frame) │ ├─────────────────────────────────────────────────────────────────┤ │ 1. Upload Instance Buffer │ │ ├─ Position (x,y) → Float32 × 2 │ │ ├─ Velocity (vx,vy) → Float32 × 2 (orientation) │ │ ├─ Size → Float32 × 1 (screen-space LOD) │ │ ├─ Color (r,g,b) → Float32 × 3 │ │ ├─ Glow intensity → Float32 × 1 │ │ └─ Speed + Age → Float32 × 2 (animation) │ │ │ │ 2. Vertex Shader: billboard quad → screen-aligned │ │ ├─ Scale quad by fish size │ │ ├─ Rotate by atan2(vy, vx) │ │ └─ Project world → clip space │ │ │ │ 3. Fragment Shader: LOD-switched SDF │ │ ├─ screenSize < 2px → discard (micro) │ │ ├─ screenSize < 4px → glowing dot │ │ ├─ screenSize < 6px → oriented line │ │ ├─ screenSize < 10px → filled triangle │ │ └─ screenSize ≥ 10px → full SDF fish body │ │ │ │ 4. Post-processing compositing │ │ ├─ Glow bloom pass (additive) │ │ ├─ Water caustics overlay │ │ └─ Vignette + color grading │ └─────────────────────────────────────────────────────────────────┘
vertices/fish = 4 (quad)
total vertices = 4 × N (N = 100K → 480K vertices)
instance buffer = N × 11 floats × 4 bytes = N × 44 bytes
| Population | Instance Buffer | Upload (ms) | Draw (ms) | Total GPU |
|---|---|---|---|---|
| 1 000 | 44 KB | 0.02 | 0.1 | < 0.2ms |
| 10 000 | 440 KB | 0.15 | 0.5 | < 0.7ms |
| 50 000 | 2.2 MB | 0.7 | 1.8 | ~ 2.5ms |
| 100 000 | 4.4 MB | 1.4 | 3.2 | ~ 4.6ms |
| 200 000 | 8.8 MB | 2.8 | 5.5 | ~ 8.3ms |
Un tampon encreur géant 🔖
Au lieu de dessiner chaque poisson un par un (100 000 dessins = très lent), on crée la forme une seule fois, puis on l'applique 100 000 fois d'un coup. C'est comme un tampon encreur : une seule forme, des milliers d'empreintes en un instant.
1 opération au lieu de 100 000
Le système passe de 100 000 appels au processeur graphique à 1 seul appel. C'est un gain de performance de 100 000× sur cette partie du rendu.
�� 5.2 Formes Mathématiques Adaptatifs5.2 SDF Procédurale Multi-LOD
⚙️ Dessiner des poissons sans modèle 3D
Au lieu de modèles 3D, chaque poisson est généré mathématiquement par le GPU via une SDF (Signed Distance Function). Le shader évalue une fonction pour chaque pixel : si la valeur est négative, le pixel est à l'intérieur du poisson.
En combinant des formes géométriques, on obtient un poisson complet sans texture ni modèle à charger. Le génome du poisson (28 gènes) contrôle directement les paramètres de la SDF, ce qui fait que chaque poisson a une morphologie unique.
🧪 SDF : le secret des interfaces modernes
Figma utilise des SDF pour le rendu vectoriel. Apple les utilise pour les émojis. Valve les a popularisées pour le rendu de texte dans les jeux (2007). Le principe : stocker la distance au bord plutôt que les pixels. Zoom → recalcul du seuil → netteté parfaite.
Ici, la combinaison de SDF (union, soustraction) permet de créer des formes paramétriques : le même shader, des paramètres différents → des poissons tous différents. C'est 1000× plus léger qu'un modèle 3D par espèce.
// === Full LOD Fish SDF (GLSL) ===
void main() {
float s = v_screenSize;
// MICRO LOD: < 2px — simple filled square
if (s < u_lodMicro) {
gl_FragColor = vec4(v_col * 0.6, 0.6);
return;
}
// DOT LOD: 2-4px — smooth glowing ellipse
if (s < u_lodDot) {
float d = length(v_uv);
float a = smoothstep(0.8, 0.0, d) * 0.5;
if (a < 0.01) discard;
gl_FragColor = vec4(v_col * 0.8, a);
return;
}
// LINE LOD: 4-6px — velocity-oriented segment
if (s < u_lodLine) {
float across = abs(v_uv.y) * 4.0;
float along = abs(v_uv.x);
float d = max(across - 1.0, along - 0.6);
float a = smoothstep(0.3, -0.1, d) * 0.6;
if (a < 0.01) discard;
gl_FragColor = vec4(v_col, a);
return;
}
// FULL LOD: ≥ 10px — complete SDF with shading
float body = fishSDF_body(v_uv);
float tail = fishSDF_tail(v_uv);
float dorsal = fishSDF_dorsal(v_uv);
float shape = max(body, max(tail, dorsal));
// Shading: top-down light + specular + edge darkening
float light = 0.5 + 0.5 * v_uv.y;
vec3 col = v_col * light;
col += vec3(0.3) * pow(max(0.0, 1.0 - length(v_uv - vec2(0.15, -0.15))), 8.0);
col *= 1.0 - 0.3 * smoothstep(0.7, 1.0, length(v_uv));
// Pulsing: speed-based animation
float pulse = 1.0 + 0.08 * sin(v_speed * 3.0 + u_time * 4.0);
col *= pulse;
if (shape < 0.01) discard;
gl_FragColor = vec4(col, shape);
}Des poissons faits de maths, pas de pixels 📐
Les poissons ne sont pas des images ou des modèles 3D. Ils sont calculés par des formules mathématiques directement dans la carte graphique. Avantage : on peut les redimensionner à l'infini sans qu'ils deviennent flous. Comme des polices d'écriture vectorielles !
💼 Utilisé par les pros
Cette technique est utilisée par Figma (design vectoriel), Apple (émojis), et Valve (texte dans les jeux). C'est l'avenir du rendu graphique haute performance.
🚀 5.3 Calcul sur la Carte Graphique5.3 WebGPU Compute Pipeline
⚙️ Utiliser le GPU pour penser, pas seulement dessiner
Traditionnellement, le GPU ne fait que peindre les pixels. WebGPU permet d'utiliser ses milliers de cœurs pour des calculs généraux — comme les forces de flocking. On envoie les positions au GPU, un compute shader calcule les forces en parallèle (groupes de 64 threads), et on récupère le résultat.
Le moteur utilise le Deferred Readback : le GPU calcule la frame N pendant que le CPU dessine la frame N-1, masquant le temps de transfert. Résultat : à 100K boids, le GPU est 7× plus rapide que le CPU.
🧪 WebGPU en production : retour d'expérience
WebGPU est encore considéré "expérimental" mais fonctionne dans Chrome 113+ et Firefox Nightly. Le vrai gain : les compute shaders. Le flocking GPU tourne en ~1ms pour 100K entités (vs ~8ms en JavaScript pur). C'est un gain de 8×.
Le piège principal : la synchronisation. Envoyer des données au GPU → calculer → relire les résultats prend ~2ms d'overhead. Si le calcul dure moins de 2ms, le GPU est contre-productif. C'est pour ça qu'on ne l'active qu'au-delà de 50K entités.
Buffer Layout
positions: Float32 × 4 (x,y,vx,vy) par boid. forces:
Float32 × 2
(fx,fy) output. params: uniforms (weights, radii, dt).
grid: spatial
hash pour voisinage O(K).
Dispatch Strategy
Workgroup size = 64. Dispatches = ceil(N/64). À 100K boids = 1875 dispatches. Exécution ~4ms sur GPU mid-range. Async readback <= 1 frame de latence.
Double Buffering
Deux snapshots de forces (SnapA, SnapB) tournent en ping-pong. Quand un nouveau résultat arrive, SnapA ← SnapB, SnapB ← nouveau. Permet l'extrapolation entre dispatches.
// WebGPU Compute Shader — Flocking Forces (simplifié)
@compute @workgroup_size(64)
fn flockCompute(@builtin(global_invocation_id) id: vec3u) {
let i = id.x;
if (i >= params.boidCount) { return; }
let pos = positions[i].xy;
let vel = positions[i].zw;
var sep = vec2f(0.0); var align = vec2f(0.0); var coh = vec2f(0.0);
var count: u32 = 0;
// Spatial hash neighbor query
let cell = worldToCell(pos);
for (var dx = -1; dx <= 1; dx++) {
for (var dy = -1; dy <= 1; dy++) {
let nc = cell + vec2i(dx, dy);
let start = gridOffset[cellIndex(nc)];
let end = gridOffset[cellIndex(nc) + 1];
for (var j = start; j < end; j++) {
let ni = gridBuf[j];
if (ni == i) { continue; }
let npos = positions[ni].xy;
let diff = pos - npos;
let dist = length(diff);
if (dist < params.radius) {
sep += diff / (dist * dist + 0.001);
align += positions[ni].zw;
coh += npos;
count++;
}
}
}
}
if (count > 0) {
align = align / f32(count) - vel;
coh = coh / f32(count) - pos;
}
forces[i] = sep * params.wSep + align * params.wAlign + coh * params.wCoh;
}✅ Speedup Factor
À 100K boids : 7× plus rapide sur GPU. À 200K : >6.8×. Le GPU scale linéairement grâce à la parallélisation massive (1875 workgroups × 64 threads = 100K threads simultanés).
Processeur classique
1 calculateur très intelligent fait les poissons un par un → 8 millisecondes
Carte graphique
Des milliers de mini-calculateurs font TOUS les poissons en même temps → 1 milliseconde
🎯 5.4 Transitions Visuelles Douces5.4 Système de Transition LOD Anti-Popping
⚙️ Transitions fluides entre niveaux de détail
Quand un poisson passe de "petit point" à "forme détaillée", la transition doit être invisible. Le système utilise une interpolation douce et une marge de sécurité (hystérésis) pour éviter les « sauts » visuels désagréables.
🧪 Le anti-popping en production
Le popping est le bug de LOD le plus courant en jeu vidéo. La solution est simple en théorie (hystérésis ±10%) mais subtile en pratique : il faut gérer le cas où un poisson traverse la frontière en diagonale (il peut rester bloqué entre 2 LOD).
La solution : un smooth blend sur 0.2 secondes dans le fragment shader. Pendant la transition, les deux LOD sont rendus avec des opacités complémentaires. C'est invisible pour le joueur et élimine 100% du popping.
screenSize = fishWorldSize × zoom / viewportHeight
hystérésis : LOD↑ si size > threshold × 1.1 ; LOD↓ si size < threshold × 0.9
| Propriété | LOD Micro | LOD Dot | LOD Line | LOD Triangle | LOD Full |
|---|---|---|---|---|---|
| Taille écran | < 2px | 2-4px | 4-6px | 6-10px | > 10px |
| Instructions GPU | ~3 | ~8 | ~15 | ~25 | ~80 |
| Nombre de shapes | 0 | 1 (ellipse) | 1 (segment) | 1 (triangle) | 3 (body+tail+dorsal) |
| Shading | Non | Glow simple | Alpha fade | Gradient | Specular + edge |
| Animation | Non | Non | Non | Non | Pulsation vitesse |
| Coût relatif | 1× | 3× | 5× | 8× | 26× |
💡 Distribution LOD typique (zoom standard, 100K boids)
~70% micro (hors écran ou < 2px) · ~15% dot · ~8% line · ~5% triangle · ~2% full SDF. Résultat : le coût GPU effectif est ~5× moins que si tout était rendu en full LOD.
Des transitions invisibles 🎭
Quand un poisson s'approche, il passe du "point simple" au "poisson détaillé". Mais cette transition doit être invisible. Le système fait un fondu progressif entre les deux niveaux, comme un morphing. Vous ne le remarquez jamais !
Ce qu'il faut retenir
100 000 poissons dessinés en une seule commande GPU grâce au rendu instancié. Chaque poisson est unique (28 gènes) mais le coût de rendu est presque fixe. Le système LOD à 5 niveaux économise 90% du calcul graphique sans perte visuelle perceptible.