Il est faux de dire qu’on peut remplacer le Z-buffer par un tri des polygones. Ca marcherait très partiellement. Pour dire qu’un polygone n’est pas visible du tout, il faut déjà en être certain, il ne suffit pas de dire qu’il est derrière, il peut être décalé à gauche par rapport à un autre polygone, il aura être plus loin que celui ci, il sera visible (mais des méthodes existent et sont utilisées, mais c’est surtout qu’un polygone dans le cas du rendu n’a qu’une face, alors déjà si le polygone est pas tourné du bon coté, c’est qu’à priori il est caché par les autres polygones du même objet). Ensuite il y a tous les polygones partiellements visibles, et ceux là, à part le Z-buffer, y’a pas vraiment de solution miracle (redécouper le polygone en fonction des polygones qui sont devant, ouhlala, bonjour les calculs).
Ensuite; je pense sincèrement que le glas de la bidouille commence à sonner, laissant place au gaspillage de ressources (oui parceque toutes ces bidouilles n’ont qu’un but, faire pas trop moche très très vite).
Java a le vent en poupe, .Net est à la fête. Tout cela suit la même logique (on essaye de faire propre, même si ça coute un peu de puissance)
La même sanction va probablement toucher dans le futur proche (5 ans disons) les applications graphiques grand public.
On nous sort des cartes avec de plus en plus de techniques bidouillées dans le seul but de s’approcher d’un rendu réaliste. Il arrive cependant un moment où le niveau de détail demandé remet en cause les anciennes bidouilles. Aujourd’hui un rétroviseur dans un jeu, c’est un “trou” dans l’affichage où la vue d’une caméra qui regarde derrière est déssiné, mais si on donner la sensation d’être bousculé dans la voiture, ça devient plus difficile à faire (une bidouille de plus). Le nombre de bidouilles à supporter devient au bout d’un moment tellement grand qu’il faut des processeurs très gros avec des conditions et des branchements logiques de partout.
Aujourd’hui on veut voir le grain de peau, des cheveux, des poils, des vetements froisés, des ombres réalistes, des réflexions, etc.
Bien sur on peut continuer à grossir les processeurs (méthode éprouvée par Intel jusqu’ici, vas-y que j’te rajoute du jeu d’instructions), ou alors on revient à du tout petit processeur qui ne sait faire que quelques opérations mais qui sait les faire super vite et à partir desquels on peut tout faire (les RISC). Un des avantages du raytracing, en plus, c’est que le calcul de chaque pixel est totalement indépendant, on peut donc faire tout en parallèle.
Comme je l’ai dit, pour faire du raytracing, basiquement, on a besoin principalement d’accélerer le calcul de l’intersection et de la normale de quelques surfaces bien connues (triangle, cercle, sphere, nurbs,…), et aussi de quelques fonctions sur le traitement des couleurs. Il me semble que cela suffit, non ? Le reste (que faire du résultat de l’intersection) étant du resort d’un autre processeur plus générique pour gérer le bumpmapping, faire des effets de lumières un peu zarbi pour donner du style, etc etc
Une autre partie de ce processeur à instructions réduites peut être consacré au calcul de caustiques, radiance, etc.
L’idée est très séduisante, mais que je sache les RISC n’ont toujours pas la belle vie dans le marché grand public pour les processeurs centraux… et je doute que cela arrive un jour pour les processeurs graphiques (à moins qu’un grand du marché s’y mette).
En revanche, je me refuse à pronostiquer le succes d’une telle puce dans le monde professionnel.