Stellantis · Stage R&D · 2026
Le brief portait sur une seule voiture, vue de l’intérieur et de l’extérieur, en VR. La physique fait bouger une voiture de façon naturelle, mais la calculer pendant le rendu dans un casque coûte trop cher. Ma réponse : calculer la physique une seule fois, écrire le résultat dans la scène sous forme d’animation USD et laisser la VR le rejouer. Le projet est passé d’une seule voiture à du trafic, et un scénario se résume à trois entrées : un itinéraire dessiné en vue de dessus, une vitesse cible et l’endroit où s’arrêter.
Chaque méthode habituelle pour faire bouger une voiture répondait à l’un de ces besoins et échouait sur un autre.
L’animation sur trajectoire était construite et fonctionnelle. La physique en temps réel était l’amélioration évidente. Le précalcul (bake) était l’idée qui conservait les atouts des deux et en supprimait les coûts.
| Critère | Option AAnimation sur trajectoire, en temps réel | Option BPhysique, en temps réel en VR | Option C · le choixPhysique, précalculée en USD |
|---|---|---|---|
| Mouvement | Approximé. L’inclinaison et la plongée sont ajoutées par-dessus. | Naturel | Naturel, enregistré à partir de la simulation |
| Coût pendant le rendu VR | Faible | Trop lourd | Faible. Les poses stockées sont rejouées. |
| Hauteur de l’itinéraire | À ajuster à la route | La physique trouve la route | La physique trouve la route |
| Se rejoue sans l’outil | Non | Non | Oui. Elle fait partie de la scène. |
| Verdict | Léger, mais le mouvement est approximé | Naturel, mais trop lourd pour un casque | Naturel, léger et rapide à configurer |
La physique est calculée une seule fois, pendant la construction du scénario, hors du casque. La simulation est écrite dans la scène sous forme d’animation USD : une pose stockée par image pour la carrosserie, les roues et la direction. En VR, ces poses sont seulement rejouées. Le casque n’exécute jamais de simulation.
Une vidéo du trajet figerait la caméra. USD conserve le trajet sous forme de mouvement dans la scène 3D, si bien qu’on peut s’asseoir dans la voiture et regarder où l’on veut. USD est aussi le format de scène ouvert sur lequel repose Omniverse, donc le mouvement est une donnée de la scène, au même titre qu’un modèle ou un matériau. Une seule simulation physique devient ainsi un asset.
Dans une simulation physique, le travail est partagé en deux. Le scénario décide où va la voiture, à quelle vitesse et où elle s’arrête. La physique décide de ce que la route lui fait subir. L’itinéraire n’a jamais à suivre la hauteur de la route, seulement sa forme vue du dessus. Personne ne l’ajuste aux pentes, aux sommets de côte ni aux creux, si bien qu’un nouvel itinéraire se dessine vite.
L’auteur du scénario règle une seule vitesse et place un seul panneau. Le freinage avant le virage et le sommet de côte, l’arrêt, l’attente et le redémarrage en découlent tous.
Le moteur de scénarios construit et précalcule les trajets. Le lecteur transforme les trajets précalculés en trafic en VR. Ils ne se rejoignent que dans l’USD précalculé, si bien que chacun peut évoluer de son côté tant que le fichier reste stable.
J’ai cadré le problème, choisi l’approche, planifié les étapes, développé les deux extensions et rédigé les guides. Chaque étape s’est terminée par une version qui tournait dans Omniverse et qui a été vérifiée dans la scène. Le périmètre ne s’est élargi qu’une fois l’étape précédente stabilisée.
Il me revenait de proposer le périmètre, et à l’équipe métier de l’accepter.
Ce cas décrit l’approche de manière générale. Le code, les scènes et les résultats internes du projet appartiennent à Stellantis.
Contact