Moteur de rendu soft en OpenGL ? - Page 1

Bon, voilà, je me suis mis un peu à OpenGL y a qqs jours, et j'avais envie de faire un petit moteur de rendu 3D logiciel... L'idée de base étant que je veux essayer de l'optimiser à fond pour mon processeur (Athlon XP Barton), pour pas trop me compliquer la vie à me renseigner sur les différences entre processeurs (au moins dans un premier tps), et si possible maximiser la localité en cache (travailler principalement par fragments de 512 ko, donc), quitte à perdre en qualité (ça obligera notamment à prendre des textures soit en basse résolution soit en format non-bitmap, i.e. générées par des bouts de code) Seulement j'imagine qu'il y a des exigences contradictoires pour la localité au niveau framebuffer, au niveau textures et au niveau regénération/stockage de la liste des triangles (s'il y a des grosses textures qui couvrent 1/3 de l'écran et plein de triangles, par exemple...) Ca peut même être encore plus fun au niveau cache si on rajoute de l'antialiasing ("compresser" le framebuffer tout en gardant une bonne localité )

Donc je sais pas trop sur quelle base partir :
* est-ce que c'est possible de faire facilement une "carte vidéo virtuelle", qui me permettrait d'utiliser mon moteur comme backend d'autres progs OpenGL, ou est-ce que c'est une usine à gaz absolument ingérable si on ne compte pas implémenter tous les petits détails ?
* est-ce qu'il y a des bons moteurs OpenGL open source qui me permettraient de les modifier sans trop de pbs, tout en ayant des zoulies images ? (genre Trinity; est-ce que c'est le plus adapté ? par exemple ce serait mieux si y avait aussi des persos qui bougent)
L'intérêt de partir sur une base pré-existante et donnant un rendu typique de situations "réelles" serait de pouvoir faire des statistiques sur l'image et ainsi permettre de savoir quelles sont les optimisations qui seront efficaces ou pas -- sinon, le risque de partir sur une fausse piste est élevé, en tout cas pour qqun comme moi n'ayant aucune expérience dans le domaine

<parenthèse>
A titre indicatif, juste pour me faire une idée de la faisabilité du truc, si un pro est au courant [sBibi ?] : dans un jeu typique 3D pas trop vieux, combien y a-t-il par frame [ça dépend de la résolution, bien sûr]
- de triangles ?
- de pixels rendus ? (en comptant ceux qui seront écrasés par des pixels plus proches)
- parmi ces pixels rendus, de pixels antialiasés, en AA 4x ? (i.e. n'étant pas totalement remplis par la couleur issue du texturing)
- de texels analysés ? de texels distincts analysés ?
- de triangles qui ont été rendus mais qui finalement ont été totalement recouverts par d'autres ?
</parenthèse>

Sinon, est-ce que je peux, pour pas trop avoir à me faire chier au début, faire faire le T&L par OpenGL (en soft ou en hard, peu importe) tout en prenant en charge le rendu ? Ou je suis vraiment obligé de tout refaire de A à Z, y compris les trucs simples mais nombreux genre matrice de rotation ?

Bon, évidemment c'est un projet un peu vague et probablement complètement irréaliste et/ou qui aura des performances très mauvaises et/ou un rendu très mauvais, mais ça peut être rigolo (hmm d'ailleurs ça ferait dans les combien au 3DMark01, le rendu soft de DX avec un processeur récent ? parce qu'il segfaulte qd je désactive l'accélération matérielle )

* est-ce que c'est possible de faire facilement une "carte vidéo virtuelle", qui me permettrait d'utiliser mon moteur comme backend d'autres progs OpenGL, ou est-ce que c'est une usine à gaz absolument ingérable si on ne compte pas implémenter tous les petits détails ?

ta "carte video virtuelle", ca serait juste faire une dll a loader avec le prog gl, et qui intercepte tous les calls gl. y a un truc qui fait deja ca, mais pas pour le rendu, c'est un logger gl qui te sort un gros fichier de log de tous les calls que tas fait, des valeurs de retour, des erreurs si y en a eues, etc, etc.. j'avais juste lu vite fait leur page, mais visiblement tout ce qu'ils font, c'est de faire par exemple une fonction glFrustum dans leur dll, qui va logguer, et appeller le vrai glFrustum de maniere transparente en lui faisant passer les params...

* est-ce qu'il y a des bons moteurs OpenGL open source qui me permettraient de les modifier sans trop de pbs, tout en ayant des zoulies images ? (genre Trinity; est-ce que c'est le plus adapté ? par exemple ce serait mieux si y avait aussi des persos qui bougent)

oue mais nan, trinity c pas un bon exemple si tu veux les modifier... heu franchement je sais pas t'as des trucs genre ogre qui sont opensource, mais bon c'est juste un moteur quoi, t'as pas de resources avec, de base ca affiche rien, donc je sais pas trop si c'est le genre de trucs que tu cherche...
a la rigueur ce que tu veux faire si j'ai bien compris ton truc de carte video virtuelle, c'est de virtuellement "remplacer" le driver pour emuler la cg aux yeux du prog qui tourne... pour ca t'as pas vraiment besoin de pouvoir modifier les src du moteur... sinon au pire pour tester des trucs, t'as des masses de tutos 3D utilisant gl qui peuvent tres bien faire l'affaire.
je veux bien te filer les src de trinity (si je les ai tjrs ) mais attention, c'est meta gore, c'etait mon premier prog C hein... je suis pas sur que t'en tirera grand chose.

L'intérêt de partir sur une base pré-existante et donnant un rendu typique de situations "réelles" serait de pouvoir faire des statistiques sur l'image et ainsi permettre de savoir quelles sont les optimisations qui seront efficaces ou pas -- sinon, le risque de partir sur une fausse piste est élevé, en tout cas pour qqun comme moi n'ayant aucune expérience dans le domaine

bah le pbl c'est que tes statistiques seront completement foireuses selon ce que tu prends comme exemple, ya pas de situation typique. tu prend un renderer de maps/persos Q3, t'en prends un autre du genre UE3, ca aura de toute evidence pas tout a fait les memes.. mmmh... "stats"

<parenthèse> A titre indicatif, juste pour me faire une idée de la faisabilité du truc, si un pro est au courant [sBibi ?]

lol

dans un jeu typique 3D pas trop vieux, combien y a-t-il par frame [ça dépend de la résolution, bien sûr] - de triangles ?

pas trop vieux == ?
je peux te donner les chiffres de HH si tu veux
deja rien que la ca varie bcp par frame, entre 800000 et 1.5Mtris (des fois au dessus de 2Mtris), et ca depend completement de ce que t'affiche biensur.. enfin c'est juste pour te donner un ordre de grandeur.

- de pixels rendus ? (en comptant ceux qui seront écrasés par des pixels plus proches)

completement dependant de la resol la...c'est pas trop le nombre de pixels rendus, c'est plutot le % d'overdraw...
a 0% d'overdraw (utopique ), et un framebuffer de 1600*1200, ca te fait juste 1 920 000 pixels...
a 500% d'overdraw ca fait... mmmh... bcp

