Discussion :

[typedef]

Bonjour,

Je développe actuellement un petit moteur 3D. Je me suis fixé comme objectifs d’implémenter un moteur relativement simple, mais reprenant les bon concepts tout un essayant de rendre la chose performante et supportant OpenGL et OpenglES 2.
Je me pose donc quelques questions sur l'archi interne des moteurs, notamment sur le point du sorting des objets Renderable.

pour simplifier les choses, voila ou j'en suis arrivé :

Phase 0 : * Chaque Renderable calcul sa matrice monde si nécessaire pendant la phase d update des SceneNode et de
Scene Culling, ainsi que sa distance par rapport a la camera.

Phase 1 : * Pour les Renderable qui sont DepthTesté et qui n ont pas de Blend :
- Un system hierarchic de Material, avec donc un rootMaterial, est rendu.
- Chaque Material possède une liste de Renderable (sorte de RenderQueue non trié), et une liste de RenderTechnique.
- Chaque Renderable est ensuite rendu par la RenderTechnique qui correspond a sa distance par rapport a la camera.
- Les RenderTechnique possède des RenderPass pour le rendu nécessitant plusieurs draw call du Renderable.

Phase 2-A :
* Pour les Renderable qui ne sont pas DepthTesté et qui sont opaque :
- Ils sont push dans une RenderQueue qui est trié en fonction de leur distance par rapport a la camera, si celle ci s est
déplacé. Puis ils sont rendu après la Phase 1.

Phase 2-B :
* Pour les Renderable qui ont du Blend
- Idem, ils sont push dans une seconde RenderQueue qui est aussi trié si la camera s est déplacé, et rendu après
la Phase 2-A.

Suite a cela je me pose donc plusieurs questions,

1/ State sorting ou Depth sorting, il faut choisir car l'ordre des Renderable résultant est forcement conflictuel entre les deux type de tri. Est ce que mon approche de mixe des deux selon si le DepthTest et le Blending est activé ou pas est la bonne ? Y a t il des approches plus performantes / adapté..

2/ Dans la phase 1, je n'ai pas de RenderQueue centrale, et chaque material parcours sa propre RenderQueue, puis rend ses Material enfants qui font de même. Est-ce mieux de Centraliser la RenderQueue des Material d'une manière ou d'une autre, afin d'éviter de traverser l'arbre des Materials ? ( Je sais qu'en terme de parcours seulement ça serait plus rapide d’itérer sur un vector centralisé, mais cela implique de créer ce vector et de le trier comme il faut lorsqu'on rajoute un Renderable a la scène).

3/ Dans la phase 1 il n'est pas pratique de gérer des PreRenderPass et PostRenderPass sur l'ensemble des Renderable. C'est possible d'en avoir dans les RenderTechnique, mais les Pre/PostRenderPass seront faite par Type de Material et non sur l'ensemble. Cela peut il être problématique plus tard ? (la question 2/ permettrait de résoudre ce problème simplement je pense, mais est ce que ça vaut vraiment le coup ?)

4/ Dans la Phase 1, les Renderable ne sont donc pas trié par Distance, cela implique des LoadMatrix potentiellement très diffèrent d'un Renderable a l'autre. Par exemple un Material peu avoir trois Renderable A,B,C dans cette ordre de rendu, avec A et C proche de la camera, et B a l'autre bout du monde. Est ce un problème pour Opengl ou pas ? (sachant que c'est bien moi qui calcul les matrices de chaque Renderable et les load toute calculé a OpenGL)



j'espère que tout ça est a peu près compréhensible,
merci d'avance pour vos réponses,

[LeGreg]

Le state sorting est le plus important pour le coût CPU. Mais jusqu'à un certain point où il y a trop d'artefacts bien entendu.

Est-ce qu'il est possible de retravailler les maths pour limiter le changement d'état des particules par exemple si tu rends avec pixel color = src color + (1-alpha) * dest color. Tu peux combiner le cas (alpha) * src color + (1-alpha) * dst color (tu fais le calcul alpha * src color dans le pixel shader à la place) et le cas src color + dest color (tu rends avec alpha = 1 dans le pixel shader).

Pour les matériaux depth testés, il y a deux effets en concurrence, le premier est qu'il est préférable de rendre de l'avant vers l'arrière (afin de bénéficier du pixel culling voire hierarchical culling) et le deuxième est que le coût CPU risque d'être dominé par les changements d'état. Là encore il faut trouver une balance, trier par distance mais pas à une granularité suffisante pour séparer des contenus à matériaux communs. Et voir à unifier les matériaux si possible (uber shader, geometry instancing, données matériaux dans des arrays de textures etc.).

LeGreg

[typedef]

Merci pour ta réponse,

je ne vois pas quels artefacts on peut avoir pour des objets DepthTesté et non Blend ?

Pour l'alpha, si j'ai bien compris c'est un peu comme le principe de l'uber shader dans le sens ou le shader traite plusieurs cas en fait. C'est effectivement intéressant, je ne connaissais pas le principe.

par contre quand tu dis :

trier par distance mais pas à une granularité suffisante pour séparer des contenus à matériaux communs

c'est pas franchement évident, par exemple :


imaginons que mes cubes aient deux matériaux possible, ici rouge et bleu, si je n'ai aucune idée de leur répartition dans la scène, je ne vois vraiment pas comment tester par distance sans séparer les objets a matériau de même type.

