etude bibliographique : ogre 3d

ETUDE BIBLIOGRAPHIQUE DU MOTEUR : OGRE 3D
Date :
1er Avril
Crée-le :
22/03/2010
Mis à jour le :
09/04/2010
Version :
2.0
Objets :
Présentation du moteur 3D Ogre3D
1
Sommaire
Introduction .............................................................................................................................................. 3
1. Moteur 3D ......................................................................................................................................... 3
2. Présentation générale du moteur OGRE 3D........................................................................................ 4
3. Architecture logiciel d’OGRE 3D ...................................................................................................... 4
4. Les différents formats gérés par OGRE.............................................................................................. 6
5. Les outils utiles .................................................................................................................................. 6
6. Fonctionnement d’OGRE 3D ............................................................................................................. 7
7. Architecture programme .................................................................................................................... 8
8. Fonctionnalités d’Ogres ..................................................................................................................... 9
9. Les principaux modules (add-ons) & plugins ................................................................................... 12
10. Récapitulatif : .................................................................................................................................. 13
11. Applications utilisant OGRE 3D....................................................................................................... 14
12. Sources............................................................................................................................................. 15
2
Introduction
Projet initialement monter par Steve Streeting en 2001 ; OGRE : "Object-Oriented Graphics
Rendering Engine" (Moteur de rendu Graphique Orienté-Objets) est un moteur 3D libre,
multiplateforme et gratuit qui permet, à partir d'objets à facettes, de réaliser un environnement en
3D. OGRE est une surcouche utilisant les APIs Direct3D et OpenGL, qui permet l'utilisation des
cartes accélératrices 3D. Grace à une participation active de la communauté, OGRE a aujourd’hui
atteint une certaine maturité. Il commence même à être utilisé pour des projets professionnels (ex :
l’INIRA pare l’équipe REVES).
1. Moteur 3D
Un moteur 3D est un composant logiciel qui crée des images à partir de coordonnées
tridimensionnelles. Généralement les moteurs 3D sont intégrés dans les moteurs de jeu. Le moteur
de jeu inclut également un moteur physique, de son…Dans notre cas, OGRE est un moteurs 3D
indépendant mais il fournit des moyens (par des plugins) permettant de l’associer à d’autres
moteurs.
Lors de l’affichage d’une scène en 3D (=le rendu), un moteur
3D peut adopter différents procédés permettant un rendu
2D dans la fenêtre de visualisation :
-
-
La rastérisation est le procédé le plus utilisé pour la
simulation (utilisé par OGRE) et permet de garder
un flux de traitement constant en temps réel. Les
objets sont représentés sous forme de triangles.
Lorsque les coordonnées 2D des triangles sont
connues, la carte graphique les transforme en un
ensemble de pixels, puis calcule la couleur de chaque
pixel individuellement. L'utilisation de shaders
permet de modifier les différentes étapes du rendu,
dans le but d'ajouter des effets graphiques
personnalisés (voir Fig.1 ce contre).
Le ray tracing permet d'obtenir une image photo
réaliste. Plus gourmand, il est utilisé pour réaliser
des images fixes et des films d'animation.
Afin de profiter de l'accélération matérielle, les moteurs 3D (comme OGRE) utilisent les
bibliothèques logicielles telles que DirectX ou OpenGL. Cela permet d’utiliser le processeur
graphique pour « décharger » le CPU de certaines taches et donc lui permettant de gérer d’autres
calculs issus des autres moteurs par exemple.
Voici quelques exemples de moteur 3D : (cf. Fig2)
3
2. Présentation générale du moteur OGRE 3D
Le moteur d’OGRE 3D est programmé en C++. Il est multiplateforme donc est utilisable sur
Windows, Linux et Mac OSX avec une légère prédominance (optimisations) pour Windows car la
majorité des applications graphiques (commerciales ou non) sont faites pour fonctionner sous
Windows
avec
DirectX.
Il nécessite une bonne maitrise de la programmation C++ (C# ou Python via des plugins), d’avoir des
notions dans les graphismes 3D (pour pouvoir manipuler les fichiers et scripts) et de la patience pour
le prendre en main car Ogre est complet et présente une multitude de possibilités (apprentissage
long). Il convient pour des projets ayant des besoins d’affichage 3D haute performance avec un taux
de rafraichissement relativement élevé.
Ogre est sous License LGPL. Rédigée par la Free Software Foundation, la licence GNU LGPL
(Lesser General Public Licence) s'avère moins contraignante que la classique GPL. Elle n'oblige pas
à communiquer les sources d'un programme propriétaire qui utilise des bibliothèques LGPL. Ce
caractère non héréditaire des licences LGPL est très apprécié des laboratoires de recherche et des
sociétés commerciales. En revanche, comme pour la GPL, l'utilisateur a le droit d'utiliser les
bibliothèques LGPL à condition de ne pas dériver du code source original. S'il modifie le code
d'origine, il est conseillé de reporter les modifications auprès de la communauté.
3. Architecture logiciel d’OGRE 3D
Comme le montre la Fig.3 ci-dessus, le .exe générer par OGRE à l’issu de la compilation s’appui sur
les liens vers le dossier media contenant toutes les ressources (textures / matériels / sons / scripts…).
Les fichiers .cfg indiques à l’exécutables les différentes possibilités d’exécution da l’application
(utilisation de plugins, de DirectX ou de OpenGL, du plein écran, de la résolution…).
Lors
de
l’exécution
de
l’application,
les
librairies
d’entrées/sortie
(périphériques
clavier/souris/joystick), d’OGRE et des plugins seront surement sollicitées.
4
Une application OGRE à besoin de fichiers media contenant les textures et les scripts, d’un fichier
ressource contenant le chemin vers les médias, ainsi que d’un ensemble de librairies. Parmi ces
librairies, on trouve les plugins, les librairies internes à OGRE (OIS) et la librairie principale
d’OGRE : OGRE Main. En voici une liste :
 OgreMain.dll :
Librairie de base contenant toutes les fonctions pour le fonctionnement du moteur. Doit être
présente dans toutes les applications Ogre.
 Plugin_BSPSceneManager.dll :
Librairie plugin contenant l'ensemble des fonctions pour faire fonctionner des cartes de type BSP
(spécifique a Quake3). Elle est optionnelle selon la configuration. C'est un « manager » optimisé pour
les rendus en intérieur utilisant des cartes au format BSP. Il gère très bien les géométries
d'intersections (murs, couloirs...). Fichiers utilisés compatibles avec des éditeurs de niveaux. La
gestion optimale du BSP commence à disparaître sur les cartes graphiques modernes.
 Plugin_CgProgramManager.dll :
Librairie plugin et de liaison permettant l'utilisation de CG par Ogre. CG est un « langage » de
programmation de graphismes proche de C développé par Nvidia. Pour plus de renseignements vous
pouvez trouver des renseignements sur le site Nvidia dans la partie développeur. Optionnelle si vous
ne comptez pas utiliser CG.
 Plugin_OctreeSceneManager.dll :
Librairie plugin proposant le SceneManager principal utilisé par Ogre. Elle est optionnelle mais il
est conseillé de l'utiliser car elle remplace et améliore très bien le rendu générique d'Ogre. Mode de
gestion utilisant une organisation particulière (octree) qui divise la scène en plusieurs parties et
augmente les performances par rapport au rendu générique. Permet d'utiliser la classe «
StaticGeometry » permettant d'accélérer les grandes scènes avec des « géométries immobiles ». Cette
classe est supportée par les cartes graphiques récentes.
 Plugin_ParticleFX.dll :
Librairie plugin permettant la génération et la gestion des particules. Optionnelle si vous n'utilisez
pas d'effets de particules.
 RenderSystem_Direct3D9.dll :
Librairie contenant les fonctions pour une gestion des rendus via DirectX. Nécessaire uniquement si
votre application tourne sous Windows et propose des performances très élevées par rapport a
OpenGL. Attention elle est prévue pour DirectX version 9!
 RenderSystem_GL.dll :
Librairie contenant les fonctions pour une gestion des rendus via OpenGL. Ce rendu est universel, il
marche sous Windows, Linux et MacOs. Optionnelle si vous comptez uniquement faire tourner votre
application sous Windows avec DirectX.
 OgreGUIRenderer.dll :
Librairie de liaison avec l'ensemble CEGUI qui permet un affichage de menus dans le rendu Ogre.
Uniquement nécessaire si vous comptez intégrer des menus CEGUI dans votre application.
 cg.dll :
Librairie permettant l'utilisation du langage Cg de Nvidia par Ogre. Doit être présente si vous
utilisez Plugin_CgProgramManager.dll.
 CEGUIBase.dll :
Comme indiqué, c'est la libraire de base pour les affichages de type CEGUI. Optionnelle si vous
n'utilisez pas CEGUI.
5
4. Les différents formats gérés par OGRE
 Mesh :
Fichier binaire spécifique à Ogre contenant l'ensemble des informations pour créer une entité
graphique. Il contient la position de tous les pixels et triangles à générer par le moteur. Ce fichier
est obtenu à partir d'un fichier xml (état intermédiaire) qui provient d'une exportation d'un
programme d'édition graphique tel que 3DSMax, Cinema 4D, Blender, etc....
 Skeleton :
Fichier binaire spécifique à Ogre contenant l'ensemble des informations pour gérer les animations
d'un mesh. Toutes les animations sont contenues de ce fichier et ce dernier est lié au mesh du même
nom. Ce fichier est obtenu à partir d'un fichier xml (état intermédiaire) qui provient d'une
exportation d'un programme d'édition graphique tel que 3DSMax, Cinema 4D etc....
 Material :
Fichier « script » écrit en C-like qui permet de lier un mesh à une texture et d'intégrer des effets et
manipulations sur celle-ci. On peut trouver plusieurs « materials » dans un même fichier pour des
meshs différents (la référence est contenue dans le fichier binaire mesh). Il est possible d'écrire
directement un programme graphique a l'intérieur mais pour plus de clarté il est préférable
d’appeler des fichiers programmes a part.
 Program :
Fichier « script » permettant à plusieurs materials d'appeler des fonctions communes évitant ainsi
de réécrire plusieurs fois le même code.
 Particle :
Fichier « script » permettant de créer des effets de particules (pluie, neige, feu....).Les paramètres
possibles pour ce type de fichier sont énormes et il est préférable de se tourner vers l'éditeur
graphique proposé sur le site d'Ogre pour la création de particules.
5. Les outils utiles
 XmlConverter :
Ce petit programme permet de transformer un fichier XML provenant d'une exportation d'un
éditeur graphique 3D en mesh, material et skeleton. L'inverse est aussi possible.
 MeshUpgrader :
Petit programme permettant de mettre à jour vos fichiers 3D (mesh et skeleton) si l'organisation
binaire de ces derniers change suite a la sortie d'une nouvelle version d'Ogre.
 MaterialUpgrader :
Comme pour MeshUpgrader mais uniquement pour les materials.
6
6. Fonctionnement d’OGRE 3D
 Ressource :
OGRE utilise beaucoup de fichiers annexes, comme les modèles des objets 3D ou les textures. Il est
nécessaire de lui indiquer dans quels répertoires il doit chercher les différentes ressources. Pour
cela, plusieurs fichiers de configuration doivent être créés et analysés lors du chargement de
l’application.
 Objet racine :
La première chose à réaliser pour une application OGRE est de créer un objet racine. Cet objet est la
base de l’application, car tous les autres objets lui seront rattachés et il ne sera instancié qu’une
seule fois.
 Choix du système de rendu :
Il faut ensuite choisir le mode d’affichage, le type de rendu (Direct3D ou openGL), la résolution et
autres paramètres graphiques parmi ceux supportés par la machine.
 Scène :
Une scène dans OGRE est un élément qui va contenir des éléments graphiques. Elle comporte une
hiérarchie similaire aux arbres : une racine « mère » à laquelle va se rattacher d’autres objets, qui
pourront à leur tour devenir parents. Un objet parent transmet certaines données à tous ses fils.
Ainsi, un enfant nouvellement créé sera positionné dans la scène par rapport aux coordonnées de
son parent. De même, une transformation de type translation, rotation ou redimensionnement se
répercutera sur tous les fils d’un objet. L’inverse n’est cependant pas vrai : un fils subissant une
transformation ne la communique pas à son parent.
 Nœuds et Entités :
Un élément important du fonctionnement d’OGRE est le lien entre les nœuds et les entités. Une
entité est un élément graphique chargé ou généré. Il contient donc l’objet à afficher, la texture
associée, ainsi qu’une possible animation. Néanmoins, il est impossible de l’utiliser tel quel. Il doit
être associé à un nœud de la scène, qui contiendra toutes les informations nécessaires à son
affichage, notamment sa position dans la scène. Toutes les transformations que doit subir l’objet
doivent être appliquées au nœud auquel il est rattaché. Un nœud peut posséder plusieurs entités, en
revanche une entité n’a qu’un seul nœud.
 Camera et point de vue :
Une fois les objets graphiques correctement chargés, il faut décrire la portion de scène à afficher.
Autrement dit, un point de vue doit être spécifié à l’application, grâce à l’ajout d’une caméra dans
celle-ci. La camera va nous permettre de voir nos objets, de changer l’angle de vue ou encore la
distance. Elle doit être associée à un nœud de la scène (attention, une camera n’est pas une entité,
les lumières et les particules non plus), et peut changer dynamiquement de nœud, ce qui permet de
changer d’angle de vue durant l’exécution. Plusieurs caméras peuvent rendre différents points de
vue à l’écran simultanément : le cas le plus courant est l’écran « splitté » (divisé en deux).
 Boucle d’événement :
Une fois que tous les objets OGRE sont initialisés, il faut lancer la boucle d’évènements. A chaque
tour de cette boucle, les événements sont captés et traités et, en fonction des traitements ainsi fait,
on calcule l’image à afficher. Lorsque cette boucle est interrompue, volontairement ou non dans le
cas d’une erreur du programme, l’application se termine.
7
7. Architecture programme
Pour le rendu de la fenêtre, il existe une classe abstraite 'RenderWindow', puis pour le rendu dans
Windows, par exemple, une sous-classe 'Win32Window' implémente les fonctions de 'RenderWindow'
en
spécifiant
le
rendu
des
fenêtres
sur
une
plateforme
Win32.
Pour la gestion des objets 3D, il y'a la classe 'SceneManager' qui gère le positionnement des objets
3D dans la scène et la façon dont ils sont rendus. Les applications n'ont généralement qu'a utiliser
cette classe et OGRE trouvera la meilleure façon de gérer la scène, mais si vous voulez un rendu
encore plus optimisé, il existe par exemple la classe ' BspSceneManager' (vue plus haut) qui offre un
affichage optimisé pour les scènes en intérieur de type BSP (type de format Quake3).
Voici un diagramme UML (cf. Fig. 4) schématisant le 'noyau' (core object) d'OGRE et qui montre les
relations entre les différentes classes.
8
8. Fonctionnalités d’Ogres
 Affichage 3D :
OGRE gère divers formats d’objet, qui peuvent être préalablement modélisés sous différents
logiciels, open source ou payant, tels que 3DStudio Max, Blender, Maya, Wings3D, etc.
Il offre de nombreuses fonctions afin de gérer ces objets : déplacement, rotation, agrandissement… Il
est également possible, généralement dans le but de débugger une application, d’afficher les
polygones qui composent l’objet Cf. Fig. 5 et 6.
 Animations :
OGRE supporte différent type d’animations :
Les animations de type « squelettes » sont prévues dès la modélisation de l’objet. Les
mouvements sont préalablement créés par le designer et exportés dans un fichier. Ogre se
contentera dans ce cas de charger ce fichier, et de lancer la ou les animations choisies.
Il est également possible de programmer des animations directement à l’aide d’OGRE. En
effet, il suffit d’indiquer à un objet un mouvement (translation, rotation …), ainsi que le temps qu’il
lui est accordé pour effectuer ce mouvement. Le moteur se chargera d’approximer la position de
notre objet à chaque actualisation de la scène.
 Éclairage
OGRE offre quatre types d’éclairage pour les scènes finales (à noter que la couleur de la lumière est
laissée à l’appréciation du développeur) :
La lumière ambiante : toutes les faces des objets sont éclairées de manière uniforme et
équitable. Cf. Fig. 7
Point : la lumière est envoyée dans toutes les directions, à partir d’un point précis. Cf. Fig. 8
Spot : lumière de style « lampe torche », qui comporte donc une direction et un halo de
lumière en cône. Cf. Fig. 9
Directionnel : simule un point lumineux étant situé à une distance infinie de la scène, ce qui
équivaut à notre soleil. Cf. Fig. 10
Fig. 7: Ambiante
Fig. 8: Point
Fig. 9: Spot
Fig. 10 : Directionnel
9
 Ombrage :
Il existe également plusieurs sortes de rendus d’ombres dans OGRE :
Texture Modulative : crée une texture en noir et blanc appliquée à la scène, en tenant compte
seulement une seule source de lumière. Cf. Fig. 11
Stencil Modulative : calcule toutes les ombres de la scène, de toutes provenances, puis
l’applique sur le rendu. Cf. Fig. 12
Stencil additive : calcule chaque ombre séparément puis les fusionne sur la scène. Cette
dernière technique s’avère être la plus réaliste mais également la plus coûteuse en terme de
traitement et de calculs. Cf. Fig. 13
Fig. 11: Texture-modulative Fig. 12: Stencil-modulative
Fig. 13: Stencil-additive
 Terrains
Le sol peut-être modélisé préalablement comme tous les objets de la scène, ou bien être
généré à la volée. Dans ce dernier cas, apporte une gestion des « heightmaps », ou terrains nivelés. Il
s’agit de terrains calculés en temps réel à partir des pixels d’une image en niveau de gris. Plus la
couleur du pixel se rapproche du blanc, plus la portion correspondante du terrain sera élevée en
hauteur. On peut ainsi obtenir deux cents cinquante-six (256) variations d’altitude pour un seul
terrain.
Voici une image heightmap en niveau de gris (cf. Fig. 14) et le rendu sur OGRE (cf. Fig. 15)
(la texture a été rajouté pour bien illustrer les différences de niveau du terrain, elle n’est pas gérée
par la heightmap)
Fig. 14: image en NdG
Fig. 15: rendu du relief associé à l’image 14
10
 Ciels :
Les Skybox : le principe de la « boîte à ciel » est simple. La
caméra se trouve à l’intérieur d’un cube auquel on a appliqué
une texture représentant le ciel. La difficulté majeure étant de
faire correspondre les textures entre elles pour que l’utilisateur
ait l’impression d’avoir un ciel ouvert au dessus de lui. cf. Fig. 16
Les Skydomes : idem que la skybox, à l’exception près que la
texture est projetée de manière sphérique à l’intérieur du cube.
L’utilisateur a ainsi l’impression d’être sous une voûte céleste.
Les Skyplanes : tout simplement un plan situé au dessus de la
caméra auquel est appliquée une texture de ciel. Principalement
utilisé dans des environnements clos mais à ciel ouvert : par
Fig. 16: Rendu du ciel (« plafond »)
exemple, l’enceinte d’un château.
 Effets Visuels :
OGRE offre également de nombreux outils afin de rendre à l’écran des effets visuels très
différents les uns des autres :
OGRE propose une gestion de particules personnalisable à volonté au travers de fichiers
configurables, dans un format spécifique. De nombreux paramètres sont pris en compte pour obtenir
l’effet escompté. Ainsi, seuls quelques chiffres différencient des particules de fumée, de pluie ou
d’étincelles. cf. Fig. 17
Il est à noter qu’OGRE dispose nativement d’un effet de brouillard, utilisable grâce à un simple
appel de fonction.
Un shader est un ensemble d’instruction permettant d’utiliser la carte graphique au lieu du
processeur. Les shaders permettent de décrire les réflexions, l’absorption et la diffusion de lumière
(etc etc). Ces programmes sont gérés dans OGRE par le biais de fichiers écrit dans le langage Cg
développé par nVidia. Voici quelques exemples de possibilités qu’offrent les shaders. cf. Fig. 18-19
Le Cel-Shading est un shader qui se place complètement dans le cadre du rendu non photoréaliste, et emprunte quantité de caractéristiques à l’univers de la bande dessinée. L’effet est
composé de textures vives, basées sur une palette de couleurs restreintes, auquel est appliqué un
ombrage gradué en niveau de gris. Ensuite, un trait cerné foncé est utilisé sur les contours du
modèle, ce qui accentue leur aspect cartoon. cf. Fig. 20
Le Cube Mapping est une technique permettant de créer un effet de réflexion de textures
environnantes et de ce fait, d’obtenir un objet de style miroir. cf. Fig. 21
Fig. 18-19 : Shader
Fig. 20 :Cel-Shading
Fig. 21: Cube Mapping
Fig. 17: Particules
11
9. Les principaux modules (add-ons) & plugins
La communauté très active d’OGRE s’est illustrée par le développement de plugins qui, sans être
absolument obligatoires, fournissent des fonctionnalités assez intéressantes.
 CEGUI (Crazy Ed' Graphical User Interface) :
Librairie Open Source permettant de faire des interfaces de très bonne qualité pour toutes vos
applications graphiques. CEGUI est intégré par défaut à OGRE car il est lui aussi très bien
documenté et pensé de la même façon.
 PaggingLandscapeSceneManager2 (PLSM2) :
Plugin très performant gérant l'affichage de très grande étendues avec des reliefs et textures varié
grâce a une technique de pagination des textures. Ce plugin permet aussi de modeler en temps réel
des terrains et bien d'autres choses encore.
 OgreNewt :
'wrapper' de la librairie 'Newton Dynamic' permettant une gestion de la dynamique dans les
applications graphiques utilisant OGRE. Il existe beaucoup d'autre libraire dynamique pour OGRE,
notamment OgreODE ou encore NxOgre 'wrapper' de 'Novodex Physics'.
 OFusion :
Logiciel s'intégrant a 3DSMax, c'est un véritable WYSIWYG qui offre un rendu OGRE sous 3DS et
permet aussi l'export de matériaux et d'animation pour les utiliser sous OGRE. Bien sûr, des
exporteurs sont fournis pour d'autres modeleurs (Blender, Maya, Wings3D, MilkShape...) mais
oFusion est un peu plus qu'un exporteur.
 PyOgre :
Les commandes Ogre ont été 'bindés' en Python pour fournir une plate-forme de scripting
performante. Le scripting peu aussi s'effectuer en LUA ou en Squirrel, mais pour l'instant le python
est le seul langage pour lequel les fonctions on toutes été bindées.
 OgreDotNet :
Permet de programmer de applications OGRE en VB.NET, C# et autres langage .NET.
Remarque : OgreDotNet est un plugin pour Ogre3D qui permet de programmer en C# des
applications mais la base du moteur est toujours en C++. En clair vous éditez du C# qui contrôle des
fonctions C++. A la différence que Axiom est le moteur Ogre3D mais totalement réécrit en C# : c'est
un portage. Avec Axiom vous n'utiliser que le C#!
 DotScene :
Format de fichier basé sur le XML permettant la sauvegarde et le chargement de configuration de
scène, idéal pour des éditeurs de niveaux.
 ShowMesh :
Show Mesh est un viewer d'objets utilisant Ogre et Qt. Il permet de jouer avec la lumière, les ombres
le brouillard, etc.
 Ogrefsrad :
Outil permettant d'utiliser la radiosité de Fluid Studios' fsrad
 TheoraVideoPlugin Player :
Ce plugin permet d’appliquer une vidéo à la place d’une texture sur la ou les faces d’un objet. Ce
plugin ne gère qu’un seul format vidéo, l’Ogg-Vorbis. La vidéo est décrite dans un fichier texte, fort
utile puisqu’il permet d’effectuer des modifications de manière très rapide.
12
 Hikari :
Il est possible d’intégrer du flash dans une application OGRE. Cette
librairie permet de faire un menu en flash, ou encore de pouvoir jouer
une animation à la place d’une texture (de la même manière que le
Fig.22: Hikari
plugin précédent). Cf. Fig. 22
 PagedGeometry :
Pour le rendu des terrains, il existe des plugins permettant de générer
des forêts sur de très grandes zones. Il fournit une solution hautement
optimisée pour le rendu de zones massivement boisées, pouvant contenir
plusieurs millions d’arbres, arbustes, ou herbages de toutes sortes.
PagedGeometry utilise une méthode de génération dynamique. C'est-àdire qu’il ne va pas générer tous les objets mais seulement ce qui est
Fig.23: PagedGeometry
nécessaire. Cf. Fig. 23
10.
Récapitulatif :
Ogre, c’est 1015010 lignes de code (en juin 09), 18 développeurs et 33 contributeurs. C’est un projet
enregistré sous Source Forge (partage de grands projets professionnels) en Février 2000 et élu en
Mars 2005 projet du mois.
 Les avantages du moteur Ogre-3D
- Multiplateforme, le même code sur les plateformes Windows, Linux et Mac OSX ;
- Utilise les APIs DirectX et OpenGL ;
- Performant au niveau des rendus ;
- Flexible, Ogre peut "facilement" être modifié ou on peut rajouter "facilement" des plugins ;
- Support du site officiel performant, vous aurez toujours une réponse a vos problème dans la journée
suite a votre post sur le forum ;
- Qualité de développement professionnel ;
- Ogre est sous License LGPL donc Open Source et gratuit ;
 Les désavantages du moteur Ogre-3D
- Prise en main difficile nécessitant quelques mois de préparation ;
- Organisation du projet Ogre complexe, difficulté pour prendre ses marques ;
- Problème de mise à jour des informations sur le wiki Ogre ;
 Fonctions avancées :
Matériaux/shaders :
-Langage de description de matériaux permettant leur gestion en dehors du code source de
l'application ;
-Support des vertex et fragment programs (shaders) en assembleur, HLSL (DirectX), GLSL
(OpenGL) et Cg (DirectX/OpenGL) ;
-Multitexturage, rendu en passes multiples ;
-Support des textures PNG, JPEG, TGA, BMP, DDS et DXT/S3TC ;
-Support des textures modifiables en temps-réel (pour la vidéo notamment) ;
Modèles :
-Interfaçage avec de nombreux outils 3D : Blender, Wings3D, 3D Studio Max, Maya, Milkshape3D;
-Animation squelettique par images-clés, gestion des transitions entre animations ;
-Support des patches de Bézier pour les surfaces courbes ;
-Support des modèles progressifs (LOD : level of détail) ;
13
Scènes :
-Système flexible et hautement configurable de gestion de scènes, non lié à un type de scène unique ;
-Plugins supportant divers types de scènes : BSP, Octree, Terrain, Nature, Paging ;
-Gestion des scènes sous forme de scène graph hiérarchique ;
-Support des ombres portées : shadow mapping, stencil shadows.
Effets spéciaux :
-Système de particules, qui peut être géré dans des fichiers textes sous forme de scripts ;
-Gestion du « pooling » de particules pour obtenir les meilleures performances ;
-Support des skyboxes, skyplanes et skydomes pour le rendu du ciel ;
-Support des billboards (images 2D toujours orientées vers l'observateur) ;
-Gestion automatique de la transparence des objets (ordre de rendu et gestion du depth buffer).
Divers :
-Système commun de gestion des ressources pour la gestion de la mémoire et le chargement de
données à partir d'archives (ZIP, PK3) ;
-Architecture basée sur les plugins permettant d'étendre le moteur en évitant la recompilation ;
-Gestionnaire de mémoire permettant d'identifier les memory leaks en mode debug ;
-Fournis avec de nombreux exemples mettant en œuvre les différentes fonctionnalités de l'API et
montrant l'interfaçage avec d'autres librairies (notamment ODE pour la physique/collision) ;
11.
Applications utilisant OGRE 3D
L’essentiel des applications utilisant OGRE 3D sont des visites virtuelles / des mini jeux / ou des
outils de visualisation interne aux entreprises.
Exemple :
La séries " Ankh".
"Jack Keane".
"Pacific Storm".
"Rigs of Rods".
"Torchlight".
« L'Inria (Institut national de recherche en informatique et en automatisme) mixte dans ses projets
de recherche outils propriétaires, commerciaux et open source. Son équipe Reves (Rendu et
environnements virtuels sonorisés) de Sophia-Antipolis a ainsi décidé, fin 2004, de remplacer son
moteur 3D interne devenu obsolète par un logiciel libre, Ogre3D. »
Logiciels :
Ogitor est un Module d'extension gratuit basé sur le modèle WYSWYG (what you see is what you
get) et utilisant le moteur 3D d’Ogre combinée avec l’interface graphique Qt. Il permet la création
facile de scènes qui peuvent être chargées dans une application OGRE.
Le principal interet d'Ogitor est sa flexibilité. En effet, il permet d’intégrer des Modules d'extensions
personnalisés par les utilisateurs. Cela permet le l'addition de nouvelles caractéristiques à Ogitor
sans en changer le cœur (ajout du son, de la physique…).
Les fichiers son au format *.ogscene mais il est possible d’importer ou d’exporter sous le format
*.scene (le même que celui d’Ogre).
OpenSpace3D est un projet libre d’utilisation pour le développement de projet 3D temps réel et
interactif utilisant le moteur 3D Ogre.
OpenSpace3D aide au développement de nouveaux environnements 3D dans le domaine du travail
collaboratif (des réunions éloignées, webconferences), de l’éducation (salle de classe virtuelle,
serious-Game et E-learning), la simulation, l'innovation, le commerce électronique… Les fihiers sont
au format *.XOS, il est possible d’importer des *.Scene et d’exporter des *.scol et *.scolweb.
14
12.
Sources
[INTERNET]
[INTERNET]
[INTERNET]
[INTERNET]
[INTERNET]
[INTERNET]
[INTERNET]
[INTERNET]
[Document .docx]
[LIVRE]
http://www.futurn.net
http://www.ogre3d.org
http://ogre3d.fr
http://www.developpez.net
http://loulou.developpez.com/tutoriels/moteur3d/partie8/
http://www.slideshare.net/tuankuranes/ogre-3d-une-introduction
http://www.ogitor.org/
http://www.openspace3d.com/
http://ter-rible.googlecode.com/files/Fonctionalit%C3%A9s_Ogre.docx
Pro OGRE 3D Programming – Gregory Junker – Apress
15