Du scan 3D au média serveur : la chaîne complète

Le modèle 3D qui sort d'un scan et le modèle 3D qu'un média serveur accepte de faire tourner en temps réel, c'est rarement le même fichier. Entre les deux il y a une chaîne : nuage de points, mesh retopologié, dépliage UV, export au bon format, import, puis calage du modèle virtuel sur l'objet réel. Ce guide décrit cette chaîne de bout en bout, dans l'ordre où je la fais, avec les endroits précis où elle casse.

Je cale des shows sur média serveur Modulo depuis quinze ans, et je forme dessus depuis 2017 (formateur certifié Modulo Pi, plus de 250 serveurs déployés). Le passage scan vers serveur, c'est le maillon que personne ne documente. Les tutos s'arrêtent à l'export du mesh. Or c'est précisément entre l'export et le premier warp que se perdent les nuits.

La chaîne, dans l'ordre où elle tient

Un objet réel à mapper, un serveur qui doit projeter dessus au pixel près. Voilà les étapes, sans en sauter une :

1. Scan de l'objet ou du lieu, par scan 3D ou photogrammétrie, qui produit un nuage de points
2. Mesh reconstruit depuis le nuage : dense, lourd, inexploitable tel quel en temps réel
3. Retopologie : un maillage propre, léger, avec une topologie que le serveur peut afficher à 60 images par seconde
4. Dépliage UV : la surface du mesh mise à plat, pour savoir où chaque pixel de la vidéo atterrit sur l'objet
5. Export au format que le serveur lit, à la bonne échelle et à la bonne orientation
6. Import dans le média serveur, alignement du modèle virtuel sur l'objet réel, puis warp et calage

Les étapes 1 à 4 sont du travail de studio. À partir de la 5, la moindre erreur se paie sur site, la nuit, avec le camion déjà à moitié rangé. C'est pour ça que la partie export mérite plus d'attention qu'on ne lui en donne.

Export : l'échelle, l'orientation et le pivot cassent tout

Trois pièges, toujours les mêmes, au passage entre deux logiciels.

L'échelle. Blender pense en mètres, un scan peut sortir en centimètres ou en unités arbitraires, et un FBX ne transporte pas toujours l'unité proprement. Résultat classique : le modèle arrive dans le serveur cent fois trop grand ou cent fois trop petit. Vérifie l'échelle sur une dimension connue avant d'exporter. Si ton objet fait 4 mètres de haut en vrai, il doit faire 4 unités dans le serveur, pas 400.

L'orientation. Chaque logiciel a son axe vertical. Blender travaille en Z-up, la plupart des moteurs temps réel et des serveurs attendent du Y-up. Un FBX exporté sans conversion d'axe arrive couché sur le flanc. Ça se corrige en deux clics quand on sait où regarder, et ça fait perdre une heure quand on ne sait pas.

Le pivot. Le point d'origine du modèle, c'est le point autour duquel il tournera et par lequel il se positionnera dans la scène du serveur. Un pivot laissé au hasard par le logiciel de scan, et ton modèle atterrit à dix mètres de là où tu l'attends, ou pivote autour d'un coin. Place le pivot à un point de repère physique que tu pourras retrouver sur le vrai objet : un coin, une arête, la base au sol.

Sur le format lui-même, le débat FBX contre OBJ est plus simple qu'il n'en a l'air. Ton logiciel de reconstruction propose souvent une longue liste : RealityScan exporte dans une quinzaine de formats, dont OBJ, FBX et GLB (RealityScan, Model Export, consulté le 09/07/2026). Ne garde que celui que ton serveur lit. OBJ est statique, universel, sans animation : parfait pour un objet figé à mapper. FBX transporte plus (hiérarchie, animation, pivots) mais transporte aussi plus d'occasions de casser. Je pars sur OBJ quand le modèle ne bouge pas, sur FBX quand j'ai besoin de la hiérarchie ou d'objets animés.

Import dans le média serveur

