Dacota3D : simulateur de conduite

Le simulateur de conduite à la MEGAfin de concevoir ce simulateur de conduite, nous avons du :

  1. faire le choix d'un cadre de travail (voir partie choix du frameworks)
  2. définir un environnement virtuel de simulation (voir partie construction de l'espace urbain).
  3. mettre en place un système de gestion des scenarii (voir partie Modèle de gestion des scenarii) & agréger des contenus (pour la liste voir Dacota Source)

Choix du framework

Pour l'élaboration d'un simulateur de conduite, nous avons le choix entre les types d'outils suivants:

Dans le dernier cas (les jeux de conduite), il n'est pas possible de réaliser un simulateur autonome, il s'agit de dériver un simulateur existant vers les attendus du projet. Cette dérivation est limitée par les possibilités de développement offertes par le programme (qui peut aller de la simple customisation du véhicule à la réalisation d'un scénario).

Quel que soit l'outil pour conduire le projet, le framework doit inclure :

  • un moteur physique incluant les effets physiques spécifiques aux véhicules (adhérence/frottement des pneus, force de torsion, inertie, etc.).
  • un moteur de rendu graphique 3D prenant en compte un langage de shaders.
  • un moteur de rendu audio 3D (spatialisation du son, atténuation suivant la distance, effet Doppler, etc.).
  • un moteur d'intelligence artificielle (recherche de chemin, prise de décision, etc.).
  • une gestion des personnages (animation comportementale des personnages : c.-à-d. marcher, courir, s'arrêter, etc.)
  • un framework de développement accessible & complet (c.-à-d. utilisation d'un langage de programmation standard comme C++ qui donne accès à l'ensemble du moteur).
  • une interconnexion avec les équipements MEG via port parallèle et serveur via socket TCP/IP.

Dans le cadre du projet Dacota, nous avons testé les environnements suivants :

  • Ogre (moteur graphique - open source) : la compilation devient vite compliquée lors de l'intégration d'autres éléments (Audio AL, ODE, etc) néccessaires à la réalisation d'un simulateur. Ogre est avant tout un moteur graphique 3D et ni un moteur de simulation, ni un moteur de jeu.
  • Delta 3D (système de simulation - open source) : difficulté de compilation due à la complexité de l'architecture (inclusion de nombreuses librairies qui en fait sa richesse).
  • ArcSim (simulateur de conduite) : modèle de conduite très abouti qui comprend un des rares moteurs d'I.A. spécifique à la simulation de conduite (modèlisation du comportement de conduite des autres agents), gestion des scenarii d'expérimentation, pas de gestion des personnages, moteur de rendu basique.
  • Deep Creator/Esperient Creator (plateforme de création 3D) : il ets potentiellement très fort pour la restitution en temps réel de scènes complexes. Il ne pose pas de problèmes de conversion de fichiers dus à la technologie de Right Hemisphre. Pour la physique il repose sur le moteur Newton. Nous avons manqué de temps pour le tester pleinement, mais il aurait certainement pu être retenu.
  • Virtools (plateforme de création 3D) : c'est un environnement complet pour la simulation (avec notamment un moteur d'IA inclus), mais il était trop onéreux pour le projet.
  • Quest3D (plateforme de création 3D) : il est doté d'une grande qualité de rendu, avec l'intégration d'un moteur d'effet météorologique. Pour la physique il repose sur le moteur Newton. C'est un environnement de développement très particulier dont la gestion du code n'est pas forcement très lisible.
  • Conitect A6 - Game Studio (moteur de jeu) : il a posé des problèmes lors de l'intégration de la maquette urbaine (problème de texture et de performance avec des scènes complexes, sur la version A6).
  • Trynigy (moteur de jeu) : classé parmi les game-engine utilisés pour les jeux de qualité professionnelle. Il a une très grande qualité de rendue, mais il était trop onéreux pour le projet.

Finalement, nous avons retenu Unity 3D qui est un moteur de jeu pour les raisons suivantes :

  • Unity 3D est un des Game-Engine les plus récents dont la qualité de programmation est indéniable et qui se présente comme très prometteur.
  • Environnement multiplateforme : Mac, PC, Web, iPhone, Wii. Même si pour le projet actuel, la question de la portabilité multiplateforme n'était pas un critère, on peut néanmoins noter que la réalisation d'un logiciel qui cross-compile sur plusieurs plateformes implique une bien plus grande complexité de programmation et donc un certain niveau dans le développement du logiciel de la part de leurs auteurs.
  • Il présente une grande facilité de prise en main grâce à l'exploitation du look & feel (l'apparence et le ressenti) de Mac OS X.
  • La programmation est possible en temps réel (pas de phase de compilation complète pour agir sur le déroulement du programme).
  • La facilité d'utilisation du moteur physique basé sur Ageia PhysX (devenue Nvidia PhysX) est appréciable. Il est probable qu'à terme Unity 3D, pourra utiliser un processeur physique pour accélérer les calculs.
  • Communauté non négligeable de développeurs.
  • Livrée avec un jeu de shader assez exhaustif.
  • Possibilité de développer simultanément en plusieurs langages (C++, javascript, C#, etc.).
  • Coût très accessible, pour un game-engine de cette qualité.
  • Point négatif : il n'y a aucun moteur d'IA, ni d'embryon pour en concevoir un.

La construction de l'environnement urbain

La production d'un environnement urbain a été un véritable enjeu pour la réalisation du simulateur. Par environnement urbain, on entend une agglomération dans laquelle le sujet va effectuer la tâche de conduite. Classiquement, dans les simulateurs on en retrouve deux types :

  • Example de Ville-CircuitLes Villes-Circuits : le milieu est constitué d'un axe principal sur lequel sont repartis les bâtîments et des éléments d'illustration sur le bas côté (généralement sous la forme d'un simple ensemble de plan 2D). Ces villes sont proches d'un décor de cinéma, dans lequel seul sont pris en compte les objets qui vont être directement inclus dans le champ de vision. Le sujet évolue dedans comme dans les petits trains touristiques, en suivant un parcours prédéfini. Il ne peut donc pas sortir de la ligne tracée dans l'environnement. Ces environnements sont souvent utilisés pour les jeux de course de voiture. (ci-contre exemple d'un circuit urbain - source : HalukTorun / Turbo Squid)
     
  • Exemple de ville géométriqueLes Villes-Géométriques : Ce sont des villes inspirées des agglomérations américaines où les rues sont constituées d'arêtes rectilignes, parallèles entre elles ou qui se coupent à angle droit. Ce type de bâti est souvent utilisé car facile à construire. Il peut également être géré sous la forme de blocs que l'on ajoute ensuite ensemble pour former la ville à la manière d'un jeu de Lego. (Ci-contre exemple d'un milieu urbain subdivisé en blocs - sources DAVO / 3Dwarehouse).

Dans ces types d'environnement, on rencontre deux problèmes :

  • Dans le cas des villes-circuits, une fois le circuit accompli, il n'y a plus de possibilité d'avoir d'autre parcours dans la ville, si ce n'est la réutilisation de ce même circuit en plantant un décor différent. La simulation se résume donc à faire des tours de circuit.
  • Les villes-géométriques correspondent au type de réseau routier que l'on rencontre aux États-Unis ou dans les villes nouvelles, c'est-à-dire à un réseau routier rationnel où les intersections sont prédictibles (alternance de tronçons rectilignes et de carrefours). Ces deux types d'environnement ne correspondent donc pas à la représentation que l'on a d'une agglomération de type européenne.

Pour construire des villes dans le style européen, il serait toujours possible d'avoir recours à la méthode classique de design 3D, i.e. un dessin entièrement réalisé à la main. Cette méthode présente l'inconvénient d'être longue et fastidieuse, avant d'obtenir une large zone urbaine. La solution est donc d'avoir recours à des systèmes de création automatique ou semi-automatique d'environnement urbain que l'on peut classer en deux types de systèmes :

  1. Les systèmes génératifs ou systèmes procéduraux vont construire un environnement urbain à partir de règles.
  2. Les systèmes de reconstruction 3D obtenus à partir d'une analyse de l'espace.

Les systèmes procéduraux

Exemple de modélisation procéduraleCe type de système peut être considéré comme un changement de paradigme dans la création d'objets et donc de scènes 3D. Traditionnellement un objet 3D est considéré comme une forme géométrique décrite soit sous une forme polygonale (i.e. un ensemble d'arrêtes, de sommet qui forme des faces), ou de NURBS (Non-uniform rational B-spline, c'est-à-dire d'une fonction mathématique permettant de décrire des courbes et des surfaces). Dans les systèmes procéduraux, l'idée est de représenter des objets 3D par une succession d'opérations à partir de primitives simples.

