Update including nnayo's corrections :
Code: Select all
<div class="bodyElement">
<div class="bodyElementTitle">
<a href="https://openmw.org/2015/openscenegraph-port-playable/">
La version OpenSceneGraph enfin jouable !</a>
<span class="bodyElementSubtitle">
2015-06-07 - scrawl </span>
</div>
<p>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. <a href="https://openmw.org/2015/announcing-switch-openscenegraph/">Cet article</a> explique les raisons de ce changement.</p>
<p>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 <a href="https://github.com/scrawl/openmw/tree/osg">OpenMW-osg</a> branche de développement. </p>
<p>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.</p>
<p>Attendez ...<em> plus fluide </em>?Voyons voir ça…</p>
<h2>Les premiers tests</h2>
<p>Voici notre environnement de tests:<br>
GeForce GTX 560 Ti/PCIe/SSE2, AMD Phenom(tm) II X4 955 Processor × 4, Linux 3.13.0-24-generic x86_64<br>
1680×1050, plein écran, pas d'AA , 16x AF, pas de reflets sur l'eau, pas d'ombres, aucun shaders<br>
Distance de vue au maximum (par rapport au curseur en jeu)</p>
<p><a href="https://openmw.org/wp-content/uploads/2015/06/osg_bench.png"><img src="https://openmw.org/wp-content/uploads/2015/06/osg_bench-300x188.png" alt="osg_bench" class="alignnone size-medium wp-image-4399" height="188" width="300"></a><br>
<em>La scène de test : notre bonne vieille (et lourde) Balmora<br>
</em></p>
<table cellspacing="8">
<tbody><tr>
<td></td>
<td>OpenMW</td>
<td>OpenMW-osg</td>
</tr>
<tr>
<td>IPS moy.</td>
<td>49</td>
<td><strong>75</strong></td>
</tr>
<tr>
<td>tps de chargement moy.</td>
<td>7s</td>
<td><strong>3.4s</strong></td>
</tr>
<tr>
<td>mémoire moy.</td>
<td>344.6mb</td>
<td><strong>277.1mb</strong></td>
</tr>
</tbody></table>
<p>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é <a href="https://forum.openmw.org/viewtopic.php?f=2&t=2760&start=20">dans nos premiers tests</a> 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 :</p>
<ol>
<li><strong>La comparaison est injuste</strong>. 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 <a href="https://bugs.openmw.org/issues/385">des problèmes d'éclairage</a> et <a href="https://bugs.openmw.org/issues/602">le mouvement scripté des objets ne fonctionnant pas</a>. Malgré toutes ces nouvelles fonctions, OSG <em>reste</em> plus rapide !</li>
<li><strong>Attendez-vous à des gains de performances encore plus importants pour les fonctions graphiques avancées</strong>. 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.</li>
<li><strong>La <em>vraie</em> phase d'optimisation n'a même pas encore commencé</strong>. 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 :
<ul>
<li>Déplacer les mises à jour de textures vers un thread séparé.</li>
<li>Déplacer les mises à jour de particules vers un thread séparé.</li>
<li>Partager des états entre plusieurs fichiers NIF.</li>
<li>Activer l'occultation pour les émetteurs de particules.</li>
<li>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.</li>
<li>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.</li>
</ul>
</li>
<li><strong>Le rendu n'est pas un le seul goulôt d'étranglement</strong>. 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.</li>
</ol>
<p>Ceci étant dit, les améliorations de performance ne sont pas le seul changement auquel les joueurs peuvent s'attendre :</p>
<h2>Changements préliminaires</h2>
<p><strong>Amélioration du rendu</strong>
</p><ul>
<li>Mise à l’échelle non uniforme des PNJs (Bug 814):<br>
Certain PNJs sont maintenant mis à l’échelle selon leurs axes X et Y, ce qui leur donne une apparence plus forte, tout comme dans le jeu d'origine. Les versions précédentes ne pouvaient pas faire cela à cause de limites dans Ogre3D. </li>
<li>Amélioration de la précision du rendu : correction de la précision des grandes coordonnées, visible lorsque le joueur s'écarte trop du point 0,0 du monde. <a href="https://www.youtube.com/watch?v=wybVYwQPVmY">Comparaison vidéo</a> </li>
<li>Retrait du traitement par lot des objets statiques : corrige l'éclairage incorrect (Bug 385), corrige le mouvement scripté des objets (Bug 602) et améliore les temps de chargement.</li>
<li>Paramètres de transparence fidèle aux originaux : les versions précédentes d'OpenMW utilisaient des paramètres qui n'étaient pas fidèles au Morrowind original afin de faciliter le traitement par lot des géométries statiques. Cela a été corrigé - Les utilisateurs remarqueront que les feuillages et les autres objets transparents ont des bords plus "doux".</li>
<li>Ajout d'une option d'<em>occultation des petits détails</em> : en plus d'occulter les objets en dehors de l'écran, nous pouvons maintenant ne pas essayer d'afficher pour les objets qui seraient plus petit qu'un pixel lors du rendu. La différence visuelle est presque invisible, par conséquent l'option est activée par défaut.</li>
</ul>
<table cellspacing="16">
<tbody><tr>
<td>
<a href="https://openmw.org/wp-content/uploads/2015/06/osg_scaling.png"><img src="https://openmw.org/wp-content/uploads/2015/06/osg_scaling-300x156.png" alt="osg_scaling" class="alignnone size-medium wp-image-4383" height="156" width="300"></a>
</td>
<td>
<a href="https://openmw.org/wp-content/uploads/2015/06/osg_transparency.png"><img src="https://openmw.org/wp-content/uploads/2015/06/osg_transparency-300x156.png" alt="osg_transparency" class="alignnone size-medium wp-image-4386" height="156" width="300"></a>
</td>
</tr>
<tr>
<td align="center">
<em>Comparaison de la mise à l'échelle des PNJs</em>
</td>
<td align="center">
<em>Comparaison de la transparence</em>
</td>
</tr>
</tbody></table>
<p><strong>Refonte du chargeur d'objets NIF</strong>
</p><ul>
<li>Support de la mise à l'échelle non uniforme des fichiers NIF (Bug 2052)</li>
<li>Correction de la limite de nœuds dans les fichiers NIF (Bug 2187)</li>
<li>Correction des animations "figées" lorsque l'objet est occulté (Bug 2151)</li>
<li>Refonte de l’algorithme des textures pour permettre un graphe de scène plus efficient</li>
<li>Extension dynamique des boîtes de rendu en fonction de l'animation du squelette : corrige la disparition de certaines créatures selon certains angles de vue (Bug 455)</li>
<li>Les graphes de scène NIF sont maintenant des ressources partagées : améliore grandement les temps de chargement</li>
<li>Les clés textuelles des animations sont maintenant des ressources partagées</li>
</ul>
<p><strong>Réécriture du moteur physique</strong>
</p><ul>
<li>Si compilé avec Bullet 2.83 ou plus récent, profite de btScaledBvhTriangleMeshShape pour une instanciation des formes plus efficace</li>
<li>Retrait des formes de raycasting "détaillées" de Bullet, remplacées par un raycasting direct sur le graphe de scène (voir la section "Nouveau raycasting"), réduisant grandement l'utilisation mémoire</li>
<li>Utilisation de btCollisionWorld au lieu de btDynamicsWorld afin d'éviter des traitements non nécessaires pour des fonctionnalités que nous n'utilisons pas</li>
<li>Liaison des objets de collision par pointeurs au lieu de noms</li>
</ul>
<p><strong>Nouveau raycasting</strong>
</p><ul>
<li>Utilise osgUtil::IntersectionVisitor pour un raycasting direct sur le graphe de scène</li>
<li>Support du raycasting sur des formes animées, ce qui corrige le curseur de sélection sur les acteurs (Bug 827)</li>
<li>Réécriture de la logique de sélection d'objet sur la prévisualisation dans l'inventaire, qui utilise maintenant le raycasting au lieu d'un tampon de sélection, ce qui améliore le temps de réponse</li>
</ul>
<p><strong>Amélioration de l'écran de chargement</strong>
</p><ul>
<li>L'écran de chargement effectue son rendu dans un thread séparé, afin de ne plus ralentir la procédure de chargement</li>
<li>Augmentation du nombre d'images par seconde sur l'écran de chargement pour que la barre de progression soit plus fluide</li>
<li>Chargement des objets OpenGL dans un thread séparé pendant que la zone se charge, en utilisant osgUtil::IncrementalCompileOperation</li>
</ul>
<p><strong>Amélioration du support de SDL2</strong></p>
<p>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 :
</p><ul>
<li>L'anti-crénelage (ou antialiasing) fonctionne enfin sur Linux (Bug 2014)</li>
<li>SDL2 est maintenant en charge de la création du contexte graphique, ce qui signifie que les nouvelles APIs graphiques, telles que Wayland et Mir sur Linux, sont automatiquement supportées sans travail supplémentaire pour l'équipe OpenMW.</li>
</ul>
<p><a href="https://openmw.org/wp-content/uploads/2015/06/osg_antialiasing.png"><img src="https://openmw.org/wp-content/uploads/2015/06/osg_antialiasing-300x188.png" alt="osg_antialiasing" class="alignnone size-medium wp-image-4379" height="188" width="300"></a><br>
<em>L'antialiasing X8 en action</em> </p>
<p><strong>Surcouche de profilage</strong></p>
<p>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.</p>
<p><a href="https://openmw.org/wp-content/uploads/2015/06/osg_profiling.png"><img src="https://openmw.org/wp-content/uploads/2015/06/osg_profiling-300x130.png" alt="osg_profiling" class="alignnone size-medium wp-image-4376" height="130" width="300"></a><br>
<em>La surcouche de profilage - les barres de couleur représentent les thread internes d'OpenSceneGraph, les blanches la logique interne d'OpenMW</em></p>
<p><strong>Changements "passifs"</strong></p>
<p>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.</p>
<p>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).</p>
<p><strong>Autres changements</strong></p>
<p>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 :</p>
<ul>
<li>Amélioration de la distance d'activation des lumières (Bug 1813)</li>
<li>Correction de la force de NiGravity (Bug 2147)</li>
<li>Implémentation des modes d'extrapolation des contrôleurs (Bug 1871)</li>
<li>Implementation du traitement des particules NiPlanarCollider (Bug 2149)</li>
<li>Ajout d'une fonction de mise à l'échelle de l'interface : </li>
</ul>
<table cellspacing="16">
<tbody><tr>
<td>
<a href="https://openmw.org/wp-content/uploads/2015/06/osg_ui_scale_1.png"><img src="https://openmw.org/wp-content/uploads/2015/06/osg_ui_scale_1-300x188.png" alt="osg_ui_scale_1" class="alignnone size-medium wp-image-4393" height="188" width="300"></a>
</td>
<td>
<a href="https://openmw.org/wp-content/uploads/2015/06/osg_ui_scale_2.png"><img src="https://openmw.org/wp-content/uploads/2015/06/osg_ui_scale_2-300x188.png" alt="osg_ui_scale_2" class="alignnone size-medium wp-image-4394" height="188" width="300"></a>
</td>
</tr>
<tr>
<td align="center">
<em>Taille normale</em>
</td>
<td align="center">
<em>Taille X2, même résolution</em>
</td>
</tr>
</tbody></table>
<p><strong>Maintenance / restructuration / Nettoyage du code</strong></p>
<p>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.</p>
<ul>
<li>Le code gérant la physique a été déplacé vers le nouveau sous-système “mwphysics” </li>
<li>Retrait des noms de nœuds de scène, par exemple l'identifiant RefData::getHandle </li>
<li>Retrait d'OpenEngine</li>
<li>Retrait des wrappers de plateforme</li>
<li>Retrait de "shiny"</li>
</ul>
<p>Au total, ~23.000 lignes de code ont été retirées :<br>
<code><br>
git diff upstream/master --shortstat<br>
689 files changed, 24051 insertions(+), 47695 deletions(-)<br>
</code></p>
<h2>Et ensuite ?</h2>
<p>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.</p>
<p>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. </p>
<p>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 <a href="https://bugs.openmw.org/projects/openmw/roadmap#openmw-1.0">problèmes bloquants</a> 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.</p>
<p>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 !</p>
<p><a href="https://forum.openmw.org/viewtopic.php?f=38&t=2931"><br>
</a></p><h5><a href="https://forum.openmw.org/viewtopic.php?f=38&t=2931">Laisser un commentaire</a></h5><a href="https://forum.openmw.org/viewtopic.php?f=38&t=2931">
</a><p><a href="https://forum.openmw.org/viewtopic.php?f=38&t=2931"></a></p>
<a class="github-ribbon" href="https://github.com/OpenMW/openmw"><img style="position: fixed; top: 0; right: 0; border: 0;" src="https://openmw.org/ribbons/forkme_right_red_aa0000.png" alt="Fork me on GitHub"></a> 2015-06-07 - scrawl - <a href="https://openmw.org/2015/openscenegraph-port-playable/#comments">
2 retours.</a>
</div>
Finished !
Please note that the gitHub ribbon code slipped into the article, since I don't know if it is harcoded or not I left it here
Everything is (or at least should be) correct now !
With this, I'm expecting a huge changelog for the next version... Guess I'll have a lot of work !
Merci beaucoup nnayo ! En effet c'est mieux quand il y a un traducteur et un correcteur (surtout quand le traducteur ne sait plus du tout conjuguer ^^ )
Après les tournures ne me viennent pas naturellement non plus, mais bon, je suis informaticien (et dev aussi), du coup c'est des phrases que j'entends régulièrement, ça simplifie un peu ! (même si j'ai toujours cette hésitation à traduire ou non certain termes techniques, en général je laisse les plus courants, par exemple thread, wrapper, antialiasing, shaders, ... Enfin bon, il faudrait des avis de non-informaticiens pour savoir, surtout que les articles de bases sont quand même assez techniques !)
Bref, on en est venu à bout ! les anglophobes peuvent ENFIN suivre les dernières évolutions !
PS : Do not hesitate to send me a mail at :
slock (at) live (dot) fr
when you release a new article, I usually check the website rather often, but who knows...
forcément, c'est plus compliqué...