- parmi ces pixels rendus, de pixels antialiasés, en AA 4x ? (i.e. n'étant pas totalement remplis par la couleur issue du texturing)

si c'est du FSAA (de tte facons toutes les autres formes d'AA marche pas super bien, et tous les projets plus ou moins serieux utilisent le FSAA des cartes),
t'en a 4x plus. c'est pas comme dans un raytracer ou tu regarde avant de multisampler les pixels si la difference de couleur avec les pixels d'a cote est suffisemment faible pour pouvoir skipper (ce qui te permet de decouper ton image plus ou moins en un quadtree). la le FSAA c'est juste, pour le FSAA 4x, 4 samples par pixel. pour le 8x, 8, etc..
tu multiplie juste la taille de ton framebuffer par ca.

<parenthese>
si tu veux rentrer encore plus dans les details (et LA c'est prise de tete ), les samples sont positionnes au niveau sub-pixel differemment selon les constructeurs. nvidia (jusqu'a present, je sais pas si ils l'ont change depuis), avaient leurs samples "alignes" dans le pixel (ex pour 4x)

,------,
| '  ' |
| .  . |
'------'

ati, c'est le meme pattern, mais rotationne legerement (j'ai plus les valeurs exactes en tete, et je me souviens plus dans que sens, peu importe)

,------,
|.   ' |
| ,   '|
'------'

et les samples d'ATI produisent des resultats legerement meilleurs que ceux de NV.

</parenthese>

- de texels analysés ? de texels distincts analysés ?

ca depend de trop de trucs aussi, et j'ai pas trop idee... ca depend de la methode de filtrage de ta texture, si c'est en nearest, en bilileaire, trilineaire, si y a de l'aniso, etc... si t'as des tris que t'affiche en multitexturing, d'autres sans multitexturing, etc...
c'est le genre de stats qui font aussi l'interet d'un truc comme la cg virtuelle dont tu parlais au debut, c'est que tu peux recup ces stats de facon precise, et t'en servir pour optimiser ton moteur apres, une sorte de profiler quoi

- de triangles qui ont été rendus mais qui finalement ont été totalement recouverts par d'autres ?

aucune idee, c'est bcp trop dependant du moteur ca. t'as des moteurs qui utiliseront de l'occlusion culling pour reduire l'overdraw, d'autres qui feront une premiere passe sans rien ecrire dans le color buffer, juste pour remplir le Z-buffer, et une autre passe ou la ils ecrivent les pixels mais se servent des Z qui sont deja la pour virer les pixels qui seront jamais affiches (c'est surtout utile pour les pixel shaders qui sont tres couteux, mais je pense que pour l'instant tu te fous un peu des pixel shaders ).

[EDIT]: d'autres qui utiliseront des portals extrudes pour clipper la geometrie et s'approcher du 0% d'overdraw (sachant que tu trouvera probablement pas ca dans des moteurs recents, c'est bcp plus avantageux d'y aller a la brutasse et de balancer quelques centaines ou milliers de polys supplementaire a la carte que de faire des calculs compliques pour tenter d'afficher que ceux exactement visibles...)
pareil, un truc a prendre en compte, c'est la taille des batch de triangles qui sont balances a la carte a chaque render call. la taille "optimale" pour le hardware recent se situe plus ou moins aux alentours de 2500-10000 tris par batch.

Sinon, est-ce que je peux, pour pas trop avoir à me faire chier au début, faire faire le T&L par OpenGL (en soft ou en hard, peu importe) tout en prenant en charge le rendu ?

non.
si tu le fais en hard, meme en admettant que tu puisse recuperer les vertex transformes de la carte, il faudrait les faire passer par le sens le plus lent, vram -> agp -> ram, et c'est tellement lent, qu'au final ca irait bcp plus lentement de les transformer en hard que de les transformer sur le cpu, surtt si t'utilise des trucs du genre MMX/SSE/SSE2 et autres
si tu le fais faire par gl en soft (deja je sais pas si tu peux forcer gl a faire les transformations en soft quand la carte gere le T&L hard, je pense pas), t'as aucun truc dans gl qui te permet de les recuperer. et meme si tu trouvais un moyen de les recup (en admettant que ca soit possible, ce qui m'etonnerait), ca serait hyper plus chiant et long que de le faire toi.

Ou je suis vraiment obligé de tout refaire de A à Z, y compris les trucs simples mais nombreux genre matrice de rotation ?

c'est pas ca qui te prendra le plus de temps, crois moi

Bon, évidemment c'est un projet un peu vague et probablement complètement irréaliste et/ou qui aura des performances très mauvaises et/ou un rendu très mauvais, mais ça peut être rigolo

non ca peut etre tres interessant... j'avais pense faire un truc dans ce genre, un truc que tu hook a la place de gl, qui a la meme interface que gl, et qui fait le rendu lui meme en te donnant un max de stats, mais c'est passe a la trappe faute de temps (et il en faut )

