Voila un post ouvert, vos discussions m'interessent et non ce n'est pas un troll.
 
Je sais qu'il y en a quelques uns qui bossent dans la 3D temps réel et l'un des éléments clés de ce monde c'est la carte graphique.  
L'un des intérêts premiers d'un accélerateur graphique a été d'oter des taches dediées de la charge du processeur central. Au départ il s'agissait simplement de remplir rapidement des formes géométriques simples, puis on est passé progressivement au calcul de transformations géométriques, etc..
Apres quelques tentatives infructueuses, le hardware graphique a fini peu à peu à se conformer à un modele unique, principalement dicté par les deux APIs principales (DirectGraphics et OpenGL qui se copient mutuellement), ainsi que limité par ce que les designers de cartes savaient faire de mieux et de plus performant (si ce n'est pas performant ce n'est pas interessant).  
 
Que nous reserve donc le futur ? J'ai pensé à n axes de direction:
- Premier axe: la programmabilité. Peut-on atteindre un haut niveau de programmabilité et de flexibilité du CPU(interruptabilité, context switching, virtual memory) sans sacrifier ce qui donne au hardware graphique sa spécificité et sa performance ?  
- Deuxieme axe de discussion: le traitement géométrique. Peut-on s'abstraire du triangle ? Y aurait-il un sens a développer un hardware qui pourrait rasteriser des formes courbes comme des nurbs par exemple, ou traiter des solides selon la CSG. (je ne parle pas de generer des triangles)  
- Troisième axe: les méthodes de rendu. On est passé d'un stade où l'on était très proche du hardware (rasterisation simple), à un stade ou l'on cherchait a s'en extraire (hyper buffers, tiles, hardware TNL), puis on semble a nouveau se rapprocher du hardware (buffers généralisés). Evidemment si c'est vraiment la tendance l'imagination du constructeur de hardware va devoir etre serieusement limitée. En échange on pourrait voir arriver des méthodes de rendu temps réélle innovantes en software sur du hardware super flexible. Si au contraire on arrive a s'abstraire, on pourrait voir arriver du hardware capable de faire du ray tracing ou tout autre méthode differente de rendu de maniere bien plus rapide qu'avec une méthode software.
- Quatrieme axe: l'accélérateur graphique 3D comme base de tout rendu. C'est la promesse de certains moteurs de haut niveau comme celui de Longhorn ou d'autres tentatives. La fin de la spécificité du 2D (vu comme un simple cas particulier de la 3D).
- Quatrieme axe bis: le sampling. A l'heure actuelle il y a une multitudes de techniques pour eliminer les interferences, le moiré, les effets d'escalier et les clignotements. Tout cela bute sur la limite de la puissance de calcul et on a trois a quatre methodes qui se completent (mipmapping, supersampling, anisotropic filtering) ou se marchent sur les plates-bandes. Le triangle est-il le facteur limitant ici? A quoi bon rasteriser un triangle qui fait moins qu'un pixel sur l'écran? Et le flou (que ce soit de la mise au point ou du mouvement) comment le rendre avec ces rasteriseurs basés sur des pixels ?
- Cinquieme axe (sur CPC) : L'illumination. Quand on regarde ce qui est fait dans les super productions de Pixar, on se dit qu'il y a encore de la marge pour que le petit monde de la 3D temps reel n'ait pas grand chose a inventer pour la décennie a venir. On continue a se battre pour avoir des ombres sans defaut, des reflexions regulieres, de la luminosité globale dynamique, pour avoir simultanement de la saturation et de la nuance. Pourtant il y a peu on n'imaginait pas cependant avoir une maniere compacte et a decodage rapide de coder une distribution de reponse bidirectionnelle ainsi qu'une matrice de transfert pour l'eclairage global. Est-ce la direction a venir? difficile a dire en dehors de l'effet de mode et des limitations deja mises au jour. Et cela s'appuie sur un hardware qui a été designé pour faire "autre chose". Comment imaginer prendre en compte toutes ces opportunités? quelles sont celles que le hardware pourra rendre de maniere effective ?
 
Amis de la 3D :
A vos claviers..
 
LeGreg

