Bonjour Alain,
Je ne comprends rien à toutes ces librairies graphiques, mais je note que tu bosses sur la réimplémentation de SuperTuxKart...

Super !!!!

Alain,
Peut-être qu'un MiniGL qui appellerait directement Warp3D mais, MiniGL revu et corrigé avec tes codes (sources) de Wazp3D ... Cela pourrait être sympa peut-être ?

Il serait sympa de refaire un MiniGL qui soit vraiment correspondant aux capacités de Warp3D ... Si un tel projet voyait le jour, j'y participerai volontiers (avec mes maigres connaissances) en // de l'AmiDARK Engine ;)

@+
Message édité par : AmiDARK / 02-11-2012 11:23
Message édité par : AmiDARK / 02-11-2012 11:23

Salut à tous

non non je réécrirai pas minigl : je me suis déjà assez fait chier à recompiler/débugger StormMesa (aminet/stormmesa2010.lha)

Mais comme Crisot est dans le code il pourrait peut être nous rajouter qques tests pour éviter les appels continuels à W3D_SetTextureBlend et W3D_SetState avant un W3D_DrawArray()

non je fait plus rien sur SuperTuxKart :en fait ça reviendrai à améliorer minigl

>Un Wazp3D qui ferait appel aux fonctions Warp3D ? Comment cela pourrait se faire ? Il ne peut y avoir qu'une bibilothèque Warp3D en mémoire

Tu a tout à fait raison et cela pose donc qques difficultés sinon je l'aurai fait depuis longtemps ...
Evidemment on peut renommer le vrai Warp3D.library en RealWarp3D.library et avoir Wazp3D dans Warp3D.library = ça résout la cohabitation mémoire
Mais après le vrai problème c'est la compilation de Wazp3D avec dans le source des appels de memes fonctions vers la vraie Warp3D et Wazp3D
Je pense alors que le plus simple (sic) serait d'avoir une soft3d.library comme dans WinUAE qui fasse le rendu (et donc elle seule appellerait RealWarp3D.library)

Alain

On va laisser son job à Wazp3D: Un rendu software. C'est vrai que l'idée est séduisante, mais quitte à avoir les sources de MiniGL, autant plancher là dessus.

Bon, on va planter le décord: Je n'ai jamais fait d'OpenGL. J'ai un moteur 3D utilisant directement Warp3D, il fonctionne très bien, mais à ma manière. Je ne connais pas le fonctionnement d'un moteur utilisant des fonctions OpenGL, donc, je ne sais pas lesquelles sont appellées, ni dans quel ordre. A quel moment sont fait les transformations, à quel moment est fait le rendu, est ce que le clipping est fait avant/après transformation, tout ça, je ne sais pas.

Je ne réécrirais pas tout MiniGL, c'est trop de boulot, je n'en ai ni le temps, ni le courage. Par contre, il est possible de réécrire des fonctions entières lorsqu'elles ont l'air critique et qu'elles sont assez peu dépendantes du reste.

J'ai trouvé une "entrée" qui me semble interressante: glDrawElementTriangles (glDrawElements). C'est une fonction par laquelle A PRIORI toutes les routines de triangles semble passer. En tout cas, lorsque je supprime les fonctions de traçage de cette fonction, Quake3 et Hurrican n'ont plus d'affichage, donc ça passe par là.

Dans cette fonction, il y a du clipping. A priori il ne semble pas avoir été fait avant, il est fait au moment du rendu. Je sais pas si c'est tout OpenGL qui est comme ça où si c'est spécifique MiniGL, mais en fait ça m'arrange.

Plus étrange cependant, il y a un appel à une fonction succeptible des faires de transformations 3D, et ça, je ne pige absolument pas pourquoi.

glDrawElement() est une fonction appelée directement par le programme: Son nombre d'appel dépend directement de l'optimisation du moteur. Sur un lieu au hazard, ioQuake3 faisait appel une centaine de fois à cette fonction par frame. C'est bien peu comparé au nombre d'appel Warp3D que la fonction elle même fait abusivement.

Comme je le disais plus haut, cette fonction fait le clipping des triangles. Actuellement, pour ce faire, elle fait appel à une sous fonction qui clip UN triangle puis l'affiche immédiatement. En buffirisant les triangles clippés, il y a là encore un gain colossale

Donc, dans l'asbolu, en réécrivant cette fonction pour qu'elle trace tout d'un unique DrawArray (triangle non clippé et clippé), il y a une base d'optimisation énorme rien que sur elle.

