Retrospective de la semaine 2012-07-31 - ap0

Salut à tous !

Le screenshot de la semaine montre une vieille fonctionnalité dont nous n’avions jamais parlé auparavant : les ombres en temps réel !
ombres

Bien qu’il n’y aura pas de nouvelle version d’OpenMW ce mois-ci, beaucoup de choses se sont passées durant cette semaine. Récapitulons :

Tout d’abord, nous avons un nouveau développeur : _greye, qui vient de boucler sa première tâche (De la refactorisation : placer tout le fourbi CreatureStats dans une belle classe) en un seul jour. Il a enchaîné sans trembler sur une 2e (maintenance et amélioration du code ayant trait au lâcher d’objets), qu’il a également promptement terminé. Bravo à lui, et bienvenue dans l’équipe !

nhydock, un autre nouveau développeur, s’occupe du contrôle de la caméra (la vue du joueur) : avec un peu de chance, le joueur ne sera bientôt plus un nain !

Attention, cette partie de l’article est un peu technique !
Le nouveau système de shaders de scrawl a été mergé dans le master. Qu’est-ce que ça change concrètement pour OpenMW ? Avant, nous utilisions le CG toolkit d’Nvidia. Il fonctionne avec DirectX et OpenGL, mais ne donne des performances acceptables que sur des cartes Nvidia (surprenant hein ?). Pas question de laisser tomber les possesseurs de cartes ATI ou Intel. De plus, le toolkit n’étant pas libre, et uniquement disponible pour GNU/Linux, OSX et Windows, il était problématique de l’inclure dans OpenMW.

C’est pour ça qu’en général, les développeurs écrivent leurs shaders deux fois : une en GLSL pour l’OpenGL, et une en HLSL pour DirectX, ou pire, se concentrent sur DirectX et oublient l’OpenGL.

Mais grâce à Scrawl et à sa bibliothèque nommée shiny, il suffit d’écrire une fois les shaders, et ils seront compilés soit en GLSL, soit en HLSL ! Mais ça n’est pas tout, et Scrawl vous l’expliquera mieux que moi :

– High-level layer on top of OGRE’s material system. It allows you to generate multiple techniques for all your materials from a set of high-level per-material properties.

– Several available Macros in shader source files. Just a few examples of the possibilities: binding OGRE auto constants, binding uniforms to material properties, foreach loops (repeat shader source a given number of times), retrieving per-material properties in an #if condition, automatic packing for vertex to fragment passthroughs. These macros allow you to generate even very complex shaders (for example the Ogre::Terrain shader) without assembling them in C++ code.

– Integrated preprocessor (no, I didn’t reinvent the wheel, I used boost::wave which turned out to be an excellent choice) that allows me to blend out macros that shouldn’t be in use because e.g. the shader permutation doesn’t need this specific feature.

– User settings integration. They can be set by a C++ interface and retrieved through a macro in shader files.

– Automatic handling of shader permutations, i.e. shaders are shared between materials in a smart way.

– An optional « meta-language » (well, actually it’s just a small header with some conditional defines) that you may use to compile the same shader source for different target languages. If you don’t like it, you can still code in GLSL / CG etc separately. You can also switch between the languages at runtime.

– On-demand material and shader creation. It uses Ogre’s material listener to compile the shaders as soon as they are needed for rendering, and not earlier.

– Shader changes are fully dynamic and real-time. Changing a user setting will recompile all shaders affected by this setting when they are next needed.

– Serialization system that extends Ogre’s material script system, it uses Ogre’s script parser, but also adds some additional properties that are not available in Ogre’s material system.

– A concept called « Configuration » allowing you to create a different set of your shaders, doing the same thing except for some minor differences: the properties that are overridden by the active configuration. Possible uses for this are using simpler shaders (no shadows, no fog etc) when rendering for example realtime reflections or a minimap. You can easily switch between configurations by changing the active Ogre material scheme (for example on a viewport level).

– Fixed function support. You can globally enable or disable shaders at any time, and for texture units you can specify if they’re only needed for the shader-based path (e.g. normal maps) or if they should also be created in the fixed function path.

Cette bibliothèque devrait simplifier la vie des développeurs, et plus encore : développée pour Ogre (et non pas spécifiquement pour OpenMW), elle devrait connaître un avenir radieux chez d’autres projets. Hourra pour le libre !

Mais assez de blabla technique, passons aux belles images :
sous-marin
eau claire

Si ça ne suffit pas à vous rendre fébrile, cher lecteur, attendez de voir la suite :

Depuis des temps immémoriaux, dans quasiment chaque rétrospective, nous vous parlions du système d’animations, et de ses avancées constantes : cette saga touche à sa fin. Hé oui, le nouveau système d’animations attend vos retours dans le master !
Les efforts de jhooks1 et de Chris ont porté leurs fruits.

Détaillons un peu : les animations sont de la partie depuis bien longtemps, mais elles n’utilisaient pas le système d’animation d’Ogre : c’était nous (OpenMW) qui bougions l’armature. Ça n’était pas vraiment efficace, et certaines créatures (vous vous souvenez des loups-garous et des fantômes ancestraux ?) ne s’animaient pas correctement. Mais ces soucis sont maintenant réglés, et Ogre est utilisé au maximum pour les animations ! Le hardware skinning (Déporter une partie des calculs du CPU vers le GPU pour aller encore plus vite.) est à notre portée pour la version 1.0 !

Zini a fini d’implémenter l’usage de potions, il y a même le son quand vous en buvez une ! Il continue (toujours) au passage de refactorer du code.

Corristo se débrouille pour qu’OpenMW fonctionne sur OSX en corrigeant les bugs signalés.

Nous avons migré : Slashdot nous a bien montré que notre infrastructure web n’était pas très robuste. Nous avons donc pensé au cloud d’Amazon, mais ça n’était pas très pratique. Nous avons donc changé : en ce moment, OpenMW.org est hébergé sur un serveur MyDevil.net, pendant que le bugtracker et le forum sont sur un serveur OVH (Société française !). Et pour être paré à toutes enventualités, OpenMW.org est protégé par un proxy CDN de Cloudflare. Nous sommes parés !

Fork me on GitHub

You must be logged in to post a comment.