(Bon je bosse pas dans la branche, j'essaye juste de suivre un peu ce qui se passe dans mon tps libre, donc bon, autant pour l'avis eclairé, histoire de dire j'ai meme pas encore eu le tps de voir les vs/ps 2.0...)
 
 
Perso un truc que je verrais bien, c'est l'implantation de systeme de VSD sur la carte. DX9 a maintenant des query permettant (si le driver le veut bien) de connaitre le nombre de pixel ayant passé le zb, mais je ne sais pas ce que ca vaut en terme de perfs (et aucune idee de ce que les dernieres R9700 / gfFX apportent de ce coté la. Me semblait avoir entendu de Hierarchical Z-buffer fut un tps, mais c'est bien tout). C'est pas directement du rendu mais ca prolongerait l'orientation "tout sur le GPU" (il faut quand meme reconnaitre que les HDEB/IOM/... seraient quand meme tres bien sur le GPU, c'est balot de faire du rendu soft alors qu'on a un monstre a triangle a portée de main )
 
La programmabilite peut largement etre amelioré, un acces plus ou moins aleatoire au contenu d'un vb lors du rendu ne serait pas une mauvaise idée par exemple. Voir meme de la generation de triangle directement dans la carte ? A propos triangle, je ne sais pas si on se debarassera du triangle dans l'immediat, on est y encore bpc attaché. Par ailleurs, est ce que cela en vaudrait la peine ? Surtout pour les constructeurs, remettre tous un tas de transistors alors que finalement une tesselation elevée donnerait probablement le meme resultat visuel en utilisant l'existant....
 
Sinon tout petit HS, niveau illumination il semblerait qu'y ait un truc qui soit en passe de devenir a la mode c'est le Spherical Harmonic Lighting. Je connais que le nom, mais je le vois revenir de plus en plus souvent (comme avec les shadow volumes y'a pas si lgtemps ) t'as plus d'info dessus ? Perfs/couts/requirement ? (J'ai une doc de 47 pages mais j'ai pas encore eu le courage de me plonger dedans)

j'ai rajoute un paragraphe que j'avais prevu mais qui a disparu a la redaction
(journee 9h30 du matin, 9 heures du soir ca use et j'suis pas encore couché )
 
LeGreg

 
Je suis sensé en deboguer l'assembleur et je n'ai jamais ecrit un pixel shader de ma vie .
 

 
Hmm oui donc ca irait dans le sens de l'utilisation du hardware tel qu'il est designé maintenant. Ceci dit je n'ai pas dit qu'on allait tout revolutionner. Il y a encore une logique economique qui gouverne tout ca. Les asynchronous query sont quelque chose que doivent exposer les drivers tout simplement. Il n'y a pas que la visibilité, il y a des infos de debug et de performance en temps réél.  
 

 
Oui cela va encore dans le sens du hardware actuel. Tu as vu les specs d'OpenGl 2.0? Je crois qu'il y a quelque chose sur les buffers generalisés. ATI appelle ca des über buffers il me semble.  
 
Pour ce qui est de l'acces aleatoire au vb j'ai du mal a voir?
 

 
Cf le fait d'arriver a un triangle qui fait moins d'un pixel sur l'ecran.
 

 
J'en parle dans mon axe 5.
Tu as deux choses (deux papiers principaux de Peter Pike Sloan  et des derivées dont un de Sony sur la meilleure maniere d'appliquer une rotation aux coefficients spheriques).  
 
En gros si tu as une BRDF (bidirectional reflectance distribution function), et que tu fixes l'une des directions (la vue), alors tu as une fonction de distribution spheriques que tu peux ecrire sous forme d'une suite infinie de fonctions spheriques (spherical harmonics). Si tu ne prends que les premiers termes tu as une approximation qui est bonne quand la distribution a des variations de basse frequence (comme pour la transformée de fourier).  
Quel est l'interet ? de pouvoir appliquer a cette fonction de reflectance une distribution de lumiere sous la meme forme pour calculer rapidement la valeur de l'eclairement en un point. (rapidement = un produit scalaire). Cela repose sur le fait que les harmoniques spheriques sont une base orthonormée des fonctions spheriques.  
 
Le deuxieme papier parle d'appliquer au prealable a la fonction de distribution de la lumiere, une autre fonction qui est celle de la conformation de la scene en ce point independamment de l'eclairage. Suivant le type d'effet que tu veux obtenir ce sera sous forme d'un vecteur ou d'une matrice qui symbolise pour chaque vertex ou chaque pixel, le chemin complexe que devra effectuer la lumiere pour participer a la valeur d'eclairement.  
Ce n'est ni plus ni moins que de l'eclairement global et si c'est bien fait, ca peut rendre compte de l'auto ombrage, des interreflexions (color bleeding) et de la BRDF du materiau.
Je ne sais pas si on peut encoder des materiaux emissifs sans un terme constant supplementaire.
 
Si tu encodes les coefficients de cette fonction de transfert dans une texture tu obtiens une lightmap puissance dix. Tu peux changer les conditions d'eclairage externe en un clin d'oeil.
Malheureusement le calcul de cette "lightmap" si elle est poussée est assez couteuse et ne peut generalement pas etre fait en temps reel. Difficile dans ce cas de prevoir des parties mobiles dans une scene.  
 
Je ne sais pas si tu te souviens de l'horizon mapping? ca va dans le meme sens mais en poussant encore plus loin.
 
LeGreg

Oh foules dechainees.
 
LeGreg

topic elitiste reservé a ceux qui aiment se prendre la tete avec 3 triangles
 
Par acces aleatoire au vb, j'entendais pouvoir acceder non plus a un vertex apres l'autre mais par ex pour un vtx pouvoir acceder aux deux autres vtx du triangle (par exemple)
 
Sinon gros truc a la con, genre pinaillage : pouvoir specifier un index buffer par stream (pour retomber sur un truc a la 3dsmax, c quand meme pratique)
 
 
Thks pour tes explications sur l'eclairage, je m'amuserais bien a ca mais c pas moi qui suit en charge de l'eclairage dans le moteur actuel et en ce moment je fais dans la generation d'arbre, on peut pas etre au four et au moulin...

 
Ce n'est pas l'interet des indices ?
 

 
Pour par exemple faire la distinction entre un vertex qui partage une coordonnée mais avec une normale differente ?
Ca pourrait surement etre tenté, oui.  
 

 
Je ne m'occupe pas non plus de l'éclairage mais j'essaie de me maintenir informé.
En bonus, si tu ne l'as pas encore vu il y a un type qui a ecrit une demo avec source code :
http://www.itstudents.ch/users/dave/files/SHTest.exe  
 
LeGreg

oulà ça deviens violent ici
 
bah, le seul truc que je verrais dans l'immédiat (avoir une vision sur le long terme est impossible à mon avis), ça déja été dit par chrisbk, mais ce serait d'avoir la possibilité de créer des vertexs et des triangles à partir d'un vertex shader...
en ayant parcouru rapidement ce qui se fait actuellement, je trouves que ce serai l'évolution la plus censée dans l'immédiat.
 
par contre d'un point de vue hardware, je vois mal les fabricants de hardware s'orienter vers une seule et unique direction, la meilleure solution, qui serait universelle, pour eux serait de faire comme 3dlabs, un asic avec X unitées "simple", une architecture où on a plus d'unitées bloqués pour les shaders au niveau vertex ou pixel, mais le pilote qui distribue les unitées dynamiquement pour chaque besoin....
ce qui permetterai d'avoir tout les transistors d'occupés... (et non pas avoir par exemple les transitors des pipelines à pixels/fragments qui glandent pendant que ceux des vertexs bossent, ou inversement etc etc....)
De plus une telle architecture permetterai de sauter à un autre système de rendu (raytraçing...) plus facilement...

 
Traiter l'acces au vertex buffer comme un dependant texture read ? Si ce n'est pas encore possible ca le sera dans la prochaine generation de carte si c'est ce que tu veux dire ?
Quoique les texture coordinates homogenes ca va nous plomber, je me demande..
 

 
Personnellement, tant que je dois faire du temps réel je m'eloignerai autant que possible des choix de 3DSMax..
 

 
Si c'est beaucoup d'exterieurs, avec les image based lighting on doit pouvoir faire des trucs pas mal. J'attends toujours de voir une demo impressionnante qui n'implique pas qu'une cubemap et trois spheres qui tournent. (peut-etre ton programme )
 
La solution des spherical harmonics peut etre aussi pas mal, j'ai qu'un seul probleme avec ces choses la pour l'instant: on ne peut pas traiter les lumieres hautes frequences de la meme facon et puis il y a le fameux ringing effect.. De plus je cherche encore le papier qui bouleversera leur application (ou une technique avec des resultats similaire) sur des personnages skinnés des pieds à la tete avec des niveaux de détails auxquels on est habitué. -> retour aux lightmaps statiques meme si on n'en étais pas vraiment sorti..
 
LeGreg
 
 

 
C'est deja possible en theorie meme si ce ne serait pas un vertex shader mais un pixel shader.
 
Imagine que tu aies acces a l'interface bas niveau de la carte: tu crees une rendertarget linéaire dans un format float32. tu ecris un pixel shader qui ecrit la dedans mais a la place d'etre des informations de couleur ce sont des infos de position, de normales, de texture coordinates. Ensuite par la magie du fait que ta memoire video n'est pas vraiment différente si tu as une texture, un vertex buffer ou un shader, tu métamorphose ça par un coup de baguette magique en vertex buffer. Et voila..
 
Bon ca c'est la theorie.. En pratique il y a encore du chemin a parcourir pour que ce soit exposé correctement au programmeur.
 

 
Pour revenir a ce probleme d'exposer le hardware comme des unites de calcul parallele generaliste.
Non pas que l'idée ne soit pas séduisante.
 
Prenons l'exemple con du TNL hardware.
Sur Geforce Fx, le TNL fixe est présent (celui qui fait des calculs d'eclairage par vertex, plus des conneries comme le tweening, le vertex fog ou les transform de texture coordinates), dans le cas le pire (8 lumieres actives), celui-ci bat a plate couture le meilleur moteur de vertex shaders..
Cela n'est pas tres surprenant, on peut tirer avantage du parallelisme dans 8 calculs de lighting intégré dans le hardware. Pour une unité de calcul généraliste c'est un peu plus dur.
De plus les programmeurs crient victoire parce qu'ils ont l'impression qu'on leur simplifie la tache.. Pourtant quand ils auront n nouveaux processeurs a programmer en tenant compte de la synchronisation et de l'equilibrage des taches dans le chip.. C'est deja un peu le cas sauf que le modele est simple et lineaire. Evidemment ils pourront utiliser la "vieille" interface et laisser les developpeurs du driver faire le sale boulot a leur place. Ou ils seront convaincus de pouvoir faire mieux et..
 
LeGreg
 
 
 

 
oui j'avais vu ça aussi, à priori ça marche en CG.
 
par contre pour la geforce fx, je savais que les fontions T&L fixes étaient pas émulées par le moteur VS, t'as lien un vers la courbe de performances géométrique vs nombre de lumières ?

Je connais un site ca s'appelle hardware.fr
et ils testent des cartes graphiques:

 
LeGreg

pour ton point 4, macos x le fait déjà

Ma seule contribution à ce topic, parceque j'y connais rien, est l'uniformisation à venir entre DirecX et OpenGL. En effet, M$ et la société qui gèrent l'OpenGL ont décidés en partenariat de rapprocher ces deux standard qui sont à 90% équivalent, que ce soit au niveau de la vitesse, des instructions et de la qualité du rendu, afin de faire une version commune, donc DX9 est une première étape (du moins, il était prévu comme tel) et DX10 devrait être la première version de cette uniformisation. A partir de là, deux choses à prendre en compte :
- Point de vue politique, il y a fort à risquer que les inovations soient plus lentes, chacune des deux (ou plus ?) sociétés désirant imposer ses inovations, et garder tous les lauriers. L'inovation risque donc d'être ralenties, par contre, la qualités des inovations sera certainement mailleure, étant donné que pour que chaque partie approuve, ce sera forcément une chose vraiment utile.
- Point de vue portabilité, on devrait voir débarquer sur les plateformes actuellement uniquement réservées à OpenGL (Linux, Mac) un nouveau framework qui permettra d'utiliser cette nouvelle norme. Le portage des applications d'un système à l'autre sera donc plus aisé, puisqu'on n'aura plus à modifier en profondeur le moteur 3D, ou se restreindre à l'OpenGL, qui reste souvent moins bien géré sous Windows que DX, même si aujourd'hui la différence est quasi-inexistante, et même les efforts plus poussée sur la version OpenGL permettant d'obtenir de meilleures perfs avec l'OpenGL. Cette inovation est par la même occasion une porte ouverte à la 3D sur les sites web, qui est aujourd'hui quasi-inexistante, puisque limitée à des objets propriétaires et fermés (bien plus que DX, qui dispose au moins d'un SDK) rarement performants.
 
Donc en tout cas, pour ce qui est de l'évolution des cartes graphiques, disposant d'ici peu d'une interface unique, on peut espérer que la porte soit ouverte à des fonctionnalités bien plus évoluées que maintenant, le souci de compatibilité avec deux interfaces étant révolu.

J'ai dwl remplacé les DLL du runtime de VC++ par celles de la version .NET et j'ai voulu compiler.
 
Il me manque les fichiers contenus dans sdha ou chais pas quoi. Des includes. Du coup ça compile pas

 
Le source compile pas, il est la a titre d'info
c'est l'executable qu'il faut lancer !
 
LeGreg

http://graphics.stanford.edu/papers/allfreq/

j'ai pas vu d'exe ???

Comment vous faites pour etre autant informé sur tout ça?
Le monde de la 3D temps réel m'intéresse vraiment, donc j'essaye de me tenir informé le plus possible mais je ne comprends meme pas la moitié des expressions techniques que vous employez?!
 
Vous utilisez principalement internet comme source d'infos (et si oui, vous allez sur quels sites en général??) ou vous avez d'autres sources (genre livres, magazines...)??
 
Merci

 
heu....
 
http://www.hardware.fr/articles/462/page7.html
 

 
Le test T&L 8 lumières  est fait sous 3DMark 2001 (Mtri/s)
Le test vertex shader est fait avec 3DMark 2003 (fps)
 
le contexte n'est pas le même, et tu compares des choux avec des patates.
 
pour comparer correctement, il faudrait prendre les mêmes ressources géométriques, et les faire exécuter avec un FVF fixe, puis un vertex shader équivalent (voir dans la même appli).
 
mais là y'a trop de paramètres qui changent:
 
dans 3dmark2001 y'a pas de textures, alors que dans 3dmark2003 c'est le test avec les trolls skinnés.
 
----
 
vu la masse de transistor que prendrait une unitée T&L fixe, et vu l'orientation prise par le matériel, il est plus que hautement probable que toutes les fonctions T&L fixes soient émulées par VS sur les radeon 9700/9800 et geforce fx (voir aussi gf3+/radeon 8500+)

 
En l'occurrence le choux c'est la Fx et les patates c'est la Radeon. Ce n'est certes pas totalement identique
mais la différence (2x) de perfs s'explique par ce que j'ai dit.. Mais la discussion devient Hors Sujet la..
 

 
Je me cite moi meme sur un autre forum:
 

 
 
Je ne compte pas rentrer dans les méandres de l'architecture mais c'est ce qui est à retenir.
 
LeGreg

Wishlist du futur par rapport au HDR evoque dans un autre topic (raytracing):
 
- La possibilité d'avoir des back/front buffer en flottant par canal.
- d'ou la necessité d'avoir la fonction de tone mapping intégrée en "free" dans le DAC . Ce qui (spéculons) permettrait d'accomoder les nouveaux ecrans plasma à affichage hautement dynamique.
 
Le fait d'avoir une fonction de tone mapping "gratuite" n'est pas si tirée par les cheveux puisqu'on sait que la fonction de brouillard est le plus souvent cablé et gratuite à activer (au cout de sa flexibilité mais on ne peut pas tout avoir).
 
De plus avoir le tone mapping intégré et gratuit permettrait de mettre au point également des solutions d'anti-aliasing plus intelligentes sur les rendus HDR.
 
(up déguisé ?)
 
LeGreg

Les precomputed radiance transfer (PRT pour les intimes)
utilisant les Spherical Harmonics comme vecteur (SH pour les amis proches) font désormais partie du SDK de Dx9.0. (qui en est à la Release candidate zero).
 
Je ne sais pas si j'ai le droit d'en parler mais je n'ai pas signé de NDA non plus.
 
LeGreg

Mon reve du moment : arreter de se prendre la tete avec les VB switch

Le futur a moyen terme c'est le raytracing temps réel !
 
PS : regardez les exemples ici : http://www.openrt.de/

En fait ce qui nous tue c'est le support du legacy
en 3D il faut faire tourner bien les applications d'il y a  
cinq ans et les benchmarks d'il y a 10 ans.
 
Les communications CPU/GPU sont une part importante de la performance d'une carte graphique dans un jeu moderne
et elles n'ont pas tendance à diminuer en proportion du temps passé à tracer une scène. Et pour radicalement se débarasser de ce surcout il faut penser l'API autrement (se débarasser des modes immédiats).
 
Microsoft avait essayé de s'écarter d'OpenGL en proposant une API retained mais elle avait été boudée par les développeurs.
 
Faire une API retained au dessus d'une couche immediate en software ça n'apportera aucun gain (ce qui avait été la solution choisie par Microsoft meme si le mode immédiat était vraiment succinct), il faut que le plus de choses soient déférées au driver mais pour ça il faudrait que Microsoft lache du lest et que OpenGL jarte totalement tel qu'il a été designé il y a 20 ans.
 
On est arrivé à un point où les cartes graphiques sont des monstres qui tracent 8 pixels par tour d'horloge et sont ultra parallélisable et où paradoxalement le software veut controle le nombre de frames qui sont stockés dans le pipeline en verrouillant le framebuffer.
 
LeGreg

 
genre ?

De toute façon, dans 4-5 ans, les raytracer software seront capable de produire des scènes de la même qualité que le top du top de maintenant. Un gros avantage du raytrace est que la complexité de celui-ci augmente en O(ln(n)) ou n est le nombre de polys alors que les systèmes actuels on plutot une complexité en O(n). Cela permet au raytracer de faire exploser le nombre de polys par rapport a un rendu classique sans avoir à developper des technos couteuses de LOD dynamique des modèles 3D.
 
Une petite page d'exemples : http://www.openrt.de/Gallery/index.html
 
Imaginez donc ce que cela pourra donner avec du hardware dédié.

 
Je n'ai pas de solution toute faite, je fais juste que constater certaines choses.
 
Le couple API/Hardware actuel est bon pour plusieurs choses:
1- tu paies le meme cout en mémoire pour tracer 1000 cubes a differentes positions que 1 cube.  
2- ce que tu dessines a la frame 2 peut n'avoir rien à voir avec ce que tu dessines a la frame 1.
3- il y a quelques situations ou tout le hardware (CPU/GPU) est utilisé à son optimum et est imbattable par rapport à une autre approche. Ces situations ne sont généralement pas des jeux.
 
Dans une scene de ville complexe (HL2 pour ne pas le citer), tu vas faire des milliers d'appels a draw primitives avec entre deux appels des tonnes de changements de renderstates de textures, des chargements de constantes, des effacements, des blits, des changements de rendertargets etc..
Bouh c'est beaucoup de travail...
Heureusement a la frame 2 tu dois afficher exactement la meme scene... ou malheureusement parce que tu vas devoir faire exactement le meme nombre d'appels à l'API pour rendre la frame 2.
 
C'est ce que j'appelle le modele pousseur de triangles. Les developpeurs qui ne font confiance a personne d'autre qu'eux pour optimiser leur jeu veulent pousser leurs triangles eux meme un a un. Triangle numero 1 texture avec lumière speculaire. Triangle numero 2 semi transparent (trié au préalable) avec une reflection bumpmappée. Triangle trois, une ombre. Quatre je nettoie une partie de l'écran pour pouvoir pousser les triangles du HUD. C'est ça le mode immédiat.
 
Et il faudrait quoi pour remplacer?
 
Les display lists ?
Aucun intéret si ce n'est qu'une interface déguisée pour pousser les memes triangles dans le driver. La flexibilité en moins.
Tu ne peux pas concilier dans une API un mode qui dit
begin triangle, sommet 1 sommet 2 sommet 3, end triangle
et un autre mode qui se veut haute performance.
 
Tu ne peux pas concilier une description de scene efficace avec des backdoors qui permettent de blitter quelque chose dans le DepthBuffer.
 
Actuellement l'API directX 9 expose une capacité qui permet aux développeurs de faire de l'occlusion query par objet ou par groupe d'objets. Mais qui pourrait faire mieux l'occlusion query que le hardware lui meme quand se posent les problemes de parallélisme ? Cela semble une bonne idée, utiliser le hardware pour moins tracer. Mais cela fragmente le rendu. Pourquoi ne pas simplement donner une bounding box au hardware et qu'il se débrouille avec. S'il ne trace rien à l'écran et s'il a une bonne représentation interne de la profondeur ce sera optimal. Faire une requete asynchrone client/gpu c'est courir le risque d'affamer l'un qui doit décider de faire autre chose en attendant sa query, s'il ne l'attend pas activement.
 
Heureusement l'explosion exponentielle de la puissance compense ces états d'ame.
 
Ce que je raconte est très théorique, je sais très bien que ce genre de projet se heurte à la dure réalité des tests WHQL et du benchmark qui trace des rubans infinis.
 
LeGreg

 
ça j'y crois moins, une scène de 1 millions de triangles sera traitée une fois par frame dans la configuration actuelle, et une fois par fragment dans le cas d'un raytracer.
 
le coup hardware d'un raytracer est sans aucunes mesures avec le pipeline que l'on a actuellement, que ce soit actuellement ou dans 5 ans, l'ordre de coût sera le même.
 
donc faire du raytracing dans une démo technologique pour prouver la flexibilité du harware mis en démo, oui, mais du raytraçing temps réel, on a encore du temps...

 
je serais assez d'accord pour passer une bounding box au hardware pour tester à l'encontre du z-buffer si y'a visibilité ou pas....

 
Mais un raytracer ne teste pas le million de polygones à chaque rayon justement. L'avantage du fait que tu puisse ajouter autant de polys que tu veux, même de s'ils ont une taille infime est énorme. Le cout dépend plus de la surface de l'écran que du nombre de polys. En comparaison, avec les systèmes classique, 1 million de polys de taille entre 1 et 2 pixels au loin, ça fait une grosse chute de perfs.
 
Regarde un peu les video d'exemple. Oui il faut admettre que leur clusters de calculs sont pas à la portée de tout le monde. Mais ils arrivent quand même a avoir du 6-9fps sur une scène de 1000000000 de polys avec 48 CPU.

skoi le rapport avec la programmation?

 
sans optimisations si (surface courbes/boundingbox/bsp & co).
 
et si tu as des propriétées de réflextion/réfraction, c'est ton million de poly (ou autres) montée à une puissance.
 
de plus un accélérateur matériel purement raytracing aurait besoin de toute la "connaissance" de la scène.
 
avec le hardware actuel, tu actualise ton image étape par étape.
tu as donc aucune limites en nombre d'étapes.
 
alors qu'avec un raytracer hardware, il aurait besoin de tester toutes les ressources géométrique de ta scène...

 
porké si on fait pas un topic "c'est quoi le "Hello world" le plus correct en C", on pas le droit à causer ?

 
C'est quoi cette histoire de faire du raytrace sans optimisation ? Quelle idée aussi. Bien sur qu'il faut utiliser des bounding box et des BSP ( ou autres techno de remplacement ) !
 
Voici un document qui explique très bien les très nombreux avantages du raytracing sur les techniques actuelles de rasterisation : http://graphics.cs.uni-sb.de/Publi [...] racing.pdf
 
Il propose même une archi pour l'acceleration hardware

 
bah je dis pas que c'est impossible, mais 5-6 ans ça me parait bien trop optimiste... (je pense qu'il faudra doubler ou tripler ce temps, entre les premiers hardware et l'utilisation massive)
 
remarque j'ai déjà vu des stations avec du hardware pour le raytracing mais sais pas trop que ça vaux

C'est vrai que 4-5 ans est un délai un peu court pour voir apparaitre une toute nouvelle gamme de hardware au fonctionement complètement différent de ce qui se fait actuellement.
 
Mais au vu des examples donnés pas le site que j'ai indiqué, on peut considéré que ce résultat sera accessible en software avec du materiel abordable par le commun des mortels.
 
Les exemples avec 48 CPU ( soit 48 PC classiques si je ne me trompe pas ) pour 1000000000 de polys sont pas trop mal. Si on compte la fameuse loi de moore ça nous donne environ 8-9 ans pour avoir accès à ce genre de materiel. Mais le nombre de polys est quand même gigantesque. En divisant ça par 1000 on obtient quand même des scènes impressionantes et la puissance necessaire sera beaucoup moindre.

effectivement le pdf est très très interressant.....
 
par contre c'est vrai que la scène mise en BSP aide beaucoup de le bestiau, mais le prob, c'est qu'au niveau cpu faudra actuliser le BSP en fonction des objets dynamiques...
 
donc à titre intermédiaire on pourait ptet mixer un raytracer et un rasterizer, où le raytraçer s'occupe du monde statique en BSP, un z-buffer est toujours utilisé, et un rasterizer fait le traçage des objets hautement dynamique... (afin de ne pas être pénalisé par l'actualisation de l'arbre BSP)

d'un autre coté dans le PDF, ils indiquent que le BSP est généré automatiquement par le hardware, mais je doutes qu'ils le régénèrent à chaque frame