on est d'accord : Il y a bien une liste P dans chaque Mesh et une liste P2 de la Scene à afficher Idem pour les indices

(Dans mes commentaires je parlais toujours des points à afficher)

Ma remarque était plutôt sur le fait de changer de format (cad copier +- les valeurs une à une) en cours de route vs faire un memcpy de P vers P2 (au même format)

>j'ose supposer que W3D utilise au moins ça

:-) on espere mais on serait pas si étonné du contraire :-P

Et ton A de RGBA? :)

 bien sûr j'ai sauté une étape

format unique: X Y Z /X2 Y2 Z2/UV/VNX VNY VNZ A

>Voici maintenant simplement comment fonctionne OpenGL (et pourquoi je l'ai copié à mort)

>-un buffer SOURCE de vertex incluant XYZ/COULEUR/UV/NORMALE

NB: je vois pas pourquoi tu mettais ta couleur RGBA en entrée du lighting puisque elle vient que du materiau et de la VN

void LightShader(Scene3D* S,Point3D *P,ULONG Pnb,Material3D* MAT)

>A titre perso, comme je fais du normal mapping, j'ai un Vector3f normal, Vector3f binormal, et Vector3f tangent. Ca fait quand même 9 floats inutiles au rendu par vertex.

On est d'accord c'est pas parfait: l'idéal serait de gérer un format "variable" de points

Alain

Ahhh 1000 excuses, oui oui il n'y a qu'un seul buffer de vertex à afficher. Bien évidement, hors de question d'utiliser un memcpy(), le changement de structure entre source et destination se fait naturellement dans la boucle de transform&lightning!

INPUTformat *input; //(le mesh de base: x/y/z/uv/normal/binormal/tangent)
OUTPUTformat *output; (le buffer qui sera rendu: x/y/z/rgba/uvw)

for i=0 to nombre de vertex

{

output xyz = input xyz transformé

output rgba = éclairage (une petite boucle si plusieurs lumières)

output uvw = input uv

}

Tout connement non? Et au pire si on a plusieurs type de VertexOUTPUT, suffit d'adapter à peine de code pour s'adapter à tous les types.

Ensuite on fait pareil avec les indices pendant la boucle de clipping:

for i=0 to nombre d'indice

{

Si polygon pas clippé on copy les 3 indices de IN à OUT

Si polygon hors écran on ne fait rien

Si polygon à cheval, on créés quelques nouveaux vertex OUT/indice OUT

}

Puis évidement un dernier petit passage sur les vertex pour les transformer à l'écran 2D.

>>> NB: je vois pas pourquoi tu mettais ta couleur RGBA en entrée du lighting puisque elle vient que du materiau et de la VN

Pour précalculer les lumières statiques sur les objets statiques. Aucune raison de recalculer à chaque frame la lumière d'un plafonnier fixe sur un mur. Ainsi dans mon transform&lightning je ne calcule l'éclairage que si l'objet OU la lumière est de type "dynamique (modifable/déplaçable)".

>comme je fais du normal mapping, j'ai un Vector3f normal, Vector3f binormal, et Vector3f tangent.

Il doit certainement y avoir un moyen d'avoir moins de champs pour faire ça...

Malheureusement j'ai pas le niveau en math pour trouver une meilleure solution... :-(

Si on raisonne avec la normale de la face (par commodité) donc le plan de la face. Alors comme la texture est collé*  dans le plan de la face (2D) la seule inconnue est dans quelle direction (vecteur 2d) se déroule la bumptexture (déroulé comme une moquette)

C'est comme si la texture était un papier épinglée sur la face par une épingle en son centre elle peu juste tourner sur cette axe (normale de face) je pense intuitivement que ce seul champ (rotation) est nécessaire

Alain

* on pourrait imaginer que la texture soit projetée en biais (cad plan texture != normale face) sur la face et pas vraiment collée dessus mais on peut se limiter à concevoir des objets n'ayant que des objets à texture collé à plat pour être tranquille (genre tes murs) . Pour les objets plus complexes il faudrait des textures "déroulées" dont chaque triangle s' applique  à plat