Avis des connaisseurs là dessus? Alain?

>glDrawElementTriangles
Oui je vois la fonction devant mes yeux
D'abord elle recupere les points à partir des vertex,texcoords,normals
puis je pense qu'elle fait la transformation de points "normalisés (cad de -1.0 à 1-+1.0) en coords écran
Après je vois du clipping mais comme Warp3D sait faire le Scissor alors je pense qu'il doit (devrait?) être appelé que quand le hard sait pas faire le tracage

Après je sais pas trop quelle partie trace vraiment faudrait tester avec qques printf

a priori ce serait ça non?

#if 1

if (or_code == 0 && !context->enable.PolygonOffsetFill
&& !NEED_SPECIAL_FILL)
{
MaybeLock(context);

if (context->enable.CullFace)
IWarp3D->W3D_SetState(context->w3dContext, W3D_CULLFACE, W3D_ENABLE);

IWarp3D->W3D_DrawElements(context->w3dContext,
W3D_PRIMITIVE_TRIANGLES, w3dType, count, index_pointer);


if (context->enable.CullFace)
IWarp3D->W3D_SetState(context->w3dContext, W3D_CULLFACE, W3D_DISABLE);

MaybeUnlock(context);

return;
}
#endif


Mais alors pourquoi pas plus de triangles tracés en un coup?
faudrait tester avec qques printf de variables notamment "count" au début de glDrawElementTriangles

#define VAR(var) printf(" " #var "= %ld\n",(ULONG)(var) );

VAR(count)
VAR(type)

La partie que tu as montré est la seule partie capable de tracer pas mal de triangles d'un coup.

Car quand or_code==0, c'est qu'aucun point n'a été détecté hors frustum lors de la transformation => tout est tracé d'un coup.

Là où ça se complique, c'est justement sur le code qui se trouve plus bas. A partir du moment où or_code!=0 et and_code==0, ça veux dire qu'il y a des polygons dans l'écran, MAIS que certains d'entre eux sont à clipper.

C'est à ce moment préci que ça devient un massacre: MiniGL traite alors les polygons 1 par 1. Pour chaque vertex, il test le "outcode" qui a été créé aux 3 vertex lors de "v_MaybeTransform()". Si les outcode témoignent que le polygon n'est pas clippé, il le trace alors, mais SEUL. Si les outcode montrent un polygon clippé, il envoit le polygon à la fonction hc_ClipAndDrawPoly(), qui le clip avec un algo pas terrible, puis le trace, seul.

Pour en revenir à v_MaybeTransform(): A priori, c'est bel et bien cette fonction qui fait l'intégralité des transformations à l'objet, en créant au passage le "outcode" pour chaque vertex.

Pour le scissor... je ne sais plus bien pourquoi je ne m'en sert pas. Sur mon moteur perso j'ai choisi de faire le clipping moi même, mais avant les transformations. Le clipping 3D est plus lent que le clipping 2D, mais c'est tellement plus flexible. Perso, si je projète avant de clipper, je me retrouve avec des polygons projetés derrière la caméra, que je n'arrive plus à clipper correctement en 2D puisque lors coordonnées sont fausses.
Message édité par : Crisot / 02-11-2012 14:52

Ok si c est le clipper le probleme alors j ai le code dun clipper 3d qque part
je te l envoie lundi
Sinon on doit pouvoir bufferiser les points (Clippes) avant qu il les trace par 3

Btw tu as une archive des sources +makefile de minigl prete a recompiler? je peut l avoir?
Merci

J'ai du mal m'exprimer: Clipping 3D j'ai un truc très propre.

Ce qui me choque plus, c'est que MiniGL fait un Clipping *2D* après transformations/projection. Et ça je pige moins, car à moins qu'il y ai déjà eu un clipping 3D au moins par le plan "znear", y'a peu de chances que les poly 2D proches soient viables...

Je me demande si le plus simple serait pas de remplacer la plupart des appels
a w3d-drawelements par notre propre version de drawelement qui
elle bufferizerait les triangles recus

Alain

Je viens de faire le test sur mon moteur (pur Warp3D donc, pas de MiniGL): Entre afficher 10.000 triangles d'un seul DrawArray() ou faire 10.000 DrawArray() d'un seul triangle, l'écart de performance est finalement à la limite du négligeable, à ma grande surprise, pour ne pas dire désarroi...

Le problème de MiniGL doit aller beaucoup plus loin, entre les changements de blendmode, les bindtexture à gogo, etc...