Simulation · s'appuie sur l'étape 5
L'étape 5 en posait trois. Et mille ? La question paraît bête — elle contient toute la performance en 3D.
Les deux volets affichent exactement les mêmes cubes, aux mêmes endroits, avec
le même mouvement. À gauche un Mesh par cube, à droite un seul
InstancedMesh. Comparez les compteurs, pas les images : elles sont
identiques.
Mesh déclenche un appel de dessin : le processeur doit
parler à la carte graphique, lui donner une matrice, un matériau, un état. Mille
cubes = mille conversations. C'est le processeur qui étouffe, pas la carte
graphique — qui, elle, s'ennuie.
InstancedMesh, c'est un seul ordre pour tout le lot. On
envoie la géométrie une fois, plus un tableau de matrices, et la carte graphique
dessine les mille copies toute seule. Le compteur passe de mille à un.
Regardez-le.
setMatrixAt) et une couleur (setColorAt) — rien d'autre.
Une instance n'est pas un objet : elle n'a ni position, ni enfant, et
on ne peut pas la cliquer sans travail supplémentaire.
setMatrixAt, il faut
instanceMatrix.needsUpdate = true. Sans ça, rien ne bouge et l'on
cherche pendant une heure. C'est le prix de la performance : Three.js n'a aucun
moyen de savoir que vous avez touché le tableau.