Temps de rendu

Bonjour,

J'ai dessiné une scène à l'aide d'OpenGL.
Lorsque ma camera est proche d'un mur, je constate que le temps de construction de l'image est plus long. Je suppose que c'est dû à la façon dont OpenGL dessine à l'écran.

Je trouve ça très gênant.

Avez vous déjà rencontré ce "problème" ? Mon rendu n'est-il pas optimisé ? Où puis-je trouver des renseignements à ce sujet ?

Merci.

-----------------

Le temps de construction de l'image est affiché dans le titre en miliseconde.

http://www.developpez.net/forums/att...1&d=1273312405

http://www.developpez.net/forums/att...1&d=1273312405

http://www.developpez.net/forums/att...1&d=1273312405

Le temps de construction de 18 milisecondes est sans doute lié à la synchronisation vertical.

Bonjour,

Malheureusement ceci est tout à fait normal. C'est juste que le rendu d'une "zone" de mur est plus couteux que le "ciel" dans l'appli.
Votre fps est quand meme pas bien élevé, utilisez-vous des shaders ?

Oui j'ai déjà rencontré ce problème de façon très violente : une scène s'affichant en 2/3 ms et à un endroit un objet rendu en ray-casting qui faisait localement chuté les perfs, pas grand chose à faire.

Bonjour,

Il a de nombreuses raisons pour une chute de FPS.

Déjà, il semble que vous ne faites pas une optimisation, en affichant que ce qui est utile ( ne pas afficher ce qui est derrière un mur, est un gain de temps. Mais ce n'est pas grave )

Êtes vous sur d'utiliser des textures ayant une tailles de puissance de 2 ?
Avec vous de grandes textures?

Sinon, il faut savoir que lorsque l'on s'approche des textures, un processus de mipmapping va s'enclencher ( plus grande qualité des textures, lorsque l'on est proche ). Cela ne devrait toute fois pas posé de problème.

Citation:

---

Envoyé par LittleWhite

Sinon, il faut savoir que lorsque l'on s'approche des textures, un processus de mipmapping va s'enclencher ( plus grande qualité des textures, lorsque l'on est proche ).

---

C'est plutot l'inverse.

Il y aura toujours des grosses variations dans le temps de rendu sauf si la charge est très prédictible comme dans un jeu où la caméra n'est pas libre (et un gros travail de design derrière ce qui n'est pas forcément accessible aux petits studios). Pour un FPS c'est quasi inévitable la première des choses est donc de s'assurer que le jeu reste jouable avec des variations importantes de temps de rendu (utiliser le temps écoulé réel pour faire les updates de la simulation).

Après il y a toujours des optimisations possibles mais il faut savoir que si ton jeu n'affiche que trois murs comme dans ton jeu, la marge pour optimiser est très limitée. (les jeux actuels ont des géométries très complexes, des centaines de milliers de polygones, des shaders très longs etc.).

La première chose à faire si tu as des problèmes de performance est d'identifier où le rendu passe le plus de temps (aussi appelé goulet d'étranglement où Bottleneck). La bible actuelle pour les goulets d'étranglements est le programming guide de Nvidia :
http://developer.nvidia.com/object/g...ing_guide.html
Certains conseils s'appliquent à tous les GPUs (CPU limited vs GPU limited) et d'autres s'appliquent à seulement certains GPUs (shader unifié) voire certains CPUs (moteur multithreadé).

Pour ton jeu, essaie de voir si tu peux éviter le rendu des objets cachés par exemple en rendant de l'avant vers l'arrière (toujours préférable même si certaines vieilles architectures ne peuvent pas toujours en tirer parti) ou en utilisant une détermination de visibilité du côté software (toujours bénéficiaire mais à des degrés très différents suivant la situation). Dans certains FPS par exemple, la visibilité est précalculée à la génération de niveau (liste de visibilité), d'autres la calculent au rendu mais avec des structures d'accélérations (bsp, portal, occluders, etc).
Déterminer la visibilité en avance au niveau software n'aide pas forcément au temps de calcul du pixel shader (si celui-ci bénéficie du rendu de l'avant vers l'arrière via un early zcull hierarchique) mais bénéficie à toute la chaine en amont qui est souvent non négligeable.

LeGreg

Citation:

---

Envoyé par TanEk

C'est plutot l'inverse.

---

Oups :red:

Sinon, comme le dit LeGreg, un petit frustrum Culling, cela n'a jamais fait de mal ( calculé coté CPU bien sur ).

Par contre, je pense qu'il y a un problème "logique" dans votre code. Car vous ne devriez pas avoir de hausse de ce genre, et surtout pas en s'approchant d'un mur...