Côté serveur, la liste des formats acceptés est courte, et c'est voulu. Pixera, par exemple, documente noir sur blanc qu'il ne lit que GLTF, FBX et OBJ (Pixera, Models, consulté le 09/07/2026). Modulo Kinetic, le média serveur sur lequel tournent mes gros projets, importe le modèle 3D directement dans sa scène et te laisse projeter dessus avec un pipeline de rendu complet. Le point commun de tous les serveurs sérieux : ils veulent un mesh propre, pas la soupe de triangles qui sort d'un scan brut.

Une fois le fichier importé, la vraie question n'est plus technique, elle est géométrique : faire coïncider le modèle du serveur avec l'objet posé devant toi.

Aligner le modèle virtuel sur l'objet réel

C'est le cœur du métier, et aucun export propre ne le fait à ta place. Le serveur affiche ton modèle 3D. Le projecteur, lui, éclaire un objet réel dans l'espace. Tant que les deux ne coïncident pas au pixel, l'image glisse sur les arêtes.

Ma méthode sur site :

• Je repère quatre à six points de correspondance sur l'objet réel, des points nets et non alignés : coins, angles saillants, jonctions
• Je place la caméra virtuelle du serveur à la position réelle du projecteur, throw ratio et lens shift compris
• J'ajuste jusqu'à ce que les points du modèle tombent sur les points physiques, vus depuis l'axe du projecteur
• Je vérifie avec une mire de contour projetée sur les arêtes réelles : si le trait suit l'arête, le calage tient ; s'il bave, un point est faux

Un modèle bien retopologié et bien exporté rend cette étape rapide. Un modèle sale la rend impossible : tu passes la nuit à te battre contre une géométrie qui ne correspond à rien de mesurable.

Pourquoi un mesh trop lourd plombe le temps réel

Un scan brut, c'est des millions de polygones. Un média serveur doit tenir 60 images par seconde en projetant dessus, souvent sur plusieurs sorties en même temps. Les deux ne sont pas compatibles.

Un maillage trop dense fait chuter le framerate, sature la mémoire de la carte graphique, et rend le calage saccadé au point d'être imprécis. La réponse n'est pas d'acheter une machine plus grosse. La réponse est en amont : un mesh retopologié à quelques dizaines de milliers de polygones bien placés rend mieux, et plus vite, qu'un scan à deux millions de triangles. Tout est dans le guide retopologie. Si tu sautes cette étape pour gagner du temps, tu le repaieras sur site avec intérêts.

Prévoir tout ça avant le montage

Toute cette chaîne se teste avant que le premier projecteur soit loué. Poser le modèle scanné dans une scène 3D, y placer les projecteurs, vérifier la couverture et les recouvrements, valider que l'objet est mappable depuis les positions d'accroche prévues : c'est exactement ce pour quoi j'ai construit Lumeo. Le modèle issu du scan s'y importe, et l'étude se partage par lien avant qu'une seule machine bouge.

Quand ce n'est pas la peine de passer par un modèle 3D

Le workflow scan vers serveur coûte du temps. Il ne se justifie pas toujours.

• Surface plane ou quasi plane. Une façade droite, un mur, un écran : pas besoin de modèle 3D. Un warp 2D et un bon jeu de mires font le travail en une fraction du temps
• Géométrie simple et connue. Un cube, un cylindre, une forme primitive dont tu as les cotes : reconstruis-la à la main dans le serveur en dix minutes. Scanner un cube pour le retopologier ensuite, c'est se donner du travail pour rien
• Un seul projecteur, un seul point de vue. Si le public ne voit l'objet que d'un côté, le calage 2D depuis ce point de vue suffit souvent. Le modèle 3D se justifie quand plusieurs projecteurs couvrent plusieurs faces
• Le budget couvre le matériel mais pas les heures de studio. Retopologie et dépliage UV propres prennent du temps qualifié. Si ce temps n'est pas dans le devis, le modèle 3D restera sale, et sale il ne servira à rien

Une fois le modèle importé et grossièrement aligné, tout ce qui reste (warp fin, blend, couleur, uniformité) relève de la calibration proprement dite. La méthode complète part du guide de calibration projecteurs.

Et si tu es devant un objet scanné, un FBX qui refuse de se caler et un show dans trois jours, c'est en général l'échelle ou le pivot. Vérifie ces deux-là d'abord. Si le doute survit, écris-moi : j'ai déjà fait la plupart de ces erreurs, souvent deux fois.