Un exemple très simple (voir image ci-contre) est celui d'une plaque de métal avec 4 trous dedans. On peut, soit décrire cet objet avec un ensemble de polygones (i.e. un ensemble de facettes), soit de façon procédurale en posant que Plaque_Avec_4_Trous = 1 parallélépipède rectangle - 4 cylindres. C'est-à-dire prendre une primitive géométrique de type parallélépipède rectangle et lui soustraire 1 primitive cylindre en 4 endroits différents. Ici, nous avons utilisé les opérations booléennes pour composer un nouvel objet à partir d'autres objets.

On voit donc l'intérêt d'une telle approche pour la construction d'environnement urbain où l'on rencontre énormément d'éléments récurrents (par exemple dans une façade d'immeuble l'élément fenêtre va se répéter de façon constante). Les systèmes procéduraux utilisent principalement les techniques suivantes souvent de façon conjointe :

  • Les grammaires génératives comme les L-System.
  • Les grammaires d'opération.
  • Les systèmes multi-agents.
  • Le bruit de Perlin.
  • Les algorithmes de placement.

Les systèmes procéduraux pour la génération d'environnements urbains les plus connus sont : CityEngine, pCity, CityGen, GML (Generative modeling Language) et Cities Core (modéles multi-agent). On trouvera sur cette page une liste plus compléte. Pour la génération d'environnements les plus connus sont : Grome, Bryce, Terragen, 3DNature, Trian3D Builder.

