DiRT, le meilleur jeu de bagnoles

Après le très médiocre Need for Speed ProStreet, je cherchais un nouveau jeu de bagnoles pour me défouler et je l’ai trouvé. Colin McRae DIRT est un excellent jeu de rallye extrêmement réaliste et varié. On y conduit toutes sortes de voitures, de buggy et même de camions sur toutes sortes de pistes plus ou moins poussiéreuses dans toutes sortes de courses.

Côté réalisme, outre une qualité graphique à couper le souffle, c’est surtout la physique des véhicules qui m’a estomaqué.

L’adhérence sur les différentes surfaces est parfaitement simulée en considérant séparément chacune des roues. De plus, les dégâts aux véhicules sont aussi très bien gérés :  non seulement la carrosserie conserve les traces des touchettes, mais la physique et les performances du véhicule sont altérées en cas de chocs. Un nid de poule un peu profond fausse légèrement la direction, mais une sortie de route peut sérieusement diminuer la tenue de route voire la puissance de votre voiture.

Un excellent jeu, indispensable si vous avez un volant branché à votre PC.

Publicités

librairie GLua

GLua est une librairie open source qui offre au programmeurs LUA des classes et functions qui singent celles disponibles en GLSL, le « OpenGL Shading Language ».

GLua a été spécialement conçue comme librairie de base pour Demoniak3D, pour fournir un ensemble cohérent avec les shaders GLSL.

Contenu:

  • vec3.lua : vecteurs et arithmétique 3D
  • mat3.lua : matrice et arithmétique 3D
  • vec4.lua : vecteurs et arithmétique 3D
  • glsl.lua : fonctions génériques suivant les prototypes glsl comme définis dans le livre « OpenGL Shading Language » by Randi J. Rost
  • test.X.lua : tests unitaires du module X

Utilisation et exemples:

L’utilisation des classes et fonctions est relativement simple.

Regardez les fichiers test.X.lua pour plus de détails et d’exemples.

Téléchargement:

GLua est disponible sur http://luaforge.net/projects/glua/ sous licence LGPL.

Détails d’implémentation:

  • les classes sont basées sur class.lua, décrite ici: http://lua-users.org/wiki/SimpleLuaClasses
  • glsl.lua offre des fonctions génériques fonctionnant sur les nombres et tables LUA, et donc avec toutes les classes matrice/vecteur. Elle utilise intensivement la « programmation fonctionnelle » pour ce faire:
    • la fonction « apply » est définie comme suit:
      --- applies a function to a table of parameters
      -- @param f : function to apply to each element in v
      -- @param v : (vector of) parameter(s) to f function
      -- @return : (vector of) result(s) of f(v)
      function apply(f,v)
      if type(v)=="number" then return f(v) end
      if type(v)=="table" then
      local res={}
      for i,x in ipairs(v) do res[i]=f(x) end
      return res
      end
      error("apply "..f.."("..type(v)..") not implemented")
      end
    • ainsi, les fonctions peuvent facilement être définies pour accepter des nombres, vecteurs et tables:
      function sin(rad)
      return apply(math.sin,rad)
      end
  • le produit scalaire est implanté de 2 manières distinctes :
    • dans l’opérateur « exposant » ^ des classes
    • comme fonction générique dot(p1,p2) dans glsl.lua

GLua library

GLua is an open source library which provides LUA programmers with classes and functions that mimic those available in GLSL, the OpenGL Shading Language.

GLua was especially designed as a base library for the Demoniak3D real-time engine, as it provides a consistent framework with GLSL shaders.

Contents:

  • vec3.lua : 3D vectors and arithmetic
  • mat3.lua : 3D matrix and arithmetic
  • vec4.lua : 4D vectors and arithmetic
  • glsl.lua : generic functions following glsl prototypes as defined in book « OpenGL Shading Language » by Randi J. Rost
  • test.X.lua : unit test of module X

Usage & Samples:

Usage of the classes and functions is pretty straightforward.

Check the test.X.lua modules for more details or examples

Download:

GLua is available on http://luaforge.net/projects/glua/ under LGPL licence.

