State sorting et Depth sorting dans un Moteur 3D
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é :
Citation:
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,