anAlyse de l'Espace

À l'inverse des systèmes procéduraux qui tendent à reproduire la réalité par des algorithmes génératifs, les systèmes d'analyse de l'espace, tendent à reconstruire la réalité par reconnaissance, analyse et extraction de caractéristiques. De tels systèmes s'apparentent donc plus à une activité de numérisation de la réalité. Les étapes classiques de cette reconstruction sont :

  • Acquisition d'un modèle numérique de terrain (MNT) : le but des MNT est d'avoir une représentation numérique de la topographique d'un terrain, via la mesure de son altimétrie. On doit distinguer le relevé d'altimétrie (ou bathymétrique, c.-à-d. mesure des profondeurs) qui correspond au terrain naturel du relevé altimétrique avec les éléments artificiels comme les bâtiments, les ponts, etc.
  • Acquisition d'un modèle numérique d'élévation (MNE) : dans un relevé altimétrique d'un terrain, le MNE, va permettre de séparer les éléments artificiels des éléments naturels, en ne donnant que l'élévation des éléments artificiels comme les bâtiments par rapport à la référence du terrain. Dans un milieu urbain, on va principalement relever la hauteur de faîtage (c.-à-d. des toitures).
  • Extraction des zones : à partir des deux modèles (MNT & MNE), il va être nécessaire de segmenter l'espace urbain, pour en extraire ses zones. Il s’agit de récupérer non seulement le bâti (empreinte au sol des bâtiments), les réseaux routiers (les tronçons et leur type), la couverture végétale, les réseaux hydrographiques. Pour faire cette extraction, on recourt généralement, soit à un relevé direct sur le terrain, soit à des techniques de télédétection et d'analyse multi spectrale (acquisition d'une image sur plusieurs longueurs d'onde ; par exemple, une image en infrarouge va permettre de séparer des zones d'activité, comme des bâtiments ou des usines du reste). Par ailleurs, dans une analyse aboutie, on arrive à obtenir des cartes thématiques des types de zones (zone d'habitation, industrielle, commerciale, etc.).
  • Extraction des détails et des objets : la dernière étape va consister, d'une part, à obtenir l'habillage des différents éléments, cela va être classiquement l'image des façades des bâtiments, les textures des voiries, etc. et, d’autre part, la distribution des objets composant le milieu, comme le mobilier urbain, la signalétique (panneaux, feux, etc.), les arbres, et les détails des surfaces (aussi bien les hauteurs de trottoirs, les remblais, etc. que des détails architecturaux).

Pour des exemples de réalisations on peut se référer à :

L'environnement utilisé pour Dacota 3D

