Discussion :

[supergrey]

Bonjour, je souhaiterais rendre une scene 3d en plusieurs fois pour permetre un traitement plus fréquent entre les moment de rendu. Par exemple rendre par ligne (ou colone) d'un certain nombre de pixels de large (ou de haut).

Donc je sais rendre des parties de l'écran en utilisant les viewports mais que la caméra soit bonne je ne vois que des méthodes "Mc Gyver".
Quelqu'un aurait il une idée plus précise ?
Merci

[LeGreg]

hmm.. Ce n'est pas forcément très clair ce que tu veux faire (quels traitements plus fréquents ? tu essaies de résoudre un problème de frame rate ?), on va essayer de deviner donc

bon imaginons que tu veuilles rendre une image de 1600x1200 en quatre fois.

Première solution :
- ta rendertarget et ton backbuffer est déjà de taille 1600x1200. Dans ce cas pas de problème, tu règles ton viewport de manière normale, tu laisses tes matrices inchangées. Par contre tu utilises ce qu'on appelle le "Scissor rect", c'est à dire tu constrains le rendu à une portion de l'image disons [0,400]x[0,1200] ou [100,200]x[600x800]. Regardes la documentation de IDirect3DDevice9::SetScissorRect(). Problème : si tu traces directement dans le back buffer, à chaque fois que tu fais present (c'est ce que tu veux faire, j'ai compris non ?), tu vas perdre la frame précédente (double buffering/discard), en tout cas ce n'est pas conseillé pour la compatibilité (tourne en mode debug du sdk pour vérifier que tu traces tout correctement). Donc si tu ne mets à jour qu'un quart de ton back buffer par frame, il faut passer par une texture rendertarget (RTT) supplémentaire, qui va garder le contenu de ta frame (en 1600x1200) et appeler Stretchrect() pour faire la copie dans le backbuffer à chaque frame. StretchRect() a un coût, mais j'imagine que si tu t'embetes à faire ça, c'est que ton rendu est plus coûteux encore. Tu peux aussi spécifier un mode de Present() alternatif, recherche la doc à D3DSWAPEFFECT_COPY, ce qui revient à ce que le driver fasse la copie dans le front buffer à la fin du rendu et donc conserve d'une frame à l'autre le contenu de ton back buffer. Le rendu dans une texture est plus flexible et te permet par exemple d'afficher des éléments fixes et variables par frames (mouse cursor, GUI, etc.) en les rendant dans le backbuffer après que tu aies fait la copie manuelle via stretchrect(). Il permet également d'autres choses (vsync + triple buffering) mais ça devient un peu technique .
- si tu veux travailler dans un back buffer ou rendertarget de taille réduite disons 400x1200 et modifier le viewport/matrice pour que ça rende une partie différente de la scène à chaque fois, tu peux. Si par exemple ton vertex shader a pour output de position X,Y,Z,W en mode normal. La position normale du vertex sur l'écran sera X/w, Y/W. Lorsque X/W = -1 tu es sur le bord gauche de ton viewport original, X/W = 1 tu es sur le bord droit. Si tu veux que le vertex qui était au quart de l'écran (X/W = -0.5) devienne le bord gauche de ton viewport réduit et le vertex qui était au centre (X/W = 0) devienne le bord droit de ton nouveau viewport réduit, il faut que tu appliques une transformation supplémentaire à tes coordonnées originale. C'est une résolution d'équations du premier degré qui te donne donc W'=W (pour ne pas affecter Z/W, c'est à dire la distance qui sert au clipping et au stockage dans ton ZBuffer, tu peux aussi multiplier toutes les coordonnées par une constante non nulle comme c'est un espace homogène cela n'aura aucun effet), X'=4*X + W (vérification : si X/W = -0.5 alors X'/W'=4 * -0.5 + 1 = -1, si X/W = 0 alors X'/W'= 4 * 0 + 1 = 1). Tu procèdes de même pour Y.

Note : si tu cherches à économiser du temps de rendu, ta division de rendu en viewport de taille réduite ne sera beaucoup plus performante que si ton rendu original était limité par le temps de calcul dans le pixel shader et par le fillrate. Si tu avais une limitation par le processeur ou par le calcul par vertices/triangles (transform/setup/clipping/attributes etc) alors le gain ne sera effectif qu'avec des modes de culling agressif de ta part, et même là le gain effectif sera probablement sous-linéaire. À toi de faire du profiling de ton application pour voir où est vraiment ton goulet d'étranglement.

LeGreg

[supergrey]

Merci pour ces explications, en fait je fais une sorte d'application de dessin et ce que j'aimerais c'est que soit rendu fréquemment juste l'endroit ou l'on dessinne, soit par exemple un carré de 100 pixel sur 100, je pense que le gain serait très important car la baisse vu que mon appli peut couvrir tout l'écran soit par exemple 1280x1024 ou plus, et que le nombre de polygones n'est pas très grands.
Donc le but c'est que la partie "framemove" soit exécuté très souvent, même si la frame rate n'est pas très très lente.

Pour la solution avec les viewports, je n'ai pas trop compris l'explication, pour moi comme ma caméra a un ouverture de pi/4 (par exemple) si je veux rendre en 3 colones, je dois caler mon ouverture à pi/12 et pour chaque colone tourner la caméra de pi/12 (en supposant un rapport 1/1). Le problème dans ce cas c'est que le plan de clipping va être plus ou moins arondi et ça pourrait me poser des problèmes car je fais des calculs à ce niveau.

Sinon pour SetScissorRect ça pourrait être pas mal. Si je n'efface que le zbuffer est-ce que ça effacera quand même la frame précédente ?
Par contre mon compilateur me dit "identificateur introuvable" il est bien dans d3d9.h ?