La version OpenSceneGraph enfin jouable! 2015-06-07 - Lukasz Gromanowski

Durant les trois derniers mois, l’équipe OpenMW a travaillé dur pour que le code s’éloigne du moteur Ogre3D en faveur du système de rendu OpenSceneGraph. Cet article explique les raisons de ce changement.

Nous sommes heureux de vous annoncer que tous ces efforts portent enfin leurs fruits ! Ainsi, toutes les fonctions essentielles du gameplay sont désormais portées, les utilisateurs peuvent donc profiter de Morrowind dans la OpenMW-osg branche de développement.

Certaines fonctions avancées -shaders, terrain distant, ombres et reflets sur l’eau – ne sont pas encore portées. Cependant, même si le portage est encore frais, nous pouvons dire sans risques que la transition est un énorme succès, bien plus que nous ne l’avions imaginé. Les joueurs remarqueront que le jeu se charge plus vite, est plus fluide, ressemble plus au jeu original, et corrige de nombreux bugs qui s’étaient avérés très difficiles à corriger dans notre ancien moteur.

Attendez … plus fluide ?Voyons voir ça…

Les premiers tests

Voici notre environnement de tests:
GeForce GTX 560 Ti/PCIe/SSE2, AMD Phenom(tm) II X4 955 Processor × 4, Linux 3.13.0-24-generic x86_64
1680×1050, plein écran, pas d’AA , 16x AF, pas de reflets sur l’eau, pas d’ombres, aucun shaders
Distance de vue au maximum (par rapport au curseur en jeu)

osg_bench
La scène de test : notre bonne vieille (et lourde) Balmora

OpenMW OpenMW-osg
IPS moy. 49 75
tps de chargement moy. 7s 3.4s
mémoire moy. 344.6mb 277.1mb

Sans surprises, le portage vers OSG gagne sur tous les fronts. L’amélioration des images par seconde est correcte, même si elle reste loin du x3-4 que nous avions observé dans nos premiers tests avec un seul objet. Il n’y a aucune raisons de s’inquiéter, cependant – il y a d’autres choses à prendre en considération :

  1. La comparaison est injuste. De nouvelles fonctions de rendu sont incluses dans la branche OSG, qui nous rapprochent encore plus du jeu d’origine, mais affectent cependant les performances. Par exemple, nous agrandissons les boîtes d’affichage en fonction des animations, corrigeant ainsi le bug des braillards des falaises qui disparaissaient sous certains angles (Bug 455), mais réduisant les performances également. De plus, nous avons retiré le traitement par lot des objets statiques, une optimisation de performance qui causait de multiples problèmes, notamment des problèmes d’éclairage et le mouvement scripté des objets ne fonctionnant pas. Malgré toutes ces nouvelles fonctions, OSG reste plus rapide !
  2. Attendez-vous à des gains de performances encore plus importants pour les fonctions graphiques avancées. La comparaison a été faite avec les graphismes minimaux, pour la simple raison que les fonctions avancées (ombres, reflets, …) n’existent pas encore dans la branche OSG. Nous nous attendons à ce que ces fonctions, une fois portées, auront un impact sur les performances bien plus limité qu’avant, puisque le nouveau moteur de travail répartit bien mieux la charge sur le GPU. Les demandes de rendu sont donc déchargées vers un thread séparé, ainsi la complexité graphique de la scène ne bloquera pas le thread principal qui pourra donc continuer à travailler sur l’occultation, la physique, les scripts et les animations.
  3. La vraie phase d’optimisation n’a même pas encore commencé. L’objectif prioritaire jusqu’ici était de ramener le jeu à un état jouable, ce qui est arrivé il y a quelques jours seulement. Désormais, l’horizon est rempli de nouvelles opportunités d’optimisation. Notre nouveau moteur de rendu nous donne plus de contrôle sur comment le graphe de scène est structuré, et comment les mises à jours sont réparties, et nous ne faisons que commencer à en profiter. Certaines des optimisations prévues dans un futur proche sont :
    • Déplacer les mises à jour de textures vers un thread séparé.
    • Déplacer les mises à jour de particules vers un thread séparé.
    • Partager des états entre plusieurs fichiers NIF.
    • Activer l’occultation pour les émetteurs de particules.
    • Intégrer un optimiseur de modèles. Les modèles de Morrowind contiennent malheureusement beaucoup de nœuds, transformations et états redondants, ce qui impacte les performances. Le moteur original optimise les modèles au chargement dans le moteur. Nous devrions implémenter un passage d’optimisation similaire. OpenSceneGraph fournit osgUtil::Optimizer qui pourrait s’avérer utile dans cet objectif.
    • Créer un graphe de scène plus équilibré, par exemple un arbre quadratique, pour réduire l’impact sur les performances de l’occultation et des requêtes sur la scène.
  4. Le rendu n’est pas un le seul goulôt d’étranglement. Penser qu’un rendu N fois plus rapide entraine un OpenMW N fois plus rapide est faux. Nous avons d’autres systèmes ralentissant le jeu, et maintenant que le moteur de rendu est plus rapide, ces goulôts sont de plus en plus apparents. En particulier, les systèmes d’animation et de physique forment les deux plus gros ralentissements. Certaines optimisations préliminaires pour ces systèmes sont arrivées, mais il y a sans aucun doute de nombreuses optimisations possibles.