La maquette Urbaine de VienneDans le cas de Dacota, nous avons utilisé une maquette urbaine issue d'un travail Michael Wimmer & Peter Wonka (1998-2003, Real-time Rendering of Urban Environments) qui modélise une aire urbaine de 2 km/2 km d'un quartier de Vienne en Autriche. Leurs travaux se fondent, à la fois, sur un système d'analyse spatiale (construction du réseau) et d'un système génératif (grammaire générative pour la construction des bâtiments).

Tout d'abord, pour générer le réseau routier, ils partent de l'empreinte au sol des bâtiments, dont ils effectuent une triangulation de Voronoy entre les bâtiments, pour obtenir l'axial et les intersections des routes.

À partir de cette triangulation, ils utilisent un agent constructeur qui va inspecter chaque axe pour, d'une part, supprimer toutes les sources de brisure et, d'autre part, construire la radiale du réseau (construction des trottoirs, du marquage au sol, des passages piétons, des zones de stationnement). Pour la construction des bâtis, ils utilisent une grammaire générative proche des L-System, pour produire ce qu'ils désignent par de « l'architecture instantanée ». Dans le cas de Dacota, nous n’avons pas utilisé cette construction, car trop gourmande en termes de performance (nous avons gardé le bâtî uniquement sous une forme volumétrique).

Dans les images ci-dessous on peut voir comment la génération du tissu urbain se fait (pour voir l'animation aller dans la section vidéo). Pour concevoir cette construction, nous avons utilisé un modèle de calcul inspiré des ordinateurs chimiques. Les ordinateurs chimiques sont des machines qui utilisent des règles de réactions moléculaires, pour produire des calculs. Au départ, simple curiosité, les ordinateurs chimiques ont l'avantage de pouvoir facilement réaliser des opérations sur l’espace, comme la triangulation de Voronoy.

Dans le modèle d'évolution ci-dessous, nous avons remplacé chaque bâtiment par une substance chimique (étape 1). Ensuite, nous laissons cette substance se diffuser et réagir quand elle rentre en contact (étape 2 : formation d'un précipité). Puis, nous répétons l'étape 2 mais, cette fois, en utilisant aussi une substance qui se diffuse à partir des axes obtenus dans l'étape précédente. À partir des zones ainsi délimitées (étape 3), nous procédons à une simple extrusion 3D des bâtiments et des trottoirs (étape 4). Il ne reste plus qu’à appliquer des textures aux objets (étape 5) et à placer les autres objets le long des axes (étape 6).

Génération urbaine : étape 1 Génération urbaine : étape 2 Génération urbaine : étape 3 Génération urbaine : étape 4 Génération urbaine : étape 5 Génération urbaine : étape 6
Etape 1
Empreinte au sol
des batîments		 Etape 2

Génération
des axes		 Etape 3
Génération
des radials		 Etape 4


Extrusion 3D		 Etape 5

Habillage 2D		 Etpae 6
Placement
des objets 3D

La gestion des scenarii

La dernière étape pour réaliser le simulateur fut donc la création et la gestion des scenarii. La maquette urbaine de Vienne d'une dimension d'environ 2 km/2 km permettait de définir une vingtaine de parcours. Un scénario comprend les éléments suivants :

  • Un parcours dans la maquette urbaine : les parcours sont définis par une succession de panneaux, donnant les indications d'orientation. Il indique une direction (tourner à gauche ou droite) seulement quand le véhicule s'en approche à moins de 31 mètres. Par défaut, les panneaux blancs n’indiquent pas de changement de direction.
  • Feux de signalisations : par défaut les feux sont tous au vert. Une partie des feux (environ 50 %) passe à l'orange quand le sujet s'en approche à moins 27 mètres.
  • Éléments de décor : comme le mobilier urbain, des véhicules en stationnements, des piétons, des éléments de végétation. Ces éléments changent à chaque nouveau trajet.
  • Véhicules en circulation.
  • Des événements dits spéciaux se déclenchent quand le sujet s'en approche. Le simulateur contient 6 événements particuliers : 2 ballons qui déboulent devant le véhicule, 2 piétons qui traversent brutalement devant le sujet, 1 véhicule qui sort de son stationnement, 1 véhicule qui grille un feu.

