Sur la mailing list d'ioquake3, Stephan Reiter viens de poster un message concernant son travail : raytracing (ou lancer_de_rayon temps réel d'Elite force, jeu basé sur le moteur de quake 3.
Des vidéos sont disponibles http://youtube.com/watch?v=jLFrP0c7VWw http://youtube.com/watch?v=C_6Icf2m_C4
Le lien sur les archives de la mailing list http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50:mss:2281:20080(...)
Il y a de cela plusieurs années, quake 3 avait déjà eu un mode "lancé de rayons", mais il fallait beaucoup de machine. Là, sur un AMD Athlon X2 3800+ ça marche (mais sous une petite résolution)
Des vidéos sont disponibles http://youtube.com/watch?v=jLFrP0c7VWw http://youtube.com/watch?v=C_6Icf2m_C4
Le lien sur les archives de la mailing list http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50:mss:2281:20080(...)
Il y a de cela plusieurs années, quake 3 avait déjà eu un mode "lancé de rayons", mais il fallait beaucoup de machine. Là, sur un AMD Athlon X2 3800+ ça marche (mais sous une petite résolution)
> Lire le journal (15 commentaires, moyenne: 3).
Vous avez demandé le commentaire #910461.



compléments
Pour compléter ce journal pas très explicite, voici deux articles intéressants sur le sujet:
http://www.pcper.com/article.php?aid=455
http://www.pcper.com/article.php?aid=506
D'après ce que j'ai compris (je précise que je suis pas spécialiste):
Le raytracing ça permet de faire des choses plus réalistes sans se prendre la tête. Par exemple gérer les ombres est simplissime alors qu'en "rasterisation" (OpenGL/Direct3D) c'est beaucoup moins trivial.
D'autre part le calcul peut être hautement parallélisable puisqu'on dessine pixel par pixel. En gros doubler le nombre de coeur d'un processeur permet d'effectivement (presque) doubler les perfs. La techno peut donc tirer partie de l'évolution actuelle des procs. Intel semble d'ailleurs promouvoir cette techno...
Enfin, pour les résolutions PC standard, la quantité de calcul est plus importante qu'en OpenGL/Direct3D. Mais la durée de calcul augmente beaucoup moins vite qu'en rasterisation avec la complexité de la scène. Ce qui signifie qu'une fois qu'on sera capable de rendre en temps réel un jeux avec une résolution correcte, on sera rapidement à même d'avoir des scènes beaucoup plus complexes que celles actuellement possibles avec les techniques actuels.
Voilà voilà. Le raytracing c'est (peut-être) l'avenir du jeux vidéo.
En plus ça utilise des processeurs généralistes donc pas de problème de drivers! Bon, d'ici que ce soit utilisable...
[^]Re: compléments
En plus ça utilise des processeurs généralistes donc pas de problème de drivers!Et tu crois que les constructeurs de carte 3D vont laisser faire ?
Pan ! Pan !
Ne pas utiliser : traplinuxfrnico@univ-nantes.Fr
[^]Re: compléments
Aucune idée. Mais il semblerait que les GPU actuels soient pas trop adaptés aux type de calcul demandés ici. Mais je me trompe peut-être.
D'ailleurs la question serait plutôt: est-ce que nVidia va laisser faire?
ATI maintenant c'est AMD, donc ils sont bien placés pour aller dans les deux directions. Et Intel (qui fait également beaucoup de chipsets graphiques) a tout intérêt à promouvoir cela pour valoriser ses processeurs multi-CPU.
[^]Re: compléments
Rien ne les empêche de mettre un Intel Core ou équivalent sur une carte PCIe et de vendre ça sous le nom GeForce 4930500+ Deluxe GTS...
Bon j'exagère, mais je pense que les constructeurs de carte 3D sauront s'adapter et marketer.
Et puis, est-ce que le raytracing ne peut pas aussi tirer partie des GPU actuels ?
[^]Re: compléments
Si le raytracing se satisfait de calcul en real_32 pas trop précis, oui.
Avec les nouveaux framework du genre NVidia Cuda, tu peux facilement délester le processeur de calculs simple comme addition et multiplications.
D'ailleurs, en bidouillant opengl, tu peux déjà le faire, mais c'est un peu tordu.
Je vais essayer de creuser le concept, je vous en reparlerai.
[^]Re: compléments
Concernant l'utilisation possible du GPU, je cite Stephan Reiter[1] :
> By the way: as far as I gathered, most of the raytracing stuff is CPU
> based. Are there any plans to load tasks to the GPU?
I actually tried that with a GeForce 7 in 2006 and gave a poster
presentation at a raytracing conference. But the idea didn't turn out so
well: With current GPU architectures there's simply too much performance
wasted when communicating CPU<->GPU, especially read-backs are problematic
(even with PCI-Express). A CPU-only implementation running on two cores
outperformed the graphics card by a factor of 4-5. Using the GPU as an
additional processing unit to the CPUs also yields a reduction in
performance due to the associated overhead.
autrement dit (traduction très approximative) que la communication entre le CPU et le GPU consomme trop de ressource par rapport à l'utilisation d'un cœur supplémentaire
[1]http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50:mss:2290:jhhho(...)
Ubuntu is an ancient african word meaning : "I can't configure Debian"
[^]Re: compléments
En fait si c'est possible, mais c'est ultra tordu.
Le problème est que ça n'est intéressant que pour des calculs massifs sur de grosses quantités de données, quand l'algo est "utilisable"
Par exemple, on explique comment faire Y = Y + a.X où Y et X sont des vecteurs à n dimension (n très grand) et a un scalaire.
http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutori(...)
Plus d'infos ici :
http://www.gpgpu.org/developer/index.shtml#conference-tutori(...)
Effectivement, si tu veux veux multiplier 3 matrices et un vecteur, passe ton chemin, vu le bordel que c'est de charger des matrices dans la pile et de les multiplier à coup de glMultMatrixf, c'est forcément lent. Mais si on arrive à bidouiller pour profiter des opérations de très (trop) haut niveau de la carte dispo en openGl, alors oui il y a des choses à faire.
De plus, avec les glShadingLanguage on a un outil plus flexible :
http://www.ozone3d.net/tutorials/mandelbrot_set.php
Donc à voir et ça ne fait que commencer