Fluides : en temps réel aussi

Autre avancée spectaculaire de nVidia : l’intégration d’une méthode (approximative) permettant de calculer l’écoulement d’un fluide en temps réel en exploitant un GPU. ça donne ça:

La méthode utilisée est la « Smoothed particle hydrodynamics » (SPH), qui approxime le fluide par des sphères dont le mouvement et la taille de chacune est influencée par ses voisines les plus proches.

Un des précurseurs (le précurseur ?) de cette méthode est Matthias Muller (de Zürich, en Suisse…) dont j’ai déjà parlé ici et qui a travaillé sur le moteur PhysX chez Ageia, l’entreprise rachetée l’an passé par nVidia … Depuis, la méthode a été appliqueé à d’autres domaines, notamment la simulation de phénomènes astrophysiques dont je causerai très bientôt sur Dr. Goulu.

Une chose est sure : bientôt les jeux vont devenir nettement plus aquatiques. Cool.

download (si vous avez une GeForce 8600 ou mieux…)

source: shadows.fr

Publicité

Ray Tracing temps réel

Il y a quelques temps j’avais commencé un article sur le Ray Tracing sur GPU, mais ça semblait être encore de la science-fiction. Mais là, nVidia a présenté au SIGGRAPH 2008 une belle bagnole rendue en ray tracing temps réel (sur 4 cartes Quadro FX 5800) à 30 fps en 1920×1080.

Pour les novices, le ray tracing ou  lancer de rayons est la technique privilégiée pour le rendu ultra-réaliste des films d’animation, où on peut se permettre de calculer chaque image pendant des heures, alors que les jeux et autres applications 3D temps réel sont basées sur la rastérisation.

• le ray tracing consiste à calculer le trajet des rayons lumineux qui arrivent à l’observateur. On obtient ainsi des effets optiques comme les réflections et la réfraction très corrects, comme on peut les voir dans les reflets de la carosserie ci-dessus. Le temps de calcul dépend donc beaucoup de la taille de l’image, mais on peut le « paralléliser » en partie si on dispose de plusieurs processeurs.
• la rastérisation calcule des effets de lumière simplifiés sur des triangles composant la scène 3D. L’optique physique est nettement moins parfaite, mais on parvient à rendre des images très réalistes beaucoup plus rapidement.

Jusqu’ici, les cartes graphiques utilisaient des processeurs optimisés pour la rastérisation (GPU). Mais les GPU évoluent et deviennent de plus en plus des processeurs plus généraux, massivement parallèles, très puissants. On pressentait qu’un jour, qui approche à grands pas, les GPU parviendraient à calculer une image en ray-tracing en une fraction de seconde au lieu de minutes, ce qui pourrait bouleverser non seulement l’industrie du graphisme 3D, mais aussi celui des processeurs car la puce d’intel n’est désormais plus la plus puissante de votre PC, donc toute l’informatique …

sources: shadows.fr et hothardware

1. « The Coming Combo Of The CPU And GPU, Ray Tracing Versus Rasterization, And Why Billions Of Dollars Is At Stake »
2. Dean Calver. « Real-Time Ray Tracing : Holy Grail or Fools’ Errand? » , Beyond3D, 12th Oct 2007
3. Jeffrey Howard « Real Time Ray-Tracing: The End of Rasterization?« , Intel, October 10, 2007
4. Nathan A. Carr, Jared Hoberock, Keenan Crane, John C. Hart « Fast GPU Ray Tracing of Dynamic Meshes using Geometry Images », Proceedings of Graphics Interface 2006 (pdf)
5. Martin Christen « Implementing Ray Tracing on GPU« , 2005 Diploma Thesis, University of Applied Sciences Basel, Switzerland (pdf)

Historique du hardware 3D

En préparant ma prochaine présentation au Microclub, j’ai créer un historique du hardware 3D intitulé « History of 3D hardware and software » sur Dipity, un site permettant de créer des « timelines ».

Ca se présente comme ça:

Comme Dipity est un site « web 2.0 », vous pouvez compléter cette timeline si vous le souhaitez 😉

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:

• CUDA de nVidia et CTM d’ATI
• Shallows, un projet Open Source

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:

• Mike Houston «  General Purpose Computation on Graphics Processors (GPGPU) », 2005, ATI X1000 Series Launch, Ibiza, Spain

Ensembles de Julia calculés en temps réel par GPU

Retrouvé par hasard un travail très intéressant de Keenan Crane (dont on a déjà parlé ici) datant de 2005 sur cette page et dans cet article. Il s’agit d’un véritable tutoriel sur le ray-tracing en temps réel d’un objet mathématique particulier, l’ensemble de Julia, le tout calculé sur un GPU. Comme le dit Keenan, il y a deux problèmes avec l’ensemble de Julia:

1. il prend des siècles à calculer
2. il est totalement inutile

mais il est très beau, comme on le voit sur ces captures :