Dacota 3D : carte des scénariosLa préparation des scenarii a été faite avec un SIG (système d'information géographique). Le SIG permettait de positionner quatre couches d'informations sur la carte de Vienne :

  • la position des objets points comme les arbres, les lampadaires, les fontaines, etc.
  • la position des objets ligne comme les voitures, les abris bus, les bancs, etc.
  • les chemins des véhicules et des piétons en mouvement.
  • les panneaux de direction et les feux de signalisation avec leur type (avec ou sans déclenchement).

Pour la simulation en temps réel du trafic des véhicules et des piétons, nous avions au départ utilisé des algorithmes de steering (via la bibliothèque openSteer de Craig W. Reynolds), qui permet de modéliser des comportements intelligents. Le problème rencontré est que, pour un même scénario, le sujet n'était pas forcement confronté exactement à la même situation, du fait que les véhicules et les piétons pouvaient choisir des trajectoires différentes. Nous avons donc remplacé le comportement intelligent, par un comportement asservi, où les véhicules et les piétons suivent un trajet prédéfini en boucle.

Par ailleurs, pour ne pas influencer le sujet dans ses décisions :

  • Le trafic a été limité à quelques agents (une cinquantaine), pour donner une constance dans le temps, le comportement des agents ne commence que quand le sujet s'en approche à moins de 150 métres (entre temps ils sont dans un état d'attente).
  • Pour éviter que le sujet ne puisse se répérer dans la ville, en reconnaissant des lieux où il serait passé dans un scénario précédent, l'ensemble des façades a été uniformisé.

Une fois les scénarios préparés dans le SIG, on procède à un export des positions, orientations et types de chaque objet dans un fichier de traçage et, grâce à ces fichiers de description, le simulateur crée une scène graphique. En somme l'expérimentateur dispose d'un catalogue d'objet 3D et de leur comportement qu’il lui suffit de définir dans le SIG. À partir de celui-ci, le simulateur crée la scène graphique et programme le comportement des éléments.

De ce point de vue, le simulateur est générique puisqu'il permet, sans reprogrammation, de composer toutes sortes d'environnements virtuels de simulation, à partir du fichier de description.

Dans le cadre de l'expérimentation, un test de mémoire implicite était effectué à la fin de la passation. On donnait au sujet un exemplaire modifié du catalogue, en lui demandant s'il avait vu ou non tel ou tel objet (certains objets apparaissaient fréquemment, d'autre une seule fois et d'autres jamais).

Pour plus d'informations, on peut télécharger le catalogue de Dacota 3D (PDF - 660 Ko), le livret de passation (PDF - 260ko) et une capture du SIG (PDF - 1.5 Mo).

Schémas de principe

Ci dessous deux schémas : le premier montre l'organisation du framework, le deuxième le déroulement de l'expérimentation. C'est deux schémas sont téléchargeable dans un document PDF (3 Mo).

Dacota drive : framework du simulateur de conduite Dacota Drive : déroulement de l'expérimenation du simulateur de conduite

Dacota source

Ci-dessous, la liste des éléments qui ont servis pour réaliser ce simulateur.

Environnement Urbain

Pour ce simulateur, nous avons utilisé la maquette urbaine produite dans le cadre du projet "Real-time Rendering of Urban Environments" (1998-2003) conduit par Michael Wimmer & Peter Wonka.

La maquette originale peut être télécharger ici. Des captures d'écran sont visibles ici.

Logiciels

Game engine : Unity 3D.

Gestion des cartes : ArcGIS, QGis, ET Geo-Tools.

Modeleurs : 3ds Max, Sketchup.

Génération Skybox : Terragen.

Convertisseur de fichier : Deep Exploration.

Création de mouvement : Poser.

Traitement audios : Audacity, Loop Editor.

Gestion des enregistrements (Dacota Master) : Borland C++ Builder, PortIO (dll pour accéder directement à un port LPT).

Montage vidéo : Apple Final Cut Studio.

   

Sources de données

Véhicules : Sugard 3D & 3D Wharehouse.

Arbres : unitree.

Personnages : aXYZ design.

Mobiliers urbains : 3D Wharehouse.

Textures : Dosh Design & CG Textures.

Skybox : Terragen.

Mouvement des personnages : free BVH files.

Sons : Sounddogs, Kill the silence.

Autres sources : Turbo Squid.

Liens

1. Pour une liste des simulateurs de conduite on peut consulter cette page de l'INRETS.

2. Pour les moteurs de jeu et de simulation, on trouve une base de données très complète le site de Devmaster (Your source for 3D Game and Graphics Engines), ainsi que sur cette page de Wikipedia.

 

© 2011/2013 - Gérald Foliot