Pixel shaders, le retour de la vengeance du roi

Bon, suite à mes péripéties pixelshaderiennes de la dernière fois, et après enquête minutieuse de toutes les options qui m’étaient offertes, j’en suis arrivé à la conclusion suivante (qui fera plaisir à c0unt0) :

rendez moiiiiii ma ps2… bouhouhouhouhou Du coup, en te démerdant un peu, en grugeant 2/3 trucs par ci par la, tu arrives à récupérer le Z et à le balancer dans la couche alpha de ta render target qui va bien.

Sur PC, non. Rien de tout ça Ben franchement, ça calme. Je vois les pixelshaders 3.0 qui font des sincos/exp/log/sqrt/… au pixel, et même pas foutu de faire un lookup dans un ZBuffer pris comme texture

Bref, je déprime sévère la, je vais m’acheter une PS2, la patcher, et refaire le monde sur PS2 en 64ko Quand je vois ce genre de solution (qui est celle préconisée par tous les SDK/Docs/tutorials que j’ai pu trouver), ben je reste perplexe quant à l’utilité d’avoir mis des sinus et exponentiels au pixel, plutot que de faire des choses de base.

Pour info : utiliser l’information de profondeur permettrait de faire de nombreux effets spéciaux, tels que de la profondeur de champs en une passe (hors passes de blur), du fog transparent générique (tout ce qui est loin part joliment en transparence sur un background quelconque par exemple), du motion blur adaptatif ™©® dont l’importance varie avec le Z, et toute une kyrielle d’effets pas chers mais qui peuvent rapporter gros en terme de qualité d’image (testé et approuvé sur PS2).

Voili voila, c’était ma vie, mon oeuvre, par moi

Redige moi ta question comme il faut en anglais et j’essaye de faire suivre aux gens qui font directx… et pas de gros troll dedans gentil. Faut amadouer le bestiau.
Ce message a été édité par GloP le 13/11/2003

Tiens ca m’interresse aussi bien…

Ben le soucis c’est que je sais que pour DX8 et DX9, c’est semble-t-il bien mort Quoique pour DX9 c’est moins sur en fait mais bon.

Ma question serait donc :

« How could I get access to the depth buffer, either as a source texture or another input for a pixel shader, in order to retreive the depth values of a previously rendered scene? I can’t afford rendering the scene twice, and I don’t have any control over the rendering process of this scene. All I have is the depth buffer filled with information of the rendered scene, and color buffer containing the scene itself. »

Comme tu le vois, je parle mal anglais mais je pense qu’ils comprendront ET je ne troll pas, non mais !

Sinon j’ai déjà eu une confirmation d’ATI comme quoi ce n’est faisable qu’en faisant plusieurs rendus de la scène avec les pixelshaders 1.1, mais ils n’ont rien dis pour les PS2.0 par exemple.

Voili voila :wink:

Euh pourtant il me semble que les ZBuffer sont considérés comme des texture comme les autres non? il me semblait pourtant… faudrait que je mate mes bouquins, j’éditerais si je trouves

Non, en fait les Z buffers et autres sont gérés en tant que surfaces et non en tant que textures. Une texture est en fait une collection de surfaces de types spécifiques. Dont, bien entendu, les différents types de Z buffers ne font pas partie. Dommage.

A trop bosser sur des choses du genre console (sur lesquelles généralement tous les buffers sont accessibles quel que soit leur type), j’ai un peu oublié à quel point c’était le merdier sur PC

Cela dit, ça s’explique plutôt logiquement en fait : vu le nombre de hardware différents (dont certains sans “vrai” Z buffer, comme les Kyro, qui “fakaient” leur Z buffer vu qu’elles n’en avaient pas besoin), et vu la course aux performances (avec tout un tas de pixel pipelines), c’est sûr que isoler les buffers par type permet de faciliter grandement la vie des fabricants de hardware, des développeurs de drivers et des développeurs d’API

Et oui faut y faire

Sinon peut être que cette soluce marche a verifier:

Essai de mettre ton Z ds le vertex shader dans un registre de texture/color/…  qui sera ensuite disponible ds le pixel shader. Ensuite si ca passe le z-test c’est que tu peux sans risque l’utiliser
Bien entendu faut juste eviter l’overdraw pr ne pas trop en faire

Ce message a été édité par Nithril le 25/11/2003

Nithril>tu as l’air d’etre nouveau, pourrais tu eviter le SMS, c’est tres desagreable. Merci (et puis lit la FAQ aussi c’est tres utile )

Nithril, le soucis c’est que mon idée était justement d’éviter d’avoir à appliquer un traitement spécial aux objets que je rendais, l’idée étant d’appliquer un filtre uniquement en tant que passe finale. Ce n’est donc pas possible sur PC (quelle que soit la version des pixel shader d’ailleurs, je n’ai pas l’impression qu’en PS2.0 on puisse davantage qu’en PS1.x). Tant pis, ça fait davantage de boulot pour tout le monde (le codeur et la carte 3D).

Cela dit, j’ai implémenté (vive les anglicismes !) une profondeur de champs en utilisant cette technique du double rendu de la scène, et ça rends plutôt joli. Dommage que ça pompe autant de ressources quand même, je me vois difficilement faire ça dans le cadre d’un jeu (ce serait faisable mais… faudrait convaincre le chef de projet que le temps passé dessus apporte vraiment un plus )

Et je suppose que faire une copie hard du zbuffer ds une texture c pas possible?

Bien sur que non, les depth surfaces sont un cas particulier de partout, il suffit de regarder la documentation de DX9 :

[quote]Depth and stencil surfaces can be copied using IDirect3DDevice9::StretchRect with the following restrictions.

  • Both the source and destination surfaces must be created with IDirect3DDevice9::CreateDepthStencilSurface, because they must be plain depth stencil surfaces (not textures).
  • Both surfaces must be the same format (no format conversion).
  • No stretching or shrinking is allowed.
  • Subrectangle copies are not allowed. The entire surface must be copied. In other words, pSourceRect and pDestRect must be NULL, or point to rectangles that cover the whole surface.
  • StretchRect cannot be called inside of IDirect3DDevice9::BeginScene/IDirect3DDevice9::EndScene pairs.
  • The source or destination surface can't be a mip level of a texture (cube texture) created with D3DUSAGE_DEPTHSTENCIL.
  • Neither of the surfaces can be created as "discardable."
  • Drivers must set D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES. See [b]D3DDEVCAPS2[/b].
Voili voila, c'est donc le pire des cas, avec le plus de restrictions possibles, et en fin de compte l'utilité me semble quelque peu... limitée [img]style_emoticons/<#EMO_DIR#>/smile.gif[/img] A part pour faire du "backup" de Z buffer à la limite... Bref, c'est le merdier j'vous dis [img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]

[quote]
Voili voila, c’est donc le pire des cas, avec le plus de restrictions possibles, et en fin de compte l’utilité me semble quelque peu… limitée
Vu que faire une copie, certe impossible a réaliser, repondrait totalement a tes attentes.

Remarque tu peux toujours essayer d’acceder à la vram à la mano

De toute facon maintenant le zbuffer ne doit plus ressembler à rien avec l’utilisation des HOM

Mais si je suis cohérent avec moi même : copier un Z buffer dans un autre Z buffer me semble à la limite extreme de l’utilité, vu que moi c’est copier un Z buffer dans une TEXTURE que je voudrais. CQFD

Autant pr moi, je croyais que tu parlais de ma proposition d’une copie de zbuffer à texture