Implementation details:

  • the classes are based on class.lua, described on http://lua-users.org/wiki/SimpleLuaClasses
  • glsl.lua offers generic function that work on LUA numbers and tables, and therefore all vector / matrix classes. It makes extensive use of functional programming to achieve this:
    • the « apply » function is defined as follows:
      --- applies a function to a table of parameters
      -- @param f : function to apply to each element in v
      -- @param v : (vector of) parameter(s) to f function
      -- @return : (vector of) result(s) of f(v)
      function apply(f,v)
      if type(v)=="number" then return f(v) end
      if type(v)=="table" then
      local res={}
      for i,x in ipairs(v) do res[i]=f(x) end
      return res
      end
      error("apply "..f.."("..type(v)..") not implemented")
      end
    • then, functions can easily be defined to support numbers, vectors, or matrices:
      function sin(rad)
      return apply(math.sin,rad)
      end
  • dot product is implemented in 2 different ways :
    • through the « power » ^ operator in classes
    • as a generic dot(p1,p2) function in glsl.lua

Phun – bac à sable de physique 2D

Une autre petite appli sympa de physique en temps réel : Phun.

 

On peut la télécharger ici, et partager des fichiers d’exemple ici. Il y a même une combine pour faire des engrenages. Vais essayer de faire un échappement d’horlogerie (le test qui tue…)

Visualisation de Molécules

Tombé par hasard sur VMD – Visual Molecular Dynamics, un logiciel scientifique Open Source disponible sur Windows, Linux et MacOS-X. Il permet de visualiser en 3D temps réel des molécules complexes et se combine avec de nombreux plugins et autres logiciels pour réaliser des rendus assez spectaculaires :

La modélisation des molécules demande énormément de puissance de calcul car il faut simuler les attractions/répulsions électrostatiques entre de très nombreux atomes pour trouver les positions de chacun. L’équipe de développement de VMD a beaucoup utilisé les GPU pour accélérer ces simulations, et CUDA en particulier (seulement sur Linux pour l’instant).

L’article « GPGPUs: Neat Idea or Disruptive Technology? » sur ce sujet est très intéressant : l’auteur montre que les GPU peuvent apporter un gain d’un facteur 10 en puissance de calcul, mais que ce n’est pas suffisant pour changer radicalement la face de l’informatique.

VMD supporte une ribambelle de formats de fichier de représentation des molécules dont certains, comme PDB, sont des fichiers textes, donc potentiellement importables dans d’autres logiciels …

Fractales IFS, Flame, Moutons Electriques et GPU

Un « système de fonctions itérées » ou « Iterated function system » (IFS) permet de produire des « fractales autosimilaires » ressemblant parfois à des feuilles, comme cette fougère calculée par Paul Nylander en Mathematica.

Les fractales « flamme » sont une généralisation des IFS inventée par Scott Draves. Son algorithme est décrit en détail ici. Ils produisent des motifs plus abstraits mais plus colorés, qu’il est possible de faire varier progressivement pour créer des animations spectaculaires.

Les « flame fractals » ont été popularisées par le superbe screen saver « Electric Sheep » que j’ai utilisé un temps avant de me rendre compte que c’était en réalité un simple player de vidéos téléchargées munies d’un système de vote. En effet, le calcul des « moutons électriques » est très lent même sur un processeur puissant, et c’est un autre logiciel, Apophysis qui est utilisé pour les générer.

Serait-il possible de calculer des « flame fractals » sur un GPU, voire même en temps réel ? Jusqu’ici, trois tentatives ont été faites:

  1. Simon G. Green, de nVidia, a présenté « GPUflame – a GPU-accelerated IFS fractal renderer« au SIGGraph 2005. Son executable pour Windows avec un shader en Cg (ne fonctionnant donc pas avec une carte ATI…) est disponible. Sur une GeForce 6600, il tourne à 2 fps environ. Exemple de résultat:
  2. RapidMind a réalisé un « Electric Sheep » sur GPU sur la base de leur framework C++ dont j’ai parlé ici. Il fonctionne à 10 fps environ sur une GeForce 8800, soit 60x plus vite que sur un Intel Duo 6700. Ce programme n’est hélas pas disponible, on ne peut qu’admirer la video:
  3. Christopher Emory Moore a codé « GPU Flame Fractal » en GLSL + LUA, sur la base de son surprenant GL Lua Shell qui lui permet de tourner sur Mac, PC, et Linux. Et le code source est disponible! Il produit des flammes de 16’000 points à 85fps en faisant 20 itérations par frame. Le résultat est un peu brut, mais quand ça bouge c’est très joli:

