Reprise du message précédent :
ok ok, de toute façon on s'éloigne beaucoup du sujet principal ;-).
 
bjone> comment ça se passe quand tu programmes le displacement mapping en DirectX9 avec une carte ATI ? quand tu récupères les capacités de la carte le support displacement mapping est réellement absent sur les drivers récents ? et du coup des démos de displacement mapping qui fonctionnaient sur les anciens drivers ne fonctionneraient plus ? c curieux, je ne vois pas quel est l'intérêt d'avoir virer la fonctionnalité... peut-être dans un souci d'optimisation du driver, je trouve ça con quand même.

 
 
en effet et ca continue  

 
émulable, sans trop de pertes, t'as qu'à le dire aux mecs qui jouaient à CS sur 9700/9500 et qui ralentissaient parce que le truform était activé. (et vu la charge géométrique du premier CS hum hum l'émulation sans pertes)
 
y'a pu de TruForm... c'est mort comme l'EMBM on ira vers une approche plus universelle.
 
quand au SM3.0 il y a le Geometry Instancing qui lui devrait pouvoir rapidement faire ses preuves (car ça réponds à une problématique de rendement bien précise), et autre caps interressante sur les gf6 le blending fp16 bits pour le HDR qui tends à devenir le standard pour les moteurs à venir. (moteur Unreal 3, Stalker aussi je crois avec le deferred rendering).
 
bref c'est pas ici qu'on en cause c'est sur le GOB.

 
sur les 9700+ le Truform n'a jamais existé au niveau hardware (je sais j'ai été surpris quand je l'ai appris aussi), mais était émulé par le driver, cf les perfs qui baissaient dans CS quand on oublie le TruForm. plus personne ne l'utilise et ne l'utilisera jamais, c'est comme l'EMBM introduit par la G400, a mieux et plus souple avec les pixelshaders.
 
et le TruForm doit être une sacrée merde à émuler au niveau CPU car je pense qu'il faut à partir d'un VertexBuffer/IndexBuffer donné par l'app, tesseller à la main et dynamiquement par rapport à un lod lié à la distance ces deux buffers primaires dans des sous VB/IB. ce qui rend le rendu certainement limité par le CPU tôt au tard. (et vu qu'en général un GPU consomme plus de géométrie qu'un CPU peut produire à la volée, ça glande)

c'est bien les shader et les emulation mais içi on parle de quoi au juste ?

bjone> de toute façon le truform en lui-même est un "bonus" permettant globalement d'arrondir les formes et au final l'algorithme qui consiste à ajouter dynamiquement des polygones en fonction de la forme globale doit-être assez compliqué, cela ne m'étonnes pas que ce soit le CPU qui s'en chargeait car au final de son côté le GPU devait traiter plus de vertex et donc on avait une espèce d'équilibrage des charges supplémentaires. Par contre le Displacement mapping, je ne pense pas que ce n'était pas du software, sinon quel en serait l'intérêt ? il s'agit quand même de lire une texture pour transformer les coordonnées u,v en x,y,z. Appliquer des transformations (matrices) sur des textures à mon avis le GPU savait faire... ensuite il fallait récupérer et traiter le résultat comme un vertex buffer, c juste un travail du driver je pense...
 
C assez logique que le truform soit couteux puisqu'il s'agit d'un agit drastique de polygones avec en plus un algorithme assez complexe qui tourne en soft derrière...  
 
 
Enfin bref qu'est-ce qu'on dérive ! c une belle pollution de topic...

le vrai displacement (création de géométrie avec un système de lod dynamique comme doit le fait le parhelia) est plus complexe que le truform. (à mon avis)