Journal OpenMW passe d'Ogre3D à OpenSceneGraph

29
8
juin
2015

Sommaire

Introduction

OpenMW, pour ceux qui ne connaîtraient pas, est la ré-implémentation en Open Source ( GPL v3 pour être précis ) du jeu «The Elder Scrolls III : Morrowind» (que j'abrège soit en TESIII ou en Morrowind par la suite) et de son éditeur «The Elder Scrolls Construction Set», Morrowind étant considéré par un certain nombre de personnes comme le meilleur opus de la série.

Pour ma part, je n'ai pas joué à Skyrim, donc je ne peux juger, mais je préfère effectivement TESIII à Oblivion (le 4ème opus) et bien sûr à ses prédécesseurs (arrivé à un moment, le confort apporté par certaines technos modernes joue pas mal sur le gameplay, sans parler de l'univers).

Comme il s'agit d'implémentation, cela signifie qu'il faut toujours les données du jeu original pour jouer, ce n'est donc pas Morrowind qui est cloné en libre (ce qui est probablement impossible de toute façon, vue la grande part d'art impliquée dans la création d'un tel jeu), juste le côté logiciel.
D'un autre côté, je me souviens avoir vu qu'ils parlaient de faire une démo avec du contenu uniquement libre, en se basant sur leur nouvel éditeur et la communauté de moddeurs de Morrowind qui semble plutôt conséquente et ambitieuse même aujourd'hui (assez en tout cas pour tenter de réaliser le reste de Vvardenfell, patrie des elfes noirs dans l'univers d'Elder Scrolls, avec le projet Tamriel Rebuilt).

Bien qu'il s'agisse d'une ré-implémentation, il ne s'agit pas d'être exactement identique: certaines fonctionnalités ont été ajoutées (reflets de l'eau, par exemple) et l'interface utilisateur améliorée (par exemple le dialogue de commerce).

Changement de moteur 3D

Résumé des technologie utilisées

Le projet était initialement écrit en langage D, mais est passé au C++ pour une raison principale de manque de main d'œuvre, si je me rappelle bien, tandis que côté rendu graphique, Ogre3D est (enfin, était) utilisé, assisté de Bullet et OpenAL pour les collisions et le rendu sonore.

Pour ce qui est de la gestion des fenêtres et IHMs, le couple SDL+MyGUI est utilisé par le jeu proprement dit, tandis que l'éditeur et le lanceur sont basés sur Qt4.

Le tout étant saupoudré de diverses parties de Boost, libav-tools/codec/format/util… et compilé à coup de Cmake (c'est d'ailleurs grâce à OpenMW que j'utilise cmake, une dépendance était obsolète pour générer le .deb il y a quelques années, j'avais réussi à corriger le problème sans lire de doc et en moins d'une heure, alors que mettre mon nez dans un truc géré par les autotools me fait fuir très vite).

Le projet OpenMW est actuellement proche de la bêta (à mon avis, qui n'est pas celui de quelqu'un impliqué) pour le jeu, avec moins de 15 tickets marqués «feature» restant dans la roadmap, en dehors de ceux concernant l'éditeur.

Problèmes d'Ogre3D

Il y a quelques temps, un billet est apparu sur le blog officiel expliquant qu'ils allaient changer de moteur graphique, et pourquoi.
Certains défauts d'Ogre3D ont été corrigés dans les versions récentes, mais d'autres sont apparus dans ces mêmes versions, empêchant donc de simplement porter d'une version à l'autre.

Dans les versions 1.x, la vitesse d'affichage (framerate) d'Ogre3D est trop faible, comparé à l'original. Dommage, compte tenu du fait que ledit original est quand même pas super récent (2002, du 13 ans d'âge tout de même). Il n'est pas indiqué le matériel sur lequel le problème de performances a été constaté, ceci dit, mais personnellement j'apprécie que les développeurs prêtent attention aux performances.
Ceci a été corrigé par la suite, mais le projet utilise les «Tag Points» pour maintenir ensemble les diverses parties des corps, fonctionnalité qui n'est plus supportée et qui forcerait à des contournement complexes. De plus, les versions plus récentes d'Ogre3D ne supportent plus OpenGL2, que l'équipe d'OpenMW souhaite continuer de supporter. Enfin, Ogre3D v2.1 a refondu la gestion du matériel (au sens 3D, pas au sens matériel de l'ordinateur) pour utiliser une technique d'optimisation nommée «AZDO» (Approaching Zero Driver Overhead, je suppose que le but est de réduire un surcoût, mais je serai incapable de dire de quoi il s'agit réellement, je l'avoue) qui rend plus compliqué la création de matériel personnalisé, chose qu'OpenMW entend beaucoup utiliser, notamment pour permettre les modifications des utilisateurs finaux.

Il y a également des problèmes qui datent des versions précédentes, et qui perdurent:

  • Ogre3D utilise un gestionnaire de ressources global. Hors, ils ont besoin d'en avoir un par document dans OpenCS (l'éditeur). Les ressources sont également supposées avoir un nom unique, ce qui peut poser des problèmes de conflit avec le contenu créé par les utilisateurs. Ces problèmes sont compris par l'équipe d'Ogre3D et ils travaillent à les résoudre, mais malheureusement ce n'est pas encore réglé. Et je suppose que vu le stade de développement d'OpenMW, c'est devenu vraiment bloquant.
  • Le format NIF utilisé par Morrowind permet d'utiliser ce qu'ils appellent «stencil settings». Je ne sais pas comment traduire ça… cadre de pochoir? Bon, bref, toujours est-il qu'Ogre3D ne supporte pas cette fonctionnalité.
  • le système de squelette d'Ogre3D ne permets pas d'ajuster les proportions de manière non-uniforme (qui ne soient pas sur les 3 axes, à priori), alors que Morrowind supporte la notion de poids, qui résulte en une modification de la largeur des PNJs (Personnage Non-Joueur).