(hmm d'ailleurs ça ferait dans les combien au 3DMark01, le rendu soft de DX avec un processeur récent ? parce qu'il segfaulte qd je désactive l'accélération matérielle )

aucune idee..


par contre, quand je lis la premiere partie de ton post (jusqu'a avant le "Donc je sais pas trop sur quelle base partir:"), j'ai l'impression que tu parle pas de la meme chose que dans la deuxieme partie...
dans la premiere tu parle de faire un moteur de rendu soft. dans la deuxieme tu parle de faire des fonctions de rendu pour remplacer celles de gl... ca a un peu rien a voir.. c'est deux projets separes?

c'est pas un post c'est un roman !!

sBibi
: ta "carte video virtuelle", ca serait juste faire une dll a loader avec le prog gl, et qui intercepte tous les calls gl. y a un truc qui fait deja ca, mais pas pour le rendu, c'est un logger gl qui te sort un gros fichier de log de tous les calls que tas fait, des valeurs de retour, des erreurs si y en a eues, etc, etc.. j'avais juste lu vite fait leur page, mais visiblement tout ce qu'ils font, c'est de faire par exemple une fonction glFrustum dans leur dll, qui va logguer, et appeller le vrai glFrustum de maniere transparente en lui faisant passer les params...

Hmm j'ai l'impression que ça demanderait d'avoir une connaissance relativement exhaustive de toutes les fonctions, non ? C p-ê pas super exploitable pour un jeu industriel complet, surtout que le debuggage risque d'être tendu

* est-ce qu'il y a des bons moteurs OpenGL open source qui me permettraient de les modifier sans trop de pbs, tout en ayant des zoulies images ? (genre Trinity; est-ce que c'est le plus adapté ? par exemple ce serait mieux si y avait aussi des persos qui bougent)

oue mais nan, trinity c pas un bon exemple si tu veux les modifier... heu franchement je sais pas t'as des trucs genre ogre qui sont opensource, mais bon c'est juste un moteur quoi, t'as pas de resources avec, de base ca affiche rien, donc je sais pas trop si c'est le genre de trucs que tu cherche...

Moué :\ A vrai dire le truc c pas tellement que je veux les modifier, c surtout que je voudrais un truc bien complet à la base... Est-ce qu'il y aurait une alternative au fait de faire une dll opengl custom pour un jeu opengl ? Sachant que de toute façon un jeu comme ça ne sera pas modifiable *du tout*, donc rien qu'avoir une source de truc complet même difficilement modifiable (mais sur lequel on pourrait grepper les fonctions opengl appelées, voir leur contexte d'utilisation, voir si elles sont désactivables) serait pas mal... Trinity est p-ê un peu trop "simple", en ce sens qu'il n'y a que des trucs statiques

a la rigueur ce que tu veux faire si j'ai bien compris ton truc de carte video virtuelle, c'est de virtuellement "remplacer" le driver pour emuler la cg aux yeux du prog qui tourne... pour ca t'as pas vraiment besoin de pouvoir modifier les src du moteur... sinon au pire pour tester des trucs, t'as des masses de tutos 3D utilisant gl qui peuvent tres bien faire l'affaire.

Ben voilà, l'idéal ce serait la dernière leçon d'un tuto 3d qui fait un gros megamix du tuto entier et qui donne un résultat utilisable (i.e. avec le nb de triangles équilibré pour avoir un bon rendu avec une puissance raisonnable, pas pour pouvoir afficher un nombre de fonctions opengl maximal...)

je veux bien te filer les src de trinity (si je les ai tjrs ) mais attention, c'est meta gore, c'etait mon premier prog C hein... je suis pas sur que t'en tirera grand chose.

Bah elles sont sur ton site, non ? #trihacker#

bah le pbl c'est que tes statistiques seront completement foireuses selon ce que tu prends comme exemple, ya pas de situation typique. tu prend un renderer de maps/persos Q3, t'en prends un autre du genre UE3, ca aura de toute evidence pas tout a fait les memes.. mmmh... "stats"

moué, c un peu le pb... mais à la limite juste des stats pour 2-3 jeux suffiraient à se faire une idée c pas trop un pb si mon moteur ne marche pas bien dans absolument tous les cas, mais c un pb s'il ne marche bien dans aucun cas ^^

<parenthèse> A titre indicatif, juste pour me faire une idée de la faisabilité du truc, si un pro est au courant [sBibi ?]

lol

Bah t un peu le boss en 3d de yn, non ?

dans un jeu typique 3D pas trop vieux, combien y a-t-il par frame [ça dépend de la résolution, bien sûr] - de triangles ?

pas trop vieux == ?

peu importe, du moment que tu me dis de quel jeu tu parles

je peux te donner les chiffres de HH si tu veux deja rien que la ca varie bcp par frame, entre 800000 et 1.5Mtris (des fois au dessus de 2Mtris), et ca depend completement de ce que t'affiche biensur.. enfin c'est juste pour te donner un ordre de grandeur.

OK, ça me donne déjà un ordre de grandeur, c pas mal

- de pixels rendus ? (en comptant ceux qui seront écrasés par des pixels plus proches)

completement dependant de la resol la...c'est pas trop le nombre de pixels rendus, c'est plutot le % d'overdraw...
a 0% d'overdraw (utopique ), et un framebuffer de 1600*1200, ca te fait juste 1 920 000 pixels...
a 500% d'overdraw ca fait... mmmh... bcp

oué, je voulais dire le % d'overdraw en général (ce qui est à peu près équivalent à donner le nb de pixels rendus pour une résolution fixée), pas le # de pixels rendus en fonction du % d'overdraw, parce que ça j'aurais peut-être (enfin je *pense* ) pu réussir à trouver tout seul

tu n'as aucune fourchette ?

hmm d'ailleurs on doit avoir plusieurs types d'overdraw, l'overdraw "normal" qui est # pixels rendus / # pixels écran, et l'overdraw de "pixels utiles", qui est le # de pixels rendus dont un changement de couleur aurait résulté en un changement de couleur du pixel à l'écran / # pixels écran... En gros si le moteur arrive à clipper de manière 100% fiable les triangles de manière à n'avoir recouvrement que pour l'antialiasing et pour l'alpha blending, on est censé avoir % overdraw normal = % overdraw pixels utiles...

- parmi ces pixels rendus, de pixels antialiasés, en AA 4x ? (i.e. n'étant pas totalement remplis par la couleur issue du texturing)

si c'est du FSAA (de tte facons toutes les autres formes d'AA marche pas super bien, et tous les projets plus ou moins serieux utilisent le FSAA des cartes),

yup (c'est bien la même chose que le multisampling, hein ? [juste pour être sûr de pas dire de connerie] )

t'en a 4x plus. c'est pas comme dans un raytracer ou tu regarde avant de multisampler les pixels si la difference de couleur avec les pixels d'a cote est suffisemment faible pour pouvoir skipper (ce qui te permet de decouper ton image plus ou moins en un quadtree). la le FSAA c'est juste, pour le FSAA 4x, 4 samples par pixel. pour le 8x, 8, etc.. tu multiplie juste la taille de ton framebuffer par ca.

Non, t'as pas tout à fait capté ce que je voulais dire : si je veux économiser de la BP mémoire en ne stockant pas les 4 couleurs des subpixels s'ils sont tous identiques, alors quel est le %age de pixels qui vont être économisés par cette technique ?

<parenthese>
... coupé pour éviter l'effet "roman" ... </parenthese>

y a pas une histoire de truc rotatif aussi dans les 5900 ?

- de texels analysés ? de texels distincts analysés ?

ca depend de trop de trucs aussi, et j'ai pas trop idee... ca depend de la methode de filtrage de ta texture, si c'est en nearest, en bilileaire, trilineaire, si y a de l'aniso, etc... si t'as des tris que t'affiche en multitexturing, d'autres sans multitexturing, etc...
c'est le genre de stats qui font aussi l'interet d'un truc comme la cg virtuelle dont tu parlais au debut, c'est que tu peux recup ces stats de facon precise, et t'en servir pour optimiser ton moteur apres, une sorte de profiler quoi

oué (enfin cela dit ça doit être une des stats les plus dures à avoir, parce qu'il faut implémenter tout le mipmapping et toutes les techniques de filtrage pour avoir ça...)
mais tu n'as aucune idée de ce que ça pourrait être en trilinéaire sans aniso, par ex ?
(enfin au pire je peux tjs faire des bench sur carte 3D avec la fréq de la mémoire downclockée à juste un peu plus que ce qu'il faut pour le RAMDAC, ça devrait être précis mais malheureusement ça compte aussi la BP pour les pixels [pas seulement les texels], et ça ignore aussi les éventuels caches )

- de triangles qui ont été rendus mais qui finalement ont été totalement recouverts par d'autres ?

aucune idee, c'est bcp trop dependant du moteur ca. t'as des moteurs qui utiliseront de l'occlusion culling pour reduire l'overdraw, d'autres qui feront une premiere passe sans rien ecrire dans le color buffer, juste pour remplir le Z-buffer, et une autre passe ou la ils ecrivent les pixels mais se servent des Z qui sont deja la pour virer les pixels qui seront jamais affiches (c'est surtout utile pour les pixel shaders qui sont tres couteux, mais je pense que pour l'instant tu te fous un peu des pixel shaders ).

oué je crois pas que je ferai un émulateur de pixel shader enfin si, si je veux économiser de la BP mémoire j'appellerai des mini-progs pour rendre les textures mais certainement pas en asm pixelshader ^^

[EDIT]: d'autres qui utiliseront des portals extrudes pour clipper la geometrie et s'approcher du 0% d'overdraw (sachant que tu trouvera probablement pas ca dans des moteurs recents, c'est bcp plus avantageux d'y aller a la brutasse et de balancer quelques centaines ou milliers de polys supplementaire a la carte que de faire des calculs compliques pour tenter d'afficher que ceux exactement visibles...)

OK

pareil, un truc a prendre en compte, c'est la taille des batch de triangles qui sont balances a la carte a chaque render call. la taille "optimale" pour le hardware recent se situe plus ou moins aux alentours de 2500-10000 tris par batch.

Bon à savoir et concrètement, qu'est-ce que ça change ces render batch ? (euh, et un render batch c'est un appel à glBegin()/glEnd() ? ou c autre chose ?) (et oui, j'en suis pas encore très loin dans le tuto de nehe ^^)

Sinon, est-ce que je peux, pour pas trop avoir à me faire chier au début, faire faire le T&L par OpenGL (en soft ou en hard, peu importe) tout en prenant en charge le rendu ?

non.
si tu le fais en hard, meme en admettant que tu puisse recuperer les vertex transformes de la carte, il faudrait les faire passer par le sens le plus lent, vram -> agp -> ram, et c'est tellement lent, qu'au final ca irait bcp plus lentement de les transformer en hard que de les transformer sur le cpu, surtt si t'utilise des trucs du genre MMX/SSE/SSE2 et autres si tu le fais faire par gl en soft (deja je sais pas si tu peux forcer gl a faire les transformations en soft quand la carte gere le T&L hard, je pense pas), t'as aucun truc dans gl qui te permet de les recuperer. et meme si tu trouvais un moyen de les recup (en admettant que ca soit possible, ce qui m'etonnerait), ca serait hyper plus chiant et long que de le faire toi.

OK, donc opengl a pas de fonction pour faire ça... mais j'imagine que je loupe plein de subtilités pour la réflexion de la lumière ?

Ou je suis vraiment obligé de tout refaire de A à Z, y compris les trucs simples mais nombreux genre matrice de rotation ?

c'est pas ca qui te prendra le plus de temps, crois moi

oué, j'imagine ^^ mais c un peu chiant... (si je dois faire T&L et compagine, ça veut dire aussi plein d'autres trucs de merde)

Bon, évidemment c'est un projet un peu vague et probablement complètement irréaliste et/ou qui aura des performances très mauvaises et/ou un rendu très mauvais, mais ça peut être rigolo

non ca peut etre tres interessant... j'avais pense faire un truc dans ce genre, un truc que tu hook a la place de gl, qui a la meme interface que gl, et qui fait le rendu lui meme en te donnant un max de stats, mais c'est passe a la trappe faute de temps (et il en faut )

Faire un hook complet, ça doit qd même pas être évident...

(hmm d'ailleurs ça ferait dans les combien au 3DMark01, le rendu soft de DX avec un processeur récent ? parce qu'il segfaulte qd je désactive l'accélération matérielle )

aucune idee..

OK, et t'as pas un vague benchmark comparant la couche soft opengl (avec un proc récent) et la couche hard (avec une CG récente) qui traîne dans un coin, histoire de voir ce que je peux espérer avoir comme performance ?

par contre, quand je lis la premiere partie de ton post (jusqu'a avant le "Donc je sais pas trop sur quelle base partir:"), j'ai l'impression que tu parle pas de la meme chose que dans la deuxieme partie... dans la premiere tu parle de faire un moteur de rendu soft. dans la deuxieme tu parle de faire des fonctions de rendu pour remplacer celles de gl... ca a un peu rien a voir.. c'est deux projets separes?

Pas tant que ça : l'idée serait de faire un moteur relativement flexible en C++ (template pawa ), optimisé pour des trucs simples, et que je pourrais aussi utiliser via une couche d'émulation opengl qui évidemment aurait des besoins différents pour l'optimisation, mais qui permettrait de pouvoir faire des tests du moteur tout en ayant des zoulies images, et surtout en ayant une idée à peu près correcte des situations courantes et moins courantes à optimiser... (chose que je ne réussirais pas à avoir avec un cube qui tourne et donc mon moteur pourrait s'avérer catastrophique dans une situation "réelle", malgré ses 1000fps sur le cube qui tourne en FSAA 64x ^^)


Et sinon, merci de prendre le tps d'écrire ton "roman"

alphakiller> et celui là une encyclopédie...

Hmm j'ai l'impression que ça demanderait d'avoir une connaissance relativement exhaustive de toutes les fonctions, non ? C p-ê pas super exploitable pour un jeu industriel complet, surtout que le debuggage risque d'être tendu

bah, t'as les specs OpenGL qui sont la pour ca, t'as la description du comportement de la fonction de l'interface, apres tu l'implemente comme tu veux, c'est long c'est sur, mais justement ca peut te permettre d'apprendre en detail comment fonctionnent toutes les commandes GL, et au depart tu peux tres bien faire que des fonctions dummy, et en implementer au fur et a mesure...
genre point de depar: toutes les fct gl necessaires a un tuto de base pour afficher un triangle, et ensuite t'implemente les autres progressivement, en montant dans les tutos...

Moué :\ A vrai dire le truc c pas tellement que je veux les modifier, c surtout que je voudrais un truc bien complet à la base... Est-ce qu'il y aurait une alternative au fait de faire une dll opengl custom pour un jeu opengl ? Sachant que de toute façon un jeu comme ça ne sera pas modifiable *du tout*, donc rien qu'avoir une source de truc complet même difficilement modifiable (mais sur lequel on pourrait grepper les fonctions opengl appelées, voir leur contexte d'utilisation, voir si elles sont désactivables) serait pas mal...

Ben voilà, l'idéal ce serait la dernière leçon d'un tuto 3d qui fait un gros megamix du tuto entier et qui donne un résultat utilisable (i.e. avec le nb de triangles équilibré pour avoir un bon rendu avec une puissance raisonnable, pas pour pouvoir afficher un nombre de fonctions opengl maximal...)

franchement, si tu pars d'un truc deja "complet", ca va etre la galere a faire ton truc, tu commencera a avoir un truc potable a l'ecran que quand t'aura deja implemente masse de trucs, pke sans certaines fonctions pleins de trucs foireront, et les bugs d'affichage, tu saura pas si ca vient de ton implementation ou de si il te manque tel ou tel truc, bref c'est pas le mieux a mon avis... et pour voir comment les fct gl sont utilisees, t'as les glspecs qui sont bien mieux, et plus precises...

Trinity est p-ê un peu trop "simple", en ce sens qu'il n'y a que des trucs statiques

clairement ©

Bah elles sont sur ton site, non ? #trihacker#

ah bon? je les ai laissees? me semblait avoir fait le menage...

moué, c un peu le pb... mais à la limite juste des stats pour 2-3 jeux suffiraient à se faire une idée c pas trop un pb si mon moteur ne marche pas bien dans absolument tous les cas, mais c un pb s'il ne marche bien dans aucun cas ^^

les stats pour 2-3 jeux, je peux pas te dire, c'est des trucs que t'as aucun moyen de savoir sans avoir acces aux sources du jeu, ou a des stats publiques postees par la boite qui a fait le jeu, et sans avoir de tool qui te le dise.
c'est le genre de trucs que ta "cg virtuelle" te donnera par contre... et tu pourra l'optimiser en fonction de ca, mais comme ca, dsl, je peux pas te dire
meme pour HH je peux pas te dire pour tout ce qui est % d'overdraw, j'ai pas encore mesure ca, j'en suis pas encore aux optis de ce genre, et c'est trop vague, ca change trop en fonction de la scene, des objets, des settings de qualite de rendu, de tas de trucs...
tu peux tres bien avoir des overdraws enormes, qui depassent 10 000%, comme des trucs entre 10 et 100%...
soit dit en passant, les % d'overdraw enormes tu les as surtout dans des scenes ou t'as beaucoup de blending...

Bah t un peu le boss en 3d de yn, non ?

chais pas, ya pleins d'inconnus connectes

OK, ça me donne déjà un ordre de grandeur, c pas mal

heu dans un jeu comme Q3, t'es bien en dessous de 100 000 polys plutot dans les 10 000 - 20 000, dans d'autres, j'en sais rien, entre les deux, dans doom3, ca sera sans doute bcp moins que le million.
(ils doivent extruder leurs putains de shadow volumes de merde, et ca bouffe du temps quand t'as bcp de tris...), mais la encore, j'en suis pas sur du tout, c'est juste des suppositions...

oué, je voulais dire le % d'overdraw en général (ce qui est à peu près équivalent à donner le nb de pixels rendus pour une résolution fixée), pas le # de pixels rendus en fonction du % d'overdraw, parce que ça j'aurais peut-être (enfin je *pense* ) pu réussir à trouver tout seul

tu n'as aucune fourchette ?
hmm d'ailleurs on doit avoir plusieurs types d'overdraw, l'overdraw "normal" qui est # pixels rendus / # pixels écran, et l'overdraw de "pixels utiles", qui est le # de pixels rendus dont un changement de couleur aurait résulté en un changement de couleur du pixel à l'écran / # pixels écran...

si t'as pas de faces blendees c'est les memes... et en genral par % d'overdraw c'est le premier qui est designe...

En gros si le moteur arrive à clipper de manière 100% fiable les triangles de manière à n'avoir recouvrement que pour l'antialiasing et pour l'alpha blending, on est censé avoir % overdraw normal = % overdraw pixels utiles...

oue mais c'est completement inutile de faire ca... ca te prendra plus de temps de clipper exactement ce qu'il te faut que d'afficher quelques trucs de plus..

yup (c'est bien la même chose que le multisampling, hein ? [juste pour être sûr de pas dire de connerie] )

Non, t'as pas tout à fait capté ce que je voulais dire : si je veux économiser de la BP mémoire en ne stockant pas les 4 couleurs des subpixels s'ils sont tous identiques, alors quel est le %age de pixels qui vont être économisés par cette technique ?

heu... O_o pas sur d'avoir compris non... SI les 4 samples ont la meme couleur alors t'en stocke qu'un? O_o heu ton frame buffer est a taille variable alors? et ca doit etre un beau bordel pour l'indexer...
ou bien tu veux dire stocker temporairement 4 couleurs des 4 samples, calculer les couleurs, et apres les blender en une seule, et stocker cette couleur la? mais ca va pas marcher pour un FSAA ca en plus ca serait la merde a rasterizer...

y a pas une histoire de truc rotatif aussi dans les 5900 ?

chais pas, peut etre, j'ai pas regarde comment etait gere le FSAA dessus...

oué (enfin cela dit ça doit être une des stats les plus dures à avoir, parce qu'il faut implémenter tout le mipmapping et toutes les techniques de filtrage pour avoir ça...) mais tu n'as aucune idée de ce que ça pourrait être en trilinéaire sans aniso, par ex ?

(enfin au pire je peux tjs faire des bench sur carte 3D avec la fréq de la mémoire downclockée à juste un peu plus que ce qu'il faut pour le RAMDAC, ça devrait être précis mais malheureusement ça compte aussi la BP pour les pixels [pas seulement les texels], et ça ignore aussi les éventuels caches )

heu... pas sur de ce que tu veux dire la , si c'est ce que je pense, t'as pas que des pixels/texels, t'as aussi tous les vertex buffers qui sont en vram...

oué je crois pas que je ferai un émulateur de pixel shader enfin si, si je veux économiser de la BP mémoire j'appellerai des mini-progs pour rendre les textures mais certainement pas en asm pixelshader ^^

ok... ca peut etre interessant aussi hein (#v4p0r#, un projet de plus pour 2042? )

et concrètement, qu'est-ce que ça change ces render batch ? (euh, et un render batch c'est un appel à glBegin()/glEnd() ? ou c autre chose ?) (et oui, j'en suis pas encore très loin dans le tuto de nehe ^^)

heu, non
enfin si ca peut etre vu comme ca, vu que de tte facons GL batche ce que tu lui file dans les glBegin/glEnd, enfin ca depend de l'implementation du driver, mais je pense pas qu'il y en aie qui batchent pas pour les glBegin/glEndm ca ramerait encore plus...
mais c'est plutot les vertex buffers que t'affiche avec des trucs comme glDrawElements()

glDrawElements, ca t'affiche 1 batch, c'est 1 render call...

OK, donc opengl a pas de fonction pour faire ça... mais j'imagine que je loupe plein de subtilités pour la réflexion de la lumière ?

heu, non c'est juste une implementation hard du lighting de GL... (que de tte facons tu devra implementer si tu veux tout gerer )

oué, j'imagine ^^ mais c un peu chiant... (si je dois faire T&L et compagine, ça veut dire aussi plein d'autres trucs de merde)

Faire un hook complet, ça doit qd même pas être évident...

OK, et t'as pas un vague benchmark comparant la couche soft opengl (avec un proc récent) et la couche hard (avec une CG récente) qui traîne dans un coin, histoire de voir ce que je peux espérer avoir comme performance ?

Pas tant que ça : l'idée serait de faire un moteur relativement flexible en C++ (template pawa ), optimisé pour des trucs simples, et que je pourrais aussi utiliser via une couche d'émulation opengl qui évidemment aurait des besoins différents pour l'optimisation, mais qui permettrait de pouvoir faire des tests du moteur tout en ayant des zoulies images, et surtout en ayant une idée à peu près correcte des situations courantes et moins courantes à optimiser... (chose que je ne réussirais pas à avoir avec un cube qui tourne et donc mon moteur pourrait s'avérer catastrophique dans une situation "réelle", malgré ses 1000fps sur le cube qui tourne en FSAA 64x ^^)

ok

Et sinon, merci de prendre le tps d'écrire ton "roman"

de rien... ?

• sBibi zzzzzzz

tiens au fait... si tu veux un autre ordre de grandeur pour le nombre de tris
http://www.adellion.com/images/Preview1.jpg

6766 tris

sBibi
:

Hmm j'ai l'impression que ça demanderait d'avoir une connaissance relativement exhaustive de toutes les fonctions, non ? C p-ê pas super exploitable pour un jeu industriel complet, surtout que le debuggage risque d'être tendu

bah, t'as les specs OpenGL qui sont la pour ca, t'as la description du comportement de la fonction de l'interface, apres tu l'implemente comme tu veux, c'est long c'est sur, mais justement ca peut te permettre d'apprendre en detail comment fonctionnent toutes les commandes GL, et au depart tu peux tres bien faire que des fonctions dummy, et en implementer au fur et a mesure... genre point de depar: toutes les fct gl necessaires a un tuto de base pour afficher un triangle, et ensuite t'implemente les autres progressivement, en montant dans les tutos...

Moué... La DLL d'OpenGL ne contient *que* des fonctions 3D moyennement haut niveau ? (genre, gestion des polygones, mais aucune gestion des surfaces de Bézier & co)
Et sinon, ça s'interfacerait comment avec le vrai OpenGL ? Je crée un OpenGL personnalisé dans le répertoire du prog (avec l'intégralité des fonctions d'OpenGL; d'ailleurs, est-ce qu'il y a des variables globales, ou est-ce qu'il n'y a que des fonctions et que je peux donc tout remplacer par des références à une seule fonction qui se contente de faire un "return" ? [mais j'imagine que pour un paquet de fonctions, ça va faire un sympathique "undefined behaviour" )), je fais un "opengl_o.dll", et je me débrouille pour recompiler le .lib d'opengl (ou bien le patcher à la barbare en hexa ) pour qu'il référence cette DLL ? ou il y a encore d'autres subtilités, genre header de version ou champ "nom de la lib" dans la opengl32.dll ?

Autre solution, faire croire à OpenGL que j'ai une deuxième CG, mais je ne sais pas du tout comment on fait ni si c plus simple ou plus compliqué...

franchement, si tu pars d'un truc deja "complet", ca va etre la galere a faire ton truc, tu commencera a avoir un truc potable a l'ecran que quand t'aura deja implemente masse de trucs, pke sans certaines fonctions pleins de trucs foireront, et les bugs d'affichage, tu saura pas si ca vient de ton implementation ou de si il te manque tel ou tel truc, bref c'est pas le mieux a mon avis... et pour voir comment les fct gl sont utilisees, t'as les glspecs qui sont bien mieux, et plus precises...

hmm, je pense que ça doit qd même être plus galère de comprendre le contexte d'un appel sans la source... mais c vrai que si je fais une dll opengl custom, je pourrai aussi tester avec des progs dont j'ai la source
C'est facile de débugger une DLL sans avoir le source du prog appelant dans vs ? (je pense que oui, mais bon...)

moué, c un peu le pb... mais à la limite juste des stats pour 2-3 jeux suffiraient à se faire une idée c pas trop un pb si mon moteur ne marche pas bien dans absolument tous les cas, mais c un pb s'il ne marche bien dans aucun cas ^^

les stats pour 2-3 jeux, je peux pas te dire, c'est des trucs que t'as aucun moyen de savoir sans avoir acces aux sources du jeu, ou a des stats publiques postees par la boite qui a fait le jeu, et sans avoir de tool qui te le dise.

Les stats publiques hyper-détaillées (plus que juste le nb de triangles) j'y crois moyen

c'est le genre de trucs que ta "cg virtuelle" te donnera par contre... et tu pourra l'optimiser en fonction de ca, mais comme ca, dsl, je peux pas te dire
meme pour HH je peux pas te dire pour tout ce qui est % d'overdraw, j'ai pas encore mesure ca, j'en suis pas encore aux optis de ce genre, et c'est trop vague, ca change trop en fonction de la scene, des objets, des settings de qualite de rendu, de tas de trucs...
tu peux tres bien avoir des overdraws enormes, qui depassent 10 000%, comme des trucs entre 10 et 100%... soit dit en passant, les % d'overdraw enormes tu les as surtout dans des scenes ou t'as beaucoup de blending...

Mouais...

Bah t un peu le boss en 3d de yn, non ?

chais pas, ya pleins d'inconnus connectes

mais ils auraient un peu de mal à me répondre, surtout que j'ai pas mon adresse e-mail dans mon profil et qu'il faut télécharger une archive ZIP sur mon site pour avoir accès à ma vraie adresse ^^

OK, ça me donne déjà un ordre de grandeur, c pas mal

heu dans un jeu comme Q3, t'es bien en dessous de 100 000 polys plutot dans les 10 000 - 20 000, dans d'autres, j'en sais rien, entre les deux, dans doom3, ca sera sans doute bcp moins que le million. (ils doivent extruder leurs putains de shadow volumes de merde, et ca bouffe du temps quand t'as bcp de tris...), mais la encore, j'en suis pas sur du tout, c'est juste des suppositions...

1 million, c qd même assez méchant pour la localité... grosso modo, je comptais découper mon écran en 16 blocs de 192 ko chacun (un peu plus si on compte l'anti-aliasing), et donc stocker la liste des triangles correspondant à chaque bloc en RAM pour ensuite faire une passe de rendu spécifique à chaque bloc.
(après, on peut faire dans les raffinements, du style découper en 8x4 blocs au lieu de 4x4 blocs pour limiter le nb de triangles coupés tout en ayant la même localité en cache)

Donc je pense que je vais plutôt viser les 100 000 triangles ou moins.

Hmm à ce propos quel est en moyenne le nb de triangles effectivement affiché qui utilisent un vertex donné ? (parmi tous les vertex figurant dans un triangle affiché)
Ca économiserait de la RAM de regrouper ces vertex-là entre eux ?

En gros si le moteur arrive à clipper de manière 100% fiable les triangles de manière à n'avoir recouvrement que pour l'antialiasing et pour l'alpha blending, on est censé avoir % overdraw normal = % overdraw pixels utiles...

oue mais c'est completement inutile de faire ca... ca te prendra plus de temps de clipper exactement ce qu'il te faut que d'afficher quelques trucs de plus..

Oui bien sûr, ct purement théorique ^^ (surtout que ça doit être sympa à faire au pixel près )

Non, t'as pas tout à fait capté ce que je voulais dire : si je veux économiser de la BP mémoire en ne stockant pas les 4 couleurs des subpixels s'ils sont tous identiques, alors quel est le %age de pixels qui vont être économisés par cette technique ?

heu... O_o pas sur d'avoir compris non... SI les 4 samples ont la meme couleur alors t'en stocke qu'un? O_o heu ton frame buffer est a taille variable alors? et ca doit etre un beau bordel pour l'indexer...

C pas le bordel si tu considères que la quantité de données effectives dans ton framebuffer est effectivement variable, mais que tu accèdes à chaque donnée par un offset fixe comme dans un bitmap normal --> donc tu ne gagnes pas en mémoire bouffée, par contre tu gagnes en bande passante.

Grosso modo t'as un flag qui te dit si le stockage est fait sur un ou 4 samples, et selon ce flag tu fais des choses différentes... Perso je pense que je vais stocker ça en bouffant un bit sur le champ alpha.

ou bien tu veux dire stocker temporairement 4 couleurs des 4 samples, calculer les couleurs, et apres les blender en une seule, et stocker cette couleur la? mais ca va pas marcher pour un FSAA ca en plus ca serait la merde a rasterizer...

Euh non c pas ça que je voulais dire...

oué (enfin cela dit ça doit être une des stats les plus dures à avoir, parce qu'il faut implémenter tout le mipmapping et toutes les techniques de filtrage pour avoir ça...) mais tu n'as aucune idée de ce que ça pourrait être en trilinéaire sans aniso, par ex ?

(enfin au pire je peux tjs faire des bench sur carte 3D avec la fréq de la mémoire downclockée à juste un peu plus que ce qu'il faut pour le RAMDAC, ça devrait être précis mais malheureusement ça compte aussi la BP pour les pixels [pas seulement les texels], et ça ignore aussi les éventuels caches )

heu... pas sur de ce que tu veux dire la , si c'est ce que je pense, t'as pas que des pixels/texels, t'as aussi tous les vertex buffers qui sont en vram...

aussi

oué je crois pas que je ferai un émulateur de pixel shader enfin si, si je veux économiser de la BP mémoire j'appellerai des mini-progs pour rendre les textures mais certainement pas en asm pixelshader ^^

ok... ca peut etre interessant aussi hein (#v4p0r#, un projet de plus pour 2042? )

oué ^^ enfin bon, ça sera assez trivial à gérer, il suffira juste de changer l'appel à la fonction de texturage normale par un appel à la fonction personnalisée

et concrètement, qu'est-ce que ça change ces render batch ? (euh, et un render batch c'est un appel à glBegin()/glEnd() ? ou c autre chose ?) (et oui, j'en suis pas encore très loin dans le tuto de nehe ^^)

heu, non
enfin si ca peut etre vu comme ca, vu que de tte facons GL batche ce que tu lui file dans les glBegin/glEnd, enfin ca depend de l'implementation du driver, mais je pense pas qu'il y en aie qui batchent pas pour les glBegin/glEndm ca ramerait encore plus...
mais c'est plutot les vertex buffers que t'affiche avec des trucs comme glDrawElements()
glDrawElements, ca t'affiche 1 batch, c'est 1 render call...

OK... Et concrètement, ça fait quoi ? Ca force la CG à rendre le truc à l'écran pour que le prog puisse aller le lire ?

Et même si ce n'est pas ça, j'imagine qu'il y a une fonction pour faire ça... Est-ce que
les progs s'en servent souvent ? (par exemple pour faire joujou avec le stencil) Parce que vu le débit mémoire du CPU, ça va limiter le framerate à 300/n fps avec n le nombre de fois où on demande ce type d'actualisation de l'écran

OK, donc opengl a pas de fonction pour faire ça... mais j'imagine que je loupe plein de subtilités pour la réflexion de la lumière ?

heu, non c'est juste une implementation hard du lighting de GL... (que de tte facons tu devra implementer si tu veux tout gerer )

Mais est-ce qu'il y a des algos barbares avec des réflexions des sources de lumière sur les autres polygones, ou est-ce que c le programme qui se charge de faire tout ça ?

oué, j'imagine ^^ mais c un peu chiant... (si je dois faire T&L et compagine, ça veut dire aussi plein d'autres trucs de merde)

Faire un hook complet, ça doit qd même pas être évident...

OK, et t'as pas un vague benchmark comparant la couche soft opengl (avec un proc récent) et la couche hard (avec une CG récente) qui traîne dans un coin, histoire de voir ce que je peux espérer avoir comme performance ?

Et sinon, merci de prendre le tps d'écrire ton "roman"

de rien... ?

[/cite]

sBibi :
tiens au fait... si tu veux un autre ordre de grandeur pour le nombre de tris
http://www.adellion.com/images/Preview1.jpg

6766 tris

c pas bien de se moquer, et puis les arbres sont presques détaillés ^^

(par contre j'adore l'herbe ultra-réaliste et la forme de l'église qui doit pas avoir plus de 20 triangles surtout que c un peu les deux trucs centraux dans l'image ^^)

oups, j'avais lu ton post l'autre jour, mais completement oublie d'y repondre

Moué... La DLL d'OpenGL ne contient *que* des fonctions 3D moyennement haut niveau ? (genre, gestion des polygones, mais aucune gestion des surfaces de Bézier & co)

je peux pas te dire, j'ai jamais utilise ces fct la.

Et sinon, ça s'interfacerait comment avec le vrai OpenGL ? Je crée un OpenGL personnalisé dans le répertoire du prog (avec l'intégralité des fonctions d'OpenGL; d'ailleurs, est-ce qu'il y a des variables globales, ou est-ce qu'il n'y a que des fonctions et que je peux donc tout remplacer par des références à une seule fonction qui se contente de faire un "return" ? [mais j'imagine que pour un paquet de fonctions, ça va faire un sympathique "undefined behaviour" )), je fais un "opengl_o.dll", et je me débrouille pour recompiler le .lib d'opengl (ou bien le patcher à la barbare en hexa ) pour qu'il référence cette DLL ?

ca devrait suffire normalement, le mieux c'est que t'essaye
pour le "undefined behaviour", oue, c'est ce que je voulais dire la:

franchement, si tu pars d'un truc deja "complet", ca va etre la galere a faire ton truc, tu commencera a avoir un truc potable a l'ecran que quand t'aura deja implemente masse de trucs, pke sans certaines fonctions pleins de trucs foireront, et les bugs d'affichage, tu saura pas si ca vient de ton implementation ou de si il te manque tel ou tel truc, bref c'est pas le mieux a mon avis...

ou il y a encore d'autres subtilités, genre header de version ou champ "nom de la lib" dans la opengl32.dll ?

aucune idee, je me suis pas penche en details la dessus... essaye tu verra bien... tu fais une dll avec toutes les fonctions gl (tu dois avoir la liste dans les glspecs ou qquepart ailleurs sur OpenGL.org, sinon le plus simple est encore que tu reprenne le .h ...), et t'essaye de la faire loader par une app gl quelconque dl du net en l'appelant opengl32.dll et en la mettant dans le rep courant...
franchement des details comme ca j'ai jamais essaye donc j'en sais rien du tout...
mais si t'essaye de faire ca, poste tes resultats ici, ca peut etre interessant

Autre solution, faire croire à OpenGL que j'ai une deuxième CG, mais je ne sais pas du tout comment on fait ni si c plus simple ou plus compliqué...

oula, ca sent le truc hyper chiant, hyper bordelique, hyper instable, et hyper long
enfin je me trompe peut etre...

hmm, je pense que ça doit qd même être plus galère de comprendre le contexte d'un appel sans la source...

heu, je trouve pas deja dans les sources tu trouve de tout et n'importe quoi, t'as certaines fonctions qui ont des tas de comportements different, et dans une source lambda t'en aura que quelques uns d'utilises la plupart du temps... au moins dans les glspecs, t'as la description detaillee, en anglais, de ce que fait la fonction... de tout ce qu'elle peut prendre en parametre, comment elle se comporte, ce qu'elle fait, et ce qu'elle renvoie... bref je trouve ca mieux
t'as pas besoin de te preoccuper de comment l'interface est utilisee (pas pour le debut du moins), juste de comment elle est censee se comporter, et pour ca --> glspecs.
enfin tu fais comme tu veux, c'est un detail.. au final t'as une fonction qui a les memes i/o que l'equivalent gl, et qui fait la meme chose... juste qu'en passant par les glspecs t'as bcp moins de chances de te planter... c'est quand meme la reference

Les stats publiques hyper-détaillées (plus que juste le nb de triangles) j'y crois moyen

bah oue, c'est pour ca que j'en ai pas a te donner

Mouais...

t'as l'air sceptique?
certaines methodes de rendu de brouillards localises/lumiere volumetriques demandent une superposition de layers alpha blendees... quand je dis 10 000% encore c'est gentil pour certains trucs
bon apres si tu fais un rendu d'un champ de nuages affiches a coups de petits billboards tu peux facilement depasser les 50 / 100 000 % d'overdraw ... d'ou l'interet des impostors, faire un rendu de tout ca dans un pbuffer que tu reutilise pendant quelques frames, et apres au lieu de rendre 50 billboards, t'en rends plus qu'un... mais bon ca c'est des optis qui se font cote moteur, ta cg virtuelle elle s'en bat les couilles avec du chardon frais ceuilli dans les montagnes alpines par des marmottes serviables (c)
elle se contente juste d'afficher ce qu'on lui demande, apres si le moteur est optimise avec les pieds c'est pas son pbl... et je pense pas que tu t'amuse a afficher des centaintes de nuages avec ton moteur software

1 million, c qd même assez méchant pour la localité...

1 million rendu par frame, pas 1 million dans la scene hein... y a un gars sur gamedev... son moteur affiche des scenes de plus de 20 millions de polys (mais c'est pas 20Mtris par frame hein , c'est dans la scene entiere)
apres le moteur se demmerde comme y peut, compression de vertices par exemple, le gars en question utilisait un algo de compression avec pertes, jpeg style.

enfin c'est clair que (pour l'instant) c'est pas le genre de polycount le plus frequent

grosso modo, je comptais découper mon écran en 16 blocs de 192 ko chacun (un peu plus si on compte l'anti-aliasing), et donc stocker la liste des triangles correspondant à chaque bloc en RAM pour ensuite faire une passe de rendu spécifique à chaque bloc.

tu parle du moteur soft la, plus de la cg virtuelle? ca peut etre une facon de faire oue, la dreamcast avait un systeme du meme genre y me semble...

Hmm à ce propos quel est en moyenne le nb de triangles effectivement affiché qui utilisent un vertex donné ? (parmi tous les vertex figurant dans un triangle affiché) Ca économiserait de la RAM de regrouper ces vertex-là entre eux ?

?? O_o
heu tes triangles...
t'as une liste de vertex, et une liste d'index.
dans la liste de vertex t'as aucun vertex en double.
et tes triangles c'est la liste d'index..

en GL, t'affiche les triangles comment? avec glVertex3f, glNormal3f, glTexCoord2f, etc, etc, des truc dans le genre? si oui oublie tout dessuite...
tu trouvera aucun bon moteur qui utilise ca, du moins qui utilise ca pour afficher la geometrie. (pour le HUD et autres, tant qu'il y a pas bcp de tris, ca peut encore aller..)
c'est la facon la plus lente d'afficher des tris ca...

normalement t'utilise un truc du genre glVertexPointer, glNormalPointer, etc... et un coup de glDrawElements avec une liste d'index (soit triangles, soit triangle strip)...

Oui bien sûr, ct purement théorique ^^ (surtout que ça doit être sympa à faire au pixel près )

oue, une bonne prise de tete pour aller plus lentement enfin ca apprend tjrs des trucs

C pas le bordel si tu considères que la quantité de données effectives dans ton framebuffer est effectivement variable, mais que tu accèdes à chaque donnée par un offset fixe comme dans un bitmap normal --> donc tu ne gagnes pas en mémoire bouffée, par contre tu gagnes en bande passante.
Grosso modo t'as un flag qui te dit si le stockage est fait sur un ou 4 samples, et selon ce flag tu fais des choses différentes... Perso je pense que je vais stocker ça en bouffant un bit sur le champ alpha.

moue...

oué je crois pas que je ferai un émulateur de pixel shader enfin si, si je veux économiser de la BP mémoire j'appellerai des mini-progs pour rendre les textures mais certainement pas en asm pixelshader ^^

ok... ca peut etre interessant aussi hein (#v4p0r#, un projet de plus pour 2042? )

oué ^^ enfin bon, ça sera assez trivial à gérer, il suffira juste de changer l'appel à la fonction de texturage normale par un appel à la fonction personnalisée

je parlais de l'emulateur de pixel shaders

et concrètement, qu'est-ce que ça change ces render batch ? (euh, et un render batch c'est un appel à glBegin()/glEnd() ? ou c autre chose ?) (et oui, j'en suis pas encore très loin dans le tuto de nehe ^^)

heu, non
enfin si ca peut etre vu comme ca, vu que de tte facons GL batche ce que tu lui file dans les glBegin/glEnd, enfin ca depend de l'implementation du driver, mais je pense pas qu'il y en aie qui batchent pas pour les glBegin/glEndm ca ramerait encore plus...
mais c'est plutot les vertex buffers que t'affiche avec des trucs comme glDrawElements()
glDrawElements, ca t'affiche 1 batch, c'est 1 render call...

OK... Et concrètement, ça fait quoi ? Ca force la CG à rendre le truc à l'écran pour que le prog puisse aller le lire ?

Et même si ce n'est pas ça, j'imagine qu'il y a une fonction pour faire ça... Est-ce que
les progs s'en servent souvent ? (par exemple pour faire joujou avec le stencil) Parce que vu le débit mémoire du CPU, ça va limiter le framerate à 300/n fps avec n le nombre de fois où on demande ce type d'actualisation de l'écran

pour que le prog puisse aller le lire??? heu y va rien lire du tout le prog...
et tu veux dire quoi par "faire joujou avec le stencil"?

glDrawElements prends une liste de vertex (qui peut contenir les coords, des normales, couleurs, texcoords, etc), et une liste d'index, et deux modes possibles d'interpretation de cette liste d'index: GL_TRIANGLES ou GL_TRIANGLE_STRIP.

glDrawElements balance toute cette merde au driver, qui le balance a la carte, qui le rasterize. point barre. tu peux pas recuperer les vertex transformes sur la carte. ca va que dans un sens.. prog->driver->carte. c'est le sens le plus rapide, des que tu fais un transit dans l'autre sens (via un glReadPixels quelconque, ou des que t'appelle une fonction qui a besoin de _demander_ un truc a la carte, ca introduit une bulle dans le pipeline, ca sabote le paralellisme CPU/GPU, ca desync tout, l'appel devient bloquant si il a besoin d'attendre que la FIFO de render commands se vide pour pouvoir s'executer, et une fois qu'il a pu recuperer les trucs que tu lui as demande, il doit le transferer de la carte au driver a toi. et c'est hyper lent... (et la, c'est le drame... ))
les seuls cas de figure ou c'est vraiment indispensable de demander un truc a la carte, c'est dans le cadre de l'occlusion culling hardware (c'est pour ca que pour l'instant ca sux et que ca peut etre bcp plus avantageux de calculer tes occlusion maps sur le CPU pendant que le GPU rend ta geometrie...), et quand tu veux faire un screenshot ou recuperer une partie de ton frame buffer.

tu devrais vraiment aller lire les glspecs, oui c'est long et chiant, mais... ...

Mais est-ce qu'il y a des algos barbares avec des réflexions des sources de lumière sur les autres polygones, ou est-ce que c le programme qui se charge de faire tout ça ?

le programme? tu veux dire le moteur qui utilise gl? O_o
bah il peut tres bien ne pas du tout utiliser le lighting de gl.
et les algos du lighting de gl ont rien de barbare non... c'est juste un truc classique. tu dois aussi avoir ca dans les glspecs je pense...

c pas bien de se moquer, et puis les arbres sont presques détaillés ^^

*tousse*

(par contre j'adore l'herbe ultra-réaliste et la forme de l'église qui doit pas avoir plus de 20 triangles surtout que c un peu les deux trucs centraux dans l'image ^^)

oue moi aussi j'adore

heu tiens au fait, je viens de tomber par hazard la dessus...


EDIT: et aussi, vu que tu parlais de stencil, histoire que tu vois ou ca se situe exactement dans le pipeline: http://www.opengl.org/resources/features/StencilTalk/sld004.htm

c'est plus clair que de longues explications
et va lire les glspecs bordel de merde
ou achete toi un manuel OpenGL et lis le, t'as tout ca explique dedans (plus ou moins )