En fait, l’ensemble de Julia est un objet à 4 dimensions que l’on visualise par « tranche en 3 dimensions ». En coupant une tranche en 2 dimensions dans une direction particulière, on obtient d’ailleurs l’ensemble de Mandelbrot plus connu, que Demoniak3D calcule sur GPU de façon spectaculaire.

Un exécutable avec son code source sont disponible sur la page « Ray Tracing Quaternion Julia Sets on the GPU » de Keenan Crane. Il utilise

• d’une part un petit bout de code C basé sur GLUT pour implanter la méthode décrite dans l’article « Ray Tracing Deterministic 3-D Fractals » de John Hart
• d’autre part un fragment en Cg pour les calculs de l’ensemble de Julia.

Le problème, c’est que ce dernier code n’a plus l’air de fonctionner avec le tout récent Cg 2.0… Avant que je m’attaque à porter tout ceci en GLSL + LUa sur Demoniak 3D, est-ce que quelqu’un qui connait le Cg pourrait me dire ce qui cloche, voire corriger la version actuelle ?

Caustiques en temps réel

A peine avais-je terminé le post précédent qui présentait des textures de caustiques que je suis tombé sur un post de Level of Detail intitulé « Caustics Mapping: An Image-space Technique for Real-time Caustics » qui présente une nouvelle méthode permettant de calculer des caustiques en temps réel sur un GPU dur à Musawir A. Shah et Sumanta Pattanaik, de l’University of Central Florida.

La page Caustics Mapping: An Image-space Technique for Real-time Caustics présente leurs résultats, qui sont impressionnants car leur méthode permet même de tenir compte de la réfraction de la lumière avec un framerate très acceptable sur une vieille GeForce 6800 :

Je n’ai pas encore lu en détail leur article, mais l’idée de base est de calculer la texture de la caustique sur un principe simulaire au « shadow mapping », en déterminant le point d’arrivée sur la texture d’un rayon passant par chaque vertex du modèle. L’utilisation d’un algorithme itératif de Newton-Raphson permet d’éviter de faire du véritable « ray-tracing », opération peu adaptée au GPU, et d’atteindre des résultats qualitativement très acceptables en temps réel.

Bien envie de m’attaquer à ça avec Demoniak 3D …

La montée en puissance des GPUs

Dans les ordinateurs vendus depuis 2003 environ, le microprocesseur (CPU) fourni par Intel ou AMD n’est plus le composant le plus puissant, et souvent plus le plus couteux non plus. Désormais c’est le GPU, le Graphics Processing Unit, qui détermine largement la puissance d’un PC. Strictement limités au graphisme il y a peu, ces processeurs sont désormais capables d’effectuer certains calculs nettement plus vite que les processeurs classiques. Actuellement, la puissance de calcul du G80 de nVidia est 5 à 6 fois supérieure à celle du Core 2 Duo d’Intel, voire plus (1, 2).

puissance de calcul des GPU et CPU (source : BeHardware)

Conséquence immédiate :

Si vous achetez un ordinateur pour y faire fonctionner les applications les plus exigeantes, c’est-à-dire les jeux vidéo, il faut faire plus attention au choix du GPU qu’au CPU. Vous ne gagnerez que quelques pourcents de performance avec un CPU plus rapide qui vous coûtera quelques centaines de francs, alors que la même somme investie dans une carte graphique basée sur un GPU plus récent ou puissant peut doubler le nombre d’images / seconde (fps) de vos applications favorites.

Un peu d’architecture des processeurs

Relativité en temps réel

Un de mes vieux rêve est en train de se concrétiser : il devient possible de simuler des effets relativistes en temps réel, et donc d’envisager faire des jeux basés sur la relativité d’Albert.

Deux équipes sont bien avancées dans ce domaine :

1. D. Weiskopf à l’Uni de Tubingen a fait un vélo relativiste permettant de se promener dans les rues d’une ville ou la lumière se déplacerait à 30km/h au lieu de 300’000 km/s. Cette installation était à l’exposition Einstein de Berne en 2005, mais hors service quand j’y étais 😦
2. L’équipe australienne de Craig S. Savage a repris le flambeau de Chris Betts et a réalisé le « Real Time Relativity« , le premier simulateur relativiste pour PC. Il se manipule comme n’importe quel jeu video en 3D, mais utilise le processeur de la carte graphique (GPU) pour calculer les effets de la relativité (ça a l’air d’intéresser JeGX..)

Hyperion

Hypergraphics-3D est une entreprise genevoise en création qui va « faire très fort ». Son produit « Hyperion » est une version « professionnelle et facile à utiliser » des moteurs 3D utilisés dans les jeux pour faire du rendu et de l’animation en temps réel.

Par « professionnelle », il faut comprendre qu’Hyperion vise le réalisme et la qualité d’image pour la visualisation de produits industriels ou de constructions.

Exemple de rendu en temps réel obtenu avec Hyperion !

Hyperion est « facile à utiliser » car toute la scène à représenter, les informations d’éclairage, de matière (texture) , l’interactivité, les effets visuels spéciaux et bien d’autres choses sont décrites dans un seul fichier XML, éditable avec un éditeur de texte comme PsPad par exemple.