Ceci étant dit, les améliorations de performance ne sont pas le seul changement auquel les joueurs peuvent s’attendre :

Changements préliminaires

Amélioration du rendu

osg_scaling osg_transparency
Comparaison de la mise à l’échelle des PNJs Comparaison de la transparence

Refonte du chargeur d’objets NIF

Réécriture du moteur physique

Nouveau raycasting

Amélioration de l’écran de chargement

Amélioration du support de SDL2

SDL2, la bibliothèque que nous utilisons pour la création de fenêtres et la gestion des entrées indépendamment de la plateforme, a été mieux intégrée dans le moteur de rendu. Les avantages concrets pour l’utilisateur incluent :

osg_antialiasing
L’antialiasing X8 en action

Surcouche de profilage

Un effet secondaire sympathique du passage à OpenSceneGraph est l’accès à leurs supers outils de profilage. D’un simple appui sur la touche « F3 », une surcouche apparaît, nous donnant beaucoup d’informations utiles.

osg_profiling
La surcouche de profilage – les barres de couleur représentent les thread internes d’OpenSceneGraph, les blanches la logique interne d’OpenMW

Changements « passifs »

Le nouvel OpenMW utilise un moteur OpenGL unifié sur toutes les plateformes. Le rendu via Direct3D n’est plus supporté, réduisant ainsi la charge de travail liée à la maintenance et au support pour l’équipe.

De façon pratique, nous avons donc « corrigé » le bug 2186 (Pixels imprécis sur la minicarte sous Windows) et le bug 1647 (Crash lors du passage en mode fenêtré sous Windows).

Autres changements

Enfin, nous avons fait quelques autres changements qui ne sont pas vraiment liés à la transition vers OpenSceneGraph, mais qui ont été publiés sur la branche OSG afin de réduire les conflits de fusion :

osg_ui_scale_1 osg_ui_scale_2
Taille normale Taille X2, même résolution

Maintenance / restructuration / Nettoyage du code

Le code a considérablement réduit, ce qui est plutôt intéressant pour les développeurs, mais pas vraiment pour les utilisateurs finaux.

Au total, ~23.000 lignes de code ont été retirées :

git diff upstream/master --shortstat
689 files changed, 24051 insertions(+), 47695 deletions(-)

Et ensuite ?

Wow, ça fait beaucoup de changements à encaisser – Même à ce stade, la liste des améliorations est impressionnante, donc notre priorité devrait être de fusionner le portage dans la branche principale, refaire fonctionner nos compilations automatiques, puis sortir une nouvelle version.

Sur le long terme, nous ne sommes pas près d’avoir exploité tout le potentiel de ce nouveau moteur. Les prochaines étapes devraient être des améliorations de performances encore plus poussées, puis remettre les shaders, le terrain distant, les reflets sur l’eau et les ombres. Notre nouveau chargeur de fichiers NIF facilite l’implémentation du chargement en arrière plan, qui était à la base une amélioration prévue pour après la version 1.0 – maintenant, l’implémentation devient triviale, donc nous pourrions finalement voir cette fonctionnalité apparaître avant la 1.0.

En même temps, sur l’aspect graphique, il n’y a désormais plus rien pour nous empêcher de sortir la tant attendue version 1.0 d’OpenMW, donc nous devrions peut-être rediriger nos efforts vers la correction des problèmes bloquants en premiers lieu, sortir la version 1.0, puis nous occuper des fonctions graphiques avancées pour la version 1.1. Nous pourrions décider de cela au cas par cas. En particulier, les reflets sur l’eau devraient être beaucoup plus faciles à porter que les ombres, qui ne marchaient pas très bien dans Ogre3D de toutes façons.

Si vous avez une opinion sur le sujet, n’hésitez pas à commenter. De toutes façons, quelle que soit notre décision, ce qui arrive sera probablement génial !

Laisser un commentaire

// Translated by: magusor & nnayo

Fork me on GitHub

Comments are closed.