Solution adoptée

Au vu de ces inconvénients, il fallait soit forker, soit trouver une alternative. Je précise qu'il me semble qu'ils ont déjà contribué à plusieurs reprises à Ogre3D, on ne peut donc pas dire qu'il n'y a pas eu d'efforts de faits. L'équipe a opté pour la seconde solution (compte tenu du fait que leur objectif est de créer un jeu, et pas un moteur 3D, je suppose).
Ils ont donc découvert OpenSceneGraph (que j'abrègerai OSG), qui semble répondre à leurs attentes: soit les fonctionnalités sont déjà dans le code, soit elles sont facilement réalisables via des plug-ins. En revanche, le support de DirectX sera abandonné, cette technologie n'étant pas supportée par OSG.
Mais en fait, le support de DirectX et de OpenGL ne se limite pas à un support par le moteur 3D, il faut de toute façon écrire les shaders pour les deux technologies, et OpenMW semblait avoir quelques bugs liés uniquement à DirectX. Du coup, ils ont une bonne excuse pour abandonner le support d'une technologie qui les gênait plus qu'autre chose, n'ayant de toute façon pas la main d'œuvre pour supporter 2 systèmes de shaders, et la plupart des dév. bossant sous Linux.

Stade actuel

Hier, ils ont publié un billet donnant des nouvelles de ce changement. Apparemment, après 3 mois (de boulot intensif je pense) il est possible de conclure que le port est un succès: toutes les fonctionnalités essentielles ont été migrées, et le jeu, selon le billet, se charge plus rapidement, voit sa vitesse d'affichage améliorée, ressemble plus au jeu original et des bugs qui étaient complexes à corriger auparavant ont été corrigés.

Amélioration des performances

Au sujet des améliorations de performances, l'auteur du billet relate un test qui a été fait (par lui? Aucune idée…). Il s'avère qu'à fonctionnalités égales, la vitesse d'affichage se voit augmentée de quasi 50%, le temps de chargement divisé par 2, et l'empreinte mémoire réduite de 20%…
Surprenant, mais en fait, pas tant que ça: certaines fonctionnalités avancées n'ont pas encore été implémentées, du genre les shaders, l'affichage des terres lointaines ou les reflets de l'eau. On pourrait supposer que les améliorations de performances y sont liées, mais vu que ces fonctionnalités ont été désactivées dans l'ancienne branche, probablement pas.
En revanche, des bugs ont été corrigés et des fonctionnalités et optimisations ajoutées uniquement dans la nouvelle branche. D'un autre côté, il y a aussi des optimisations qui ont été supprimées parce qu'elles causaient des problèmes… Donc, la comparaison n'est pas vraiment équitable, des deux côtés.

L'auteur indique aussi que les performances seront probablement plus élevées pour les fonctionnalités avancées. Une des raisons que je crois comprendre est qu'une partie du boulot graphique est envoyée dans un autre thread, ce qui fait que le rendu graphique ralentira moins le thread principal, qui aura donc plus de temps pour s'occuper de choses comme les collisions, les scripts ou les animations.
De même, le travail d'optimisation n'a pas encore commencé: pour le moment, ils se sont concentrés à rendre le nouveau port jouable, ce qui semble n'être le cas que depuis quelques jours. Une liste d'optimisations possible est indiquée, je vous invite à aller les consulter si ça vous intéresse vraiment. Personnellement, mes compétences en 3D sont plutôt… limitées, on va dire.

Amélioration du rendu

Comme mentionné précédemment, les performances ne sont pas la seule raison du changement technologique. Le rendu de certains personnages, comme Sellus Gravius, ou même du paysage (par exemple pour les feuillages) est plus proche du rendu originel, grâce à des proportions des personnages plus fidèles ou une meilleure gestion de la transparence (en raison d'un traitement par lot statique, qui a depuis été supprimé). Entres autres.

Autres améliorations

Comme la moule avertie l'aura constaté, les améliorations ne sont pas dues uniquement au changement de moteur.
Je n'ai cependant listé que des améliorations liées au rendu 3D, et il reste bien entendu d'autres points sur lesquels OpenMW a été amélioré. On notera une refonte du chargement des NIF, une amélioration de la physique (notamment pour ceux qui compilent avec bullet 2.83 ou plus), l'amélioration du support de la SDL2, un régime minceur du code source (à peu près 23 kLoC quand même).
Ah. Et une amélioration de taille, je cite: «In the meantime though, on the graphics front, there is now nothing stopping us from releasing the long awaited OpenMW 1.0 […]». Traduction: «Cependant, côté graphique, plus rien ne nous empêche de publier la tant attendue version 1.0 d'OpenMW […]».
Bon, ok, je peux encore améliorer mes compétences de traduction, mais le sens est le même, je pense :)

PS: le développement de ce port est situé sur une branche dédiée, pour ceux qui voudraient compiler.

  • # Dommage !

    Posté par . Évalué à 10.

    Dommage pour la news en souffrance dans la tribune de rédaction : http://linuxfr.org/redaction/news/openmw-une-implementation-libre-du-moteur-du-jeu-de-role-morrowind

    • [^] # Re: Dommage !

      Posté par . Évalué à 6. Dernière modification le 08/06/15 à 17:23.

      Je plaide coupable, je n'ai même pas vérifié.

      Bon, je vais faire semblant de défendre l'indéfendable: je me suis contenté de faire la synthèse de 2 billets de blogs, alors que cette dépêche semble créer du contenu.

      Bon en fait même pas… ça semblait parler du projet entier, mais au final après une lecture en diagonale, ça parle quasi que du changement de techno. Vraiment indéfendable moi donc.

  • # Matériau

    Posté par (page perso) . Évalué à 6.

    Enfin, Ogre3D v2.1 à refondu la gestion du matériel (au sens 3D, pas au sens matériel de l'ordinateur)

    En fait ce que tu appelles "matériel 3D" s'appelle plutôt "matériau" (métal, bois, pierre…) donc pas de confusion possible.

    • [^] # Re: Matériau

      Posté par . Évalué à 2.

      Oui, mais comme je l'ai dis un peu plus tard (ou était-ce plus tôt?) je ne suis pas très connaisseur en ce qui concerne la 3D.
      J'ai bien essayé de lire quelques docs concernant blender mais le manque de doc traitant d'une version récente m'a fait lâcher l'affaire.
      Je suis donc resté du côté programmeur de la chose, et ai essayé de trouver des infos pour coder via de l'openGL, mais encore une fois, quand on sort des sentiers battus (genre, faire du rendu de formes concaves) on se retrouve vite en galère de trucs compréhensibles.
      Du coup, je me suis re-rabattu sur mes bonnes vieilles consoles, ou y'a pas de 3D mais ou au moins c'est simple :)

      En tout cas merci de ta précision, il faudra que j'essaie de me rappeler de ce terme.

  • # Projet génial

    Posté par . Évalué à 4. Dernière modification le 09/06/15 à 11:20.

    Ça va être super de pouvoir rejouer à Morrowind en profitant de ce nouveau moteur ! On pourra ajouter les mods déjà existant, peut-être améliorer le "gameplay" orignal, y jouer sous toutes les plateformes, ect.

    Pour suivre les releases depuis 3 ans, je peux vous dire que la 1.0 n'est plus très loin !

    J'ai vraiment hâte.

    • [^] # Re: Projet génial

      Posté par . Évalué à 4.

      Perso, j'ai hâte de pouvoir y jouer sur mon système favori (basé sur linux pour le moment) en combinant à ma version officielle les mods codés en anglais. Avec un peu de bol ce sera possible.

      Accessoirement, j'ai hâte de voir les autres améliorations futures, qui ne sont et ne seront dites nulle part.
      Par exemple, j'ai souvenir qu'une personne à rejoins le projet tout en maintenant son propre clone il y à 2-3 ans. La différence de son clone était que l'objectif était le support multi-joueurs.
      Même si je vois mal comment ça pourrait s'intégrer à l'histoire principale (un groupe de nérévarines? what?), ça signifie que des gens sont très ambitieux au sujet de ce projet, et ce n'est pas une mauvaise chose.
      Et puis, de toute façon, je veux voir le combo tamriel rebuilt + openmw… je pense que ce sera une superbe preuve que l'open source peut être efficace en terme de jeux vidéo, et que ceux-ci peuvent marcher sur autre chose que sur windows.
      D'ailleurs, je devrais peut-être suivre d'un peu plus près TR… dommage qu'ils ne donnent de leurs nouvelles que tous les XX mois.

Suivre le flux des commentaires

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