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