Journal Raytracing temps réel

Posté par .
Tags : aucun
0
4
mar.
2008
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)
  • # compléments

    Posté par . Évalué à 10.

    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

      Posté par (page perso) . Évalué à 2.

      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 ?
      • [^] # Re: compléments

        Posté par . Évalué à 3.

        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

        Posté par . Évalué à 4.

        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

          Posté par (page perso) . Évalué à 3.

          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.

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: compléments

            Posté par . Évalué à 2.

            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(...)
            • [^] # Re: compléments

              Posté par (page perso) . Évalué à 3.

              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

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # Mouarf

    Posté par . Évalué à 3.

    heu ce faire chi.. à foutre du raytracing dans un moteur 3D temps reel et faire une demo dans une video qui me rappel mes premiers émois sexuel sur Atari ST ...

    Enfin moi je dis ca, je dis rien ...
    • [^] # Re: Mouarf

      Posté par (page perso) . Évalué à 1.

      C'est vrai, quand on dit raytracing on pense tout de site réflection, réfraction etc. Ici rien, je ne vois pas la différence avec une représentation 3D habituelle. Peut être que ça va se développer par la suite, et qu'on finira par avoir des jeux en vrai lancé de rayon ( et là ça sera un vrai bonheur visuel !! )

      Par contre sur la vidéo, on voit la représentation par triangles. Dommage, le raytracing permettrait de s'en passer pour les primitives, et cela permettrai de décharger la mémoire en nombre de polygone. Après c'est peut être la charge du processeur qui ne tiendrait pas..

      À quand un jeu présentant des images aussi belles que sur l'irtc ? :-)
      • [^] # Re: Mouarf

        Posté par . Évalué à 2.

        Je ne sais pas si tu as vu les vidéos de Q3, mais ils y avaient ajoutés tout ce que tu demande dedans. C'était assez impressionnant à l'époque.
        • [^] # Re: Mouarf

          Posté par (page perso) . Évalué à 1.

          Non, je n'avais pas suivi l'actualité sur quake3 j'avoue. Était-ce en raytracing ? Je sais que c'est facile de faire des effets de réflections en 3D ( en basant ça sur le principe d'une image environementale, ça peut être assez rapide ). Le faire en lancé de rayon donne cependant des résultats différents ( par exemple en prenant en compte l'indice de réfraction pour la lumière au travers d'un solide)..

          Ici on n'a rien de tout ça.. mais peut être est-ce à venir par la suite..
          • [^] # Re: Mouarf

            Posté par . Évalué à 2.

            Et bien le principe était différent. Ici, ça à l'air d'être une modification d'openGL pour utiliser le RT sans modification de l'API. Alors que sous Q3, il avait modifier le moteur de jeu pour qu'il utilise openRT, une librairie équivalante à openGL avec les même fonctions de base mais avec des extensions permettant d'utiliser le plus du RT comme les formes primitives, la réflection, etc... Ce qui permet d'adapter rapidement un jeu pour cette librairie tout en gardant sous le coude tous les avantages du RT.
        • [^] # Re: Mouarf

          Posté par . Évalué à 1.

          Pour du quake 3 en raytracing temps réel, il y avait eu http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/ (screenshot http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/screenshot(...) ) c'était impressionnant, mais ça tournais sur plusieurs machine. Là, c'est toujours le même moteur, mais ça tourne sur une seule machine.
          Bien sûr le pb reste l'augmentation de la résolution, c'est ce qui demande le plus de puissance. Mais l'avantage, c'est que le lancer de rayons utilise beaucoup les calculs parallèle, et donc trouve sont bonheur dans les nouveaux processeurs a plusieurs cœur.
          L'avenir proche est sûrement dans un mélange de rasterisation et de raytracing, permettant ainsi d'aller plus vite avec la 1ère et d'être plus précis avec la 2ème, notamment pour les collisions d'objet 3D
          • [^] # Re: Mouarf

            Posté par . Évalué à 2.

            D'après un des articles sont j'ai laissé le lien plus haut, ça serait une mauvaise idée de tenter de mixer les deux technos. Elles sont trop différentes et les gains obtenus en tentant tout de même de les mélanger peu intéressants.
  • # Bof.

    Posté par . Évalué à 6.

    Le raytracing en temps réel, pourquoi pas.
    Par contre, la radiosité en temps réel, là ça va devenir sympa :-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.