Sortie de OGRE 1.0.0

Posté par  . Modéré par rootix.
Étiquettes : aucune
0
25
fév.
2005
Jeu
La version 1.0.0 de OGRE est enfin sortie, après 5 années de développement.
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

  • # python

    Posté par  . Évalué à 4.

    Ecrit en C++ mais accessible depuis d'autres langages comme le python(alpha).
    http://www.ogre3d.org/wiki/index.php/PyOgre(...)

  • # support linux?

    Posté par  (site web personnel) . Évalué à 1.

    Est ce que le support linux a été amélioré? La derniere fois que j'avais testé, ça ne fonctionnait pas correctement avec les drivers fglrx.

    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  . Évalué à 2.

      OGRE fonctionne très bien sous Linux.

      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  (site web personnel) . Évalué à 4.

      Le support linux est complet : autant de fonctionnalites que sous windows. (plusieurs des devs sont sous Linux, et tous ont Linux installes sur un de leur PC.)

      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  . Évalué à 2.

        OGRE est d'ailleurs disponible dans Debian pour les architectures i386, m68k et powerpc. Voir : http://packages.debian.org/unstable/source/ogre(...)

        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  . Évalué à 2.

          Les paquets pour la version 1.0.0 sont disponibles. Ils ne sont pas encore dans sid mais ils sont accessibles en ajoutant cette ligne à etc/apt/sources.list :
          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  (site web personnel) . Évalué à 8.

    "l'ajout du support des hardware pixel buffers et du rendu HDR (High Dynamic Range)"

    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  (site web personnel) . Évalué à 3.

      A noter , il existe une version en .Net appelee Axiom qui compile sous Mono.
      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  . Évalué à 5.

        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

        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  (site web personnel) . Évalué à 3.

          Aahh l'objectivité...
          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  . Évalué à 4.

            Si je prends Dot3Bump, j'ai un gain de 53% en C# par rapport à C++

            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.

            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

            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  (site web personnel) . Évalué à 3.

              oué enfin de manière général c'est plus efficace de changer de carte graphique et d'ajouter une barrette de RAM dans un PC pour voir les perfs dans un jeu grimper en flèche :)

  • # Demande d'explication

    Posté par  . Évalué à 2.

    Je connais un peu ogre, enfin une trés vieille version, mais par contre j'ai pas saisi :

    Il est aussi à noter que OGRE utilise des tests unitaires via cppunit pour certaines de ses fonctionnalités ;)


    c'est ouate ?

  • # Dépendance non-libre...

    Posté par  (site web personnel, Mastodon) . Évalué à -1.

    C'est quand même dommage que Ogre dépende du Cg_Toolkit de nvidia qui est non-libre (même pas opensource) et disponnible uniquement pour linux-x86...

  • # comparatif avec G3D

    Posté par  . Évalué à 2.

    Bonjour,
    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  (site web personnel) . Évalué à 5.

      En bref, Ogre est un vrai moteur 3d alors que G3d est une surcouche d'opengl avec des fonctionnalites non-3d et 3d integres sur la base du "utiles dans pluseurs projets 3d donc mis dans la lib" (le reseau par exemple)

      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  . Évalué à 1.

    C'est peut être un peut tôt mais savez vous s'il existe des jeux (ou demo), libres de preference, sous linux. J'aimerait tester un peut ça, mais j'ai vu que des demo windows sur le site....
    Sinon, les screenshots sont vraiment impressionnants !

  • # Moteur de rendu ou moteur 3d complet ?

    Posté par  (site web personnel) . Évalué à 1.

    Est-ce qu'Ogre permet juste de faire un rendu comme le fait irrlicht ou permet-t-il de faire plus comme le son, les collisions, et le réseau par exemple ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.