reste plus qu’à en faire une version pour Demoniak3D

Programmation des GPU en C++

La montée en puissance des GPUs s’est accompagnée du développement de langages de programmation spécifiques comme Cg ou GLSL pour tirer parti de leurs performances. La syntaxe de ces langages est proche du C, mais ils sont clairement destinés à la programmation d’applications graphiques, et demandent une bonne connaissance du fonctionnement interne des GPU.

Pour exécuter des programmes plus généraux sur les GPUs, l’idéal serait de disposer de compilateurs capables de générer « tout seuls » du code optimisé pour les GPU à partir d’un source C++ standard. On n’y est pas encore, mais ça progresse.

Actuellement, il existe des librairies permettant d’utiliser le GPU comme coprocesseur au travers d’un API comme:

Dans sa thèse de doctorat « GPU++ – An Embedded GPU Development System for General-Purpose Computations » Thomas Jansen a franchi une étape de plus en permettant de développer des shaders directement en C++ à l’aide d’une librairie qui génère du code GPU (je n’ai pas encore compris comment) à la compilation sur un compilateur standard.

RapidMind propose une « plateforme » basée sur une idée similaire, mais en la généralisant encore. Leur système permet d’optimiser le même code sur des processeurs aussi différents que les GPU multi-coeurs, les GPU et le processeur Cell qui équipe les PlayStation 3. Mais comme on le voit ci-dessous, le langage C++ est difficilement reconnaissable derrière l’utilisation d’un API et de macros:

Cette approche est cependant très générale et efficace, comme on le voit sur la page des « Case Studies« , qui inclut au moins deux domaines qui m’intéressent:

  1. La simulation des fluides
  2. Les fractales. J’y reviens dans un prochain article

Documents intéressants:

VideoTrace : modelisation 3D à partir d’une video

l’ Australian Centre for Visual Technologies a développé VideoTrace, une technologie assez extraordinaire permettant de modéliser un objet réel en 3D à partir d’un bout de film. Démonstration:

C’est encore au niveau du proto, mais il fait peu de doute qu’on verra cette technologie très prochainement intégrée à nos outils de modélisation préférés. Et peut-être que dans quelques années il n’y aura même plus besoin de dessiner sur les images pour aider…

référence : Anton van den Hengel, Anthony Dick, Thorsten Thormählen, Ben Ward, Philip H. S. Torr « VideoTrace: Rapid interactive scene modelling from video« , 2007, SIGGRAPH 2007 Conference Proceedings

Mathias Müller : Simulation temps réel de fluides dans les jeux

Le cours « Real Time Fluids in Games » de Matthias Müller-Fischer présenté à la conférence SIGGRAPH 2007 est une remarquable synthèse des différents problèmes posés par la simulation réaliste des fluides. L’auteur propose de distinguer 3 situations et les solutions correspondantes:

  1. « L’eau procédurale » (Procedural Water) pour représenter de vastes étendues océaniques ou de l’eau sans interaction physique avec le jeu.
  2. La technique des « champs de hauteur » (Heightfield Fluids) permet de calculer en temps réel des vagues causées par des interactions physiques sur de petites étendues d’eau.
  3. Les « fluides basés sur les particules » (Particle Based Fluids) sont proposés pour traiter les situations où le fluide gicle ou s’écoule de façon turbulente.

Procedural Water

Cette approche vise un but purement visuel. La physique n’est utilisée que pour précalculer des textures et les animer pour obtenir un rendu réaliste sans calculs supplémentaires. L’article de Yuri Kryachko « Using Vertex Texture Displacement for Realistic Water Rendering » paru dans GPU Gems 2 explique par exemple comment des images telles que celle ci-dessous sont générées dans le jeu Pacific Fighters

