PROBLÉMATIQUE GRAPHIQUE

Nous avions à répondre à deux exigences graphiques divergentes : l’une adaptée à un traitement en temps réel, l’autre fournissant un rendu de type photoréaliste. Nous avons choisi de séparer les deux approches.

(mpeg4, 1,4 Mo)		Une approche en OpenGL
		OpenGL ne propose pas de système de particules préconstruit, mais fournit tous les composants permettant de les programmer. Le site de NeHE propose des tutoriaux OpenGL portés dans différents langages. L'un d'eux présentait une “fontaine de lumière”, dont le résultat était assez éloigné d’un effet pyrotechnique réaliste. Mais les particules le constituant étaient, elles, assez convaincantes. Il nous a semblé que partir de ce système serait plus rapide que programmer un système de particules ex nihilo, pour tenter d'obtenir un résultat satisfaisant.

Les API

Java 3D , API Java basée sur DirectX ou OpenGL, est bien entendu portable sur toutes les plateformes ; elle est capable d’intégrer des objets modélisés en VRML, mais le fait d’ajouter une couche applicative au-dessus d’OpenGL peut générer un ralentissement préjudiciable aux performances souhaitées.

L’abandon de Java 3D nous laissait le choix entre DirectX ou OpenGL pour profiter de l’accélération matérielle des cartes graphiques. La limitation de DirectX à l’environnement Microsoft nous a fait opter pour OpenGL, moins dépendant du système d’exploitation.

OpenGL , API graphique de bas niveau développée depuis 1992 par Silicon Graphics, a été créée pour le développement d’application 2D et 3D indépendantes de la machine et du système d’exploitation, dans une philosophie client-serveur de type X Window. Ouverte, portable, dédiée temps réel, sans commande de fenêtrage ni saisie utilisateur, elle est le “langage assembleur” du graphisme sur ordinateur.

GÉNÉRATION DE PARTICULES

Applets Java

On peut trouver dans les pages web des exemples de simulation de feux en Java. Certains sont rudimentaires, d’autres sont graphiquement plus convaincants.
On retiendra le remarquable travail de Kei Yuasa sur PyroWeb : depuis 1995, il poursuit un développement dont la progression – variété des formes et maniabilité d’interface – est plus orientée vers la reproduction de l’effet pyrotechnique que vers une représentation graphique poussée. Les réalisations de Koji Yamamoto « Time Tripper » séduisent par leur aspect visuellement très abouti, mêlant une luminescence diffuse à l’effet gravitationnel. Signalons aussi le site Waku Waku , où l’auteur fournit les sources de ses applets.

Logiciels 3D

C’est dans les applications de synthèse 3D que la simulation d’une grande diversité d’explosions et de masses fluides d’étincelles est systématiquement proposée. Au-delà de la difficulté de naviguer dans un environnement complexe – qui donne à manipuler des domaines aussi divers que le modelage, l’éclairage, l’animation et le texturage, dans un espace scénique autorisant plusieurs points de vue –, on accède à la figuration d’effets pyrotechniques comme une des fonctionnalités de base des systèmes de particules.

Blender, logiciel libre de création 3D, souffre d’une interface peu intuitive jusque dans le maniement de la souris. Il dispose pourtant d’atouts qui ont su séduire la communauté des utilisateurs et des développeurs : léger, gratuit, portable, scriptable en Python, il intègre toutes les composantes qui vont de la modélisation au rendu, auxquelles s’ajoute un moteur de jeu temps réel.
Son système de particules – qui exige un rendu pour exprimer la couleur – n’est pas utilisable pour un emploi en temps réel.

Moteurs de conception de jeux

L’univers du jeu vidéo, important consommateur d’effets d’explosions, de feu, de pluie, de fumée, fait grand usage des moteurs de particules pour reproduire ces phénomènes physiques complexes, afin d’obtenir une qualité visuelle sans perte de fluidité. Nous ne devions donc pas négliger les logiciels de conception de jeu, en évaluant leurs capacités de fenêtrage et leurs modules de gestion d’événements sonores.

Renderware, peut-être le meilleur moteur 3D temps réel, dispose d’un système de particules généraliste ; les temps de calcul que nous avons relevés étaient de 438 fps pour 40 particules actives et de 140 fps pour 1 000 particules. L’environnement de développement en C, avec une API sans interface graphique, implique un long temps d’apprentissage, mais avec la possibilité d’ajouter des bibliothèques tierces à celles fournies en standard. Son coût d’utilisation commerciale est élevé (15 000 €/an/poste/jeu).

Virtools nous a paru souple d’utilisation, grâce à l’emploi, accessible à des non-programmeurs, d’éléments de construction intégrant des comportements. Mais nous n’avons pas trouvé de réponse spécifique pour la conception des fenêtrages et les systèmes de particules.