A la limite, si j'ai une RenderQueue centrale pour les objets DepthTesté et non Blendé, je pourrais trier en distance par zone grise (ou par zone du quadtree de culling plus généralement), puis dans chaque zone faire le rendu en groupant par matériau commun.

Mais ca me semble relativement lourd en cpu car il faut trier les objets de ma RenderQueue centrale par zone a chaque frame, et dans ce cas d'exemple les changements de states vont quand même être fréquents, au moins un par case, alors qu'avec du state sorting complet on évite le tri sur tous les objets DepthTesté+nonBlend (donc la majorité tout de même) et on a plus que un chagement de state par materiaux, donc 2 dans ce cas.

Bon bien-sure c'est un cas ou on a pas pu unifier les deux matériaux, ça n'arrive peut être pas si souvent au final ?

Il faudrait que j'arrive a déterminer si dessiner de l'avant vers l'arrière (et donc trier, même partiellement) apporte plus de gain que éviter le tri et rendre avec le minimum de changements de states. Je vais essayer de voir lequel est le plus significatif.

[LeGreg]

je ne vois pas quels artefacts on peut avoir pour des objets DepthTesté et non Blend ?

Artefacts pour la semi transparence bien entendu. Pour les objets opaques ce que tu risques c'est une mauvaise performance si tu traces les objets les plus lointains d'abord (pixel shader qui tourne inutilement).

imaginons que mes cubes aient deux matériaux possible, ici rouge et bleu, si je n'ai aucune idée de leur répartition dans la scène, je ne vois vraiment pas comment tester par distance sans séparer les objets a matériau de même type.

Tu le fais bien pour tes matériaux semi transparents, je ne vois pas en quoi c'est impossible de trier par distance.

Par contre ce qui est évident c'est que tes cubes sont de mauvais occludeurs et donc les trier n'a que peu d'intérêt.
Si tu as de grands batiments, des murs pour des pièces fermées, des objets qui prennent une grosse partie de l'écran etc.
Et comme dit précédemment, il peut être intéressant de trier :
- grands occludeurs d'autant s'ils sont peu nombreux et/ou si leur ordre ne change pas trop par frame.
- moins bons occludeurs ne sont pas si intéressant à trier exhaustivement (par distance) mais peuvent être tracés en ordre approximatif, par exemple en divisant les queues en zones qui peuvent se superposer. Et faire un tri par matériel (via material id ?) par zone.

L'idéal étant bien entendu de prendre une scène réelle et de pouvoir évaluer si chaque décision a un sens en terme de performance réelle sur un grand nombre de hardware différents (où chaque bottleneck est différent).

LeGreg

[typedef]

Pour les objets opaques ce que tu risques c'est une mauvaise performance si tu traces les objets les plus lointains d'abord (pixel shader qui tourne inutilement)

oui effectivement je vois maintenant bien le problème pour les perfs dont tu parles sur objets lointains.

Tu le fais bien pour tes matériaux semi transparents, je ne vois pas en quoi c'est impossible de trier par distance.

je me suis mal exprimé, effectivement ca ne pose aucun probleme de trier par distance ces objets la, seulement ca sera au detriment du tri actuel qui est par materiaux.

en gros c'est
- soit on dessine tous les cube bleu d'un coup, puis tous les cubes rouge (tri par materiaux et donc meilleur state sorting possible dans ce cas, ou alors j'ai pas compris ce qu'etait le state sorting)
- soit on dessine tous les cubes bleu de la zone 1, puis tous les cube rouge de la zone 1, et cela pour toutes les zone séquentiellement (tri par distance et sous tri par materiaux)

mais la deuxieme option comporte beaucoup plus de changement d'etats (on passe de bleu a rouge pour quasiment chaque zone) et est forcement plus consequente en terme de tri que la premiere. (dans la premiere il n'y a meme pas de tri en fait, vu que c'est l'arbre hierarchique de materiaux qui dessine le material root qui lui même dessine ses enfant etc)

Et comme dit précédemment, il peut être intéressant de trier :
- grands occludeurs d'autant s'ils sont peu nombreux et/ou si leur ordre ne change pas trop par frame.
- moins bons occludeurs ne sont pas si intéressant à trier exhaustivement (par distance) mais peuvent être tracés en ordre approximatif, par exemple en divisant les queues en zones qui peuvent se superposer. Et faire un tri par matériel (via material id ?) par zone.

tu as totalement raison la dessus, mon problème étant que a ce stade la je n'ai pas encore de use case particulier, et cherche a adopter la solution la plus générique (c'est peu être le problème d'ailleurs). en gros je sais pas si je vais avoir comme type de scène une ville dense en bâtiments, ou un champ en rase campagne avec peu d'occludeurs, et comme tu le dis ça ne nécessite pas les même ajustements a priori.

a moins qu'il y ai une méthode pour tout type de scène, pour savoir quel sont les grands occludeurs sur la frame courante, pour ne trier que ceux la, et donc les rendre en premier dans le bon ordre, mais je pense pas.

[LeGreg]

Je dirais que si tu n'es pas à un point où tu peux faire ce genre de jugement, c'est probablement prématuré et tu apprendras sans doute sur le tas.