Heightfield Fluids

Cette technique consiste à modifier en temps réel un maillage représentant la surface de l’eau, modélisée comme une membrane sur laquelle se propagent les vagues. Matthias Müller la décrit de façon très complète dans son document, largement assez pour l’implanter dans une démo Demoniak 3D, par exemple (encore un projet en cours de plus, je vous en reparle bientôt…)

La principale limitation de cette méthode est que la hauteur du fluide ne peut avoir qu’une seule valeur en chaque poitn de la surface. Matthias montre comment contourner cette limitation dans 2 cas:

  1. pour les objets flottants que l’eau peut partiellement recouvrir ou des objets semi immergés, il montre qu’une seule variable supplémentaire par point du maillage permet d’en tenir compte pour modifier la surface de façon réaliste
  2. l’article de  N. Thürey, M. Mueller-Fischer, S. Schirm, M. Gross « Real-time Breaking Waves for Shallow Water Simulations » montre comment utiliser un système de particules pour représenter la crête des vagues, les déferlantes et les rouleaux.

Toutes ces techniques sont illustrées sont illustrées dans cette video:

Après avoir cofondé Novodex à Zürich, Matthias Müller y travaille pour Ageia, entreprise qui développe et commercialise l’API PhysX  permettant d’intégrer facilement la simulation physique aux jeux ainsi qu’un « Physical Processing Unit » (PPU) accélérant notablement les calculs correspondants. Le support des « heightmap fluids » est annoncé pour la prochaine version de PhysX.

Particle Based Fluids

Quand le fluide gicle et s’écoule de façon turbulente, Matthias Muller propose de modéliser le fluide comme un ensemble de particules en interaction entre elles et avec l’environnement. Cette méthode est très différente de celle que j’avais décrite ici, basée sur la résolution des équations de la mécanique des fluides. Elle présente l’avantage de pouvoir plus facilement représenter les interactions entre le fluide et son environnement, comme on le voit dans cette vidéo montrant plusieurs exemples:

Par contre, et comme on le voit déjà dans l’exemple de la vague déferlante, le réalisme visuel des fluides représentés par des particules n’est pas terrible, ce qui est assez facile à comprendre.

Autres références:

BioShock

J’ai vachement bien fait d’upgrader mon PC, ça m’a permis de dévorer LE jeu de 2007 :

BioShock est incroyablement prenant grâce à une ambiance unique soutenue par une réalisation quasiment irréprochable. On se retrouve plongé dans Rapture, un genre de Metropolis sous-marin des années 1950 dans lequel le génie génétique a prolongé les « expériences médicales » nazies, une atmosphère délirante et stressante mais qui nous emmène de surprise en découverte.

Le « gameplay » est excellent et très bien pensé, notamment le fait que les munitions et autres ressources sont relativement rares et qu’il faut donc bien explorer le jeu et utiliser au mieux ce qu’on y trouve plutôt que de « canarder dans le tas ».

A noter cet excellent jeu doit définitivement être réservé aux adultes. J’avoue avoir été moi-même dérangé par le choix cornélien concernant le sacrifice des « petites soeurs » : faut-il vraiment étriper de jolies petites filles pour obtenir plus d’Adam, cette ressource indispensable à la poursuite du jeu ?

A part ça, le jeu est techniquement magnifique, mais il requirt une machine dernier cri. J’ai particulièrement apprécié le rendu de l’eau (un sujet qui m’intéresse pas mal) que l’on trouve un peu partout sous divers aspects. La déformation de la vision lorsque le jouer passe sous une cascade est particulièrement réussie, entre autres.

La seule vraie critique concerne un point énervant : il n’est pas possible de reconfigurer les touches A, Q et Z du clavier français pour les changer en  Q, W et A pour correspondre au clavier suisse ! Impossible de jouer pour un gamer suisse habitué aux FPS ou ces touches sont devenues le standard poru contrôler les déplacements. Honte aux développeurs. Bouh! . Heureusement, on peut s’en sortir en éditant un fichier de configuration, mais c’est pénible…