OGRE (Object-Oriented Graphics Rendering Engine) est un moteur de rendu 3D écrit en C++, qui permet de développer des applications en exploitant au maximum les possibilités d'accélération matérielle des cartes graphiques 3D. OGRE fonctionne sous MS Windows, MacOS et Linux et supporte les API Direct3D et OpenGL.
Cette nouvelle version propose essentiellement des corrections de bugs par rapport à la RC1 sortie quelques semaines plus tôt. Cette dernière apportait notamment des améliorations au niveau des systèmes de particules et de gestion de ressources ainsi que l'ajout du support des hardware pixel buffers et du rendu HDR (High Dynamic Range). L'interface graphique utilisateur s'était vue supprimée au profit d'un projet externe beaucoup plus complet : CEGUI. Un article de 8 pages en français sur OGRE est récemment paru dans le magazine Software 2.0, dans son numéro de février dédié à la programmation de jeux vidéo. Voir : http://www.software20.org/fr/
Il est aussi à noter que OGRE utilise des tests unitaires via cppunit pour certaines de ses fonctionnalités ;)
OGRE supporte de nombreuses fonctionnalités 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 et bientôt Softimage|XSI ;
- animation squelettique par images-clés, gestion des transitions entre animations, weight skinning, skinning hardware ;
- support des patches de Bézier pour les surfaces courbes ;
- support des modèles progressifs (LOD : level of détail).
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 scene 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 oeuvre les différentes fonctionnalités de l'API et montrant l'interfaçage avec d'autres librairies (notamment ODE pour la physique/collision) ;
- fourni avec un outil permettant la conversion entre les formats binaires optimisés utilisés par OGRE et les formats d'échange et de stockage en XML utilisés par les outils de création.
Aller plus loin
- Site officiel (4 clics)
- ChangeLog (0 clic)
- Fonctionnalités (1 clic)
- OGRE Wiki! (2 clics)
- Copies d'écran (3 clics)
- Site français dédié à OGRE (en panne) (11 clics)
# python
Posté par blobmaster . Évalué à 4.
http://www.ogre3d.org/wiki/index.php/PyOgre(...)
# support linux?
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
Et quand on voit d'autres moteurs comme irrlicht qui n'ont qu'un support vraiment basique sous linux, ça donne presque envie de dévellopper sous windows.
[^] # Re: support linux?
Posté par pepp . Évalué à 2.
Perso ça fait 2 ans que je m'amuse avec, et au niveau perf c'est très très proche entre windows et linux (et jusqu'à ya pas longtemps j'avais une ati + fglrx).
[^] # Re: support linux?
Posté par tuan kuranes (site web personnel) . Évalué à 4.
Et meme plus, avec le support AMD64 sous linux. (sous debian:attention il y a un probleme avec la libpng, si le post sur la liste debian n'a pas corrige le probleme cf http://www.ogre3d.org/phpBB2/viewtopic.php?t=6624&start=50(...))
Apres ta carte video et ton driver supporte plus ou moins la 3d...
(Ogre ne fait pas d'emulation logicielle de la 3d)
[^] # Re: support linux?
Posté par Frédéric Lopez . Évalué à 2.
Seule la version 0.15.2 est disponible par contre, la dernière version n'a pas encore été packagée.
Sinon, l'auteur du package maintient également d'autres packages liés à OGRE (CEGUI et Cg), disponibles sur son site : http://people.debian.org/~fog/(...)
[^] # Re: support linux?
Posté par Frédéric Lopez . Évalué à 2.
deb http://people.debian.org/~fog/ogre(...) unstable main
Pour avoir un environnement de développement complet, il faut taper :
apt-get install libogre-dev ogre-tools ogre-doc blender-ogrexml ogre-plugins-cgprogrammanager nvidia-cg-toolkit
Les deux derniers paquets ne sont pas libres et ne seront pas dans sid.
Des paquets pour CEGUI 0.2 (interface graphique utilisée par une démo de OGRE) et OgreODE (interfaçage avec la librairie physique ODE) seront disponibles très prochainement.
Un lien vers l'annonce originale (en anglais) :
http://www.ogre3d.org/phpBB2/viewtopic.php?p=58934&highlight=#5(...)
# HPB, HDR et precisions
Posté par tuan kuranes (site web personnel) . Évalué à 8.
Plus clairement il s'agit du support de textures "float" utilisables pour donner des rendu de hautes qualites (HDR).
La precision de ces textures vont aussi aider a l'utilisation des GPU comme processeur mathematiques specialises : les implementations d'IA sur GPU de Reseaux de Neurones sont de l'ordre de 10^6 noeuds et de 10^8 poids pour une conectivite moyenne de 100. (bon, le cerveaux humain, c'est 10^11 neurones et 10^15 synapses... en plus d'autres choes...)
Ogre est un moteur 3d de tres grande qualite, avec une conception vraiment bien pensee, une communaute tres active, une documentation tres complete, et en plus libre.
Ce que ne dit pas la nouvelle, c'est que ce moteur a toutes les fonctionnalites de moteurs Pro, gestion des lumieres a la DoomIII, Gestion du bump-mapping a la Unreal Engine 3, Animation de squelettes par shaders, etc...
Voire plus, grace au support de la communaute :
Differents scenemanagers adaptes selon le jeu (interieur,exteieur, villes, grand terrain, etc...) Rapports de bugs, Wiki, Forums, Contributions, patches, outils de plus en plus nombreux, et teste sur de nombreuses plate-formes (configuration machine et logicielles)
A noter , il existe une version en .Net appelee Axiom qui compile sous Mono.
[^] # Re: HPB, HDR et precisions
Posté par TImaniac (site web personnel) . Évalué à 3.
Cette version est entièrement écrite en C#, et a également donné naissance à un GDK de plus haut niveau, realmforge ( http://realmforgewiki.castlegobs.nl/index.php/Main_Page(...) ).
A noter qu'il n'y a pas de pertes de perfs en passant d'un langage natif comme C++ à une plateforme plus "friendly" comme .NET/Mono : http://realmforgewiki.castlegobs.nl/index.php/Ogre_vs._Axiom_Compar(...)
[^] # Re: HPB, HDR et precisions
Posté par Frédéric Lopez . Évalué à 5.
Il n'y a pas de pertes de performance sur les examples fournis avec OGRE, ça ne veut pas dire qu'il n'y en aura pas dans un vrai jeu. Les exemples n'ont pour but que de présenter les fonctionnalités d'OGRE et font donc essentiellement appel à la carte graphique, il est donc normal qu'on ne constate pas trop de différences en passant à un autre langage.
On peut d'ailleurs noter que les différences de résulats sont globalement marginales, sauf pour les démos Smoke et SkeletalAnimation qui sont plus demandeuses niveau processeur. Dans ces deux cas, la version C++ est sensiblement plus rapide que la version C# (presque 1.5x pour Smoke).
[^] # Re: HPB, HDR et precisions
Posté par TImaniac (site web personnel) . Évalué à 3.
Comme par hasard les différences sont marginales là où celà ne t'intéresse pas...
Si je prends Dot3Bump, j'ai un gain de 53% en C# par rapport à C++, mais bien sûr dans ton exemple qui t'intéresse et qui n'est pas marginal, on a un écart de 60% cette fois en faveur de C++...
En plus c'est marrant moi j'aurais dis que c'était la demo Fresnel qui bouffait le plus de proc...
Tu remarqueras que je n'ai pas cherché à commenter le nombre de FPS dans un premier temps en disant que telle ou telle implémentation était plus rapide, les 2 étant pour moi de même niveau.
il est donc normal qu'on ne constate pas trop de différences en passant à un autre langage.
Voilà c'est celà qu'il faut retenir.
Et tu as raison, ce n'est pas une situation réelle dans un jeu, mais si je ne m'abuse, dans un vrai jeu c'est justement la carte 3D qui va se mettre à souffrir, plus que le processeur, puisqu'on lui en demandera un peu plus, et on verra peut être encore moins la différence entr les 2 implémentations...
[^] # Re: HPB, HDR et precisions
Posté par Frédéric Lopez . Évalué à 4.
Ahem, j'avais pas vu ça, je retire ce que j'ai dit précédemment. Je comprends pas comment ça peut être possible par contre.
Dans un jeu, on fait normalement en sorte d'exploiter les deux ainsi que la bande passante mémoire au maximum. Le processeur a quand même beaucoup de boulot à faire : physique, collisions, IA, gestion du son, gestion de la visibilité (BSP, portals, octrees, etc.), transformations impossible à faire sur la carte graphique (une partie de la gestion des ombres, animation squeletique sur certaines cartes, etc.). La consommation mémoire est également un élément important.
[^] # Re: HPB, HDR et precisions
Posté par TImaniac (site web personnel) . Évalué à 3.
# Demande d'explication
Posté par bartman . Évalué à 2.
c'est ouate ?
[^] # Re: Demande d'explication
Posté par tuan kuranes (site web personnel) . Évalué à 4.
http://www.idealx.org/doc/xp-synthese.fr.html(...)
[^] # Re: Demande d'explication
Posté par Frédéric Lopez . Évalué à 4.
# Dépendance non-libre...
Posté par Glenn Y. R. (site web personnel, Mastodon) . Évalué à -1.
[^] # Re: Dépendance non-libre...
Posté par tuan kuranes (site web personnel) . Évalué à 6.
Tu peux choisir d'utiliser toute les autres formes de langages de shaders disponibles de nos jours.
( et Cg est dispo pout Mac, linux et windows, en 32 et 64 bits.)
[^] # Re: Dépendance non-libre...
Posté par tuan kuranes (site web personnel) . Évalué à 6.
http://developer.nvidia.com/object/cg_compiler_code.html(...)
[^] # Re: Dépendance non-libre...
Posté par ElVirolo (site web personnel) . Évalué à 2.
Voir aussi http://fr.wikipedia.org/wiki/Open_Source_Initiative(...) pour connaître les différends (philosophiques) entre l'OSI et la FSF.
Alex.
[^] # Re: Dépendance non-libre...
Posté par tanguy_k (site web personnel) . Évalué à 1.
open source signifie en anglais que le code source est ouvert, disponible.
[^] # Re: Dépendance non-libre...
Posté par ElVirolo (site web personnel) . Évalué à 7.
Je comprends tout à fait que l'on utilise l'anglais pour désigner l'Open Source (car c'est un nom officiel, etc...).
Mais dans ce cas présent, pourquoi ne pas utiliser le français ? Je ne vois pas l'intérêt de dire "open source".
C'est un peu comme si from now I incorporated English mots dans my sentences !
Alex.
[^] # Re: Dépendance non-libre...
Posté par GhZaaark3 . Évalué à 1.
Là où le français evite l'équivoque, on ne l'utilise pas, c'est dommage...
En même temps, si l'équivalent en français est trop long/rebutant, je ne serais pas contre l'utilisation d'un englisheu weurd.
bien, See ya les gars!
# comparatif avec G3D
Posté par Tuxmym . Évalué à 2.
Je suis pas très callé en moteurs 3D, et j'aurai aimé savoir quelles sont les différences/avantages/inconvénients entre OGRE et G3D (http://g3d-cpp.sourceforge.net/(...)).
Si quelqu'un peut m'éclairer...
Merci bien.
[^] # Re: comparatif avec G3D
Posté par tuan kuranes (site web personnel) . Évalué à 5.
Sinon les differences :
- License BSD contre LGPL pour Ogre.
- Ogre supporte directX7 et directX9 et OpenGL (sous win les drivers ATI sont assez mauvais en OpenGL par exemple) et est prevu pour d'autres protage (un portage playstation et Xbox ont existe a un moment.).G3d ne supporte qu'OpenGL.
- Ogre contient bcp plus de fonctionnalites utlise couramment dans les jeux et la 3d (animation, particules, mutl-textures, multi passes) scripts pour les materiaux et les particules (Vraiment utile.), etc...
- G3d n'a pas de systeme de plugins, pas de separation moteur-gestion de scenes, du coup il faut mettre les mains dedans. ( Ogre c'est sous forme de plugins une gestion de scene BSP, terrain, Octree.. g3d c'est "AABSPTree" code en dur.
# Jeux utilisant OGRE
Posté par smorico . Évalué à 1.
Sinon, les screenshots sont vraiment impressionnants !
[^] # Re: Jeux utilisant OGRE
Posté par smorico . Évalué à 2.
http://www.ogre3d.org/modules.php?op=modload&name=Web_Links&(...)
Sur leurs site dans : Misc/Links/Projects Using OGRE ;)
[^] # Re: Jeux utilisant OGRE
Posté par Frédéric Lopez . Évalué à 4.
http://www.ogre3d.org/wiki/index.php/OgreProjects(...)
Sinon, le jeu DIE est le seul exemple de jeu libre utilisant OGRE que je connaisse, mais il n'a plus l'air d'être maintenu depuis quelques temps déjà :
http://die.sourceforge.net/(...)
[^] # Re: Jeux utilisant OGRE
Posté par Papey . Évalué à 2.
[^] # Re: Jeux utilisant OGRE
Posté par tuan kuranes (site web personnel) . Évalué à 3.
http://www.ogre3d.org/phpBB2/viewtopic.php?p=48929(...)
# Moteur de rendu ou moteur 3d complet ?
Posté par Mildred (site web personnel) . Évalué à 1.
[^] # Re: Moteur de rendu ou moteur 3d complet ?
Posté par tuan kuranes (site web personnel) . Évalué à 4.
Pour le reste, beaucoup de morceaux de code ont ete donne dans les forums :
-Son : openAL, Fmod.
-Collisions/physique : Opcode, Ode, Newton, Tokamak
-Reseau Enet
-Video : Ogg vorbis, theora, ffmpeg
[^] # Re: Moteur de rendu ou moteur 3d complet ?
Posté par rzr (site web personnel) . Évalué à 2.
ok ok ok tout ca c'est old skewl ...
gpg:0x467094BC
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.