Moteur3D - Page 2

http://www-iiuf.unifr.ch/~schweizp/infogra/Chap2.htm 2.13

jackiehchan: heu non tu les trace pas les cotes... tu fais juste que remplir le tableau...

neurone: ben pas forcement non...
si t'as un truc comme ca:

___________
|\-_       \
| \ "-_ 1   \
|  \   "-_   \
|   \     "-_ \
|    \       "-\
|     \  2    /
|      \     /
|   3   \   /
|        \ /
|_________V

[b][/b]

dessiner chacun des triangles separement t'oblige a calculer les pentes de chacunes des aretes internes que tu rajoute, mais aussi, tu "casse" les scanlines,
du coup tu perds l'interet de pouvoir allumer 8, 16 ou 32 pixels d'un coup, vu que le scanline est decoupe en deux ou en trois...
donc le surplus de calcul qu'implique une version generale qui utilise une liste de cotes est peut etre compense par ca

l'ideal a mon avis c'est d'avoir les deux. tu regarde combien de cote a le polygone que tu veux dessiner. si il en a trois, tu le remplis avec une routine rapide de remplissage de triangles, si il en a plus, tu le remplis avec la methode qui utilise la liste de cotes

Ah, oué, j'avais pas du tout imaginer ce cas là ...
Dans ce cas là, oué, c sur que l'on perd trop ...

sBibi a écrit :
tu gagne qd meme un peu
et t'as benche une routine qui recopie ligne par ligne a partir d'un buffer 4* plus grand dans l'ecran?

Et la différence entre une routine de copie de buffer en asm et une en C ?
Aux dernières nouvelles, le moteur de Galmiza tourne à environ 20~25 fps avec 400 points à l'écran. Et il est, selon ses dires, "non optimisé".

Bah en asm ça sera toujours plus rapide qu'en C

Ben moi je n'ai que des routines generales.

jahow a écrit :
Et la différence entre une routine de copie de buffer en asm et une en C ? Aux dernières nouvelles, le moteur de Galmiza tourne à environ 20~25 fps avec 400 points à l'écran. Et il est, selon ses dires, "non optimisé".

erf? seulement 25 fps pour 400 points? oue c'est pas top...
(surtout si ca fait qu'afficher des points )

Ca affiche toutes les lignes aussi mais pas de face pleines.

Tu utilises quoi pour tracer tes lignes ?

LineLib

Mais j'en fait une autre pour apprendre et pour ensuite clipper ces lignes, et au final, je ferais une routine pour remplir des triangles.

c'est quoi, Linelib ?

J'utilise une routine de la librairie linelib fait par Jimmy Mardell.

edit: je l'ai bien entendu modifiée pour qu'elle soit compatible avec la largeur de mon ecran.

heu tu parles tt le temps de "la largeur de mon ecran."
il a quoi de particulier ton ecran?

Ben tu sais, dans mon moteur 3D (programmé comme un porc), pour l'instant, j'alloue 4*2000 octets pour ne pas avoir a clipper de ligne.
L'ecran virtuel etant 4 fois plus grand (en surface) que l'ecran visible de la ti89, sa largeur est de 40octets.
Linelib est programmé pour fonctionner sur des ecrans de 30octets de large (donc pret a ete utilisée en pointant LCD_MEM).


Sinon, les 25 images par secondes sont atteintes quand l'ecran affiche 400 lignes environ et la ti projete 400 points (bien sûr rotations effectuées pour chaque point).

Les rotations ne sont pas du tout optimisées, non seulement du point de vu des operations assembleur mais surtout de l'algorithme.

Moi je trouve que c'est pas mal 25 fps pour 400 points...

En parlant de lignes, ca-y-est, j'ai fini ma routine pour afficher des lignes (non clippées ... faut commencer facile, nan?)

Apparement, elle est plus rapide que celle de Jimmy Mardell (auteur de Linelib qui ne clippe pas les lignes non plus), pas de beaucoup (10% plus rapide d'apres mes tests), mais est plus grosse (20% plus grosse a vu d'oeil).

Merci sBibi de ne pas m'avoir aidé, ce n'est pas ironique.

Est-ce que tu peux me la passer stp, que je la benche ?

Voila, jackiechan, c'est dans ta boite.

resultats ?????

J'ai fait des tests:

Pour afficher dans une memoire un certain nombre de lignes (toutes les configurations possibles), lorsque la routine de Jimmy met 4 min 08, la mienne met 3 min 46.

Dans le test, je fais attention à ne pas executer trop d'instruction "parasites", c.a.d le nombre d'instructions qui ne font pas partie des routines de ligne est negligeable.

Donc ma routine est 8.87% plus rapide (minimum a cause des instructions parasites qui tendent a diminuer l'ecart)

Bon, Résultat du bench (sur vti, donc pas très fiable) :
La valeur indiquée, est le temps mis pour afficher des tonnes de lignes
ExtendeD : 717
Jackiechan : 760 (-6% )
Galmiza : 817 (-14% )

Ta fonction est donc 14% plus lente que celle d'ExtendeD (qui est vriament très rapide, je trouve), donc ça va, si tu fais les optimisations que je t'ai dites, tu n'auras pas trop de pb pour rattraper ExtendeD

Pour un debutant, c'est deja pas mal !

le trace de lignes ca vaut pas vraiment le coup de passer du temps a l'optimiser, a moins que tu compte laisser ton moteur en wireframe.
essaye plutot de coder et d'accelerer le remplissage de triangles. la ce que tu devra optimiser c'est surtout un traceur de lignes horizontales

Tiens d'ailleurs j'avais commencé à travailler sur un moteur 3d, mais j'avais laissé tombé (manque de courage...), donc si qqun veut mes réflexions sur la routine de triangle, pas de pb (pas de vrai code, mais en gros une structure qui permet un tracé extrêmement rapide). Ou bien si ça intéresse vraiment quelqu'un je peux essayer de finir ma routine de triangle.

c'etait quoi ton idee?

Vas-y, balance ton idée, ça pourra tjs servir

Enfin c pas juste une idée, c une vraie routine.
En gros c une routine de triangle non texturée, ultra-rapide (mais qui demande ~ 16 kb de RAM) dont le remplissage tourne à peu près à 140 cycles par ligne (attention, ce n'est qu'une estimation), et pour l'initialisation je sais pas trop, mais ça ne devrait pas être démentiel; en plus on peut théoriquement l'utiliser pour des polygones convexes quelconques (gros gros gain de temps).
Pour vous expliquer le principe, en gros elle se sert du fait qu'il n'y a pas grand chose qui change entre deux lignes d'un triangle, ce qui lui permet d'être significativement plus rapide que la routine de genlib, qui elle passe systématiquement par l'intermédiaire d'une routine de tracé de ligne horizontale.
Je peux aussi essayer de retrouver mon bench de la routine de genlib. (il me semble que ça tournait autour de 900 cycles par ligne)

Donc si ça intéresse qqun, je peux essayer de la finir (parce que je viens de re-regarder mes notes et ça devrait pas être très clair pour qqun d'autre que moi )

sBibi:
tu gagne qd meme un peu et t'as benche une routine qui recopie ligne par ligne a partir d'un buffer 4* plus grand dans l'ecran?

J'ai benché pour un buffer de 3000 octets, et l'économie avec les movem.l pour un effacement est de 796 cycles; 192 cycles d'économie pour une recopie. Donc ça fait ne fait vraiment rien du tout de perceptible à l'écran.

Pollux, ton offre est certes tentante, mais dès que j'ai reussit a creer ma propre fonction pour tracer des lignes, je me suis dis:
"Je ne suis pas qu'un bon a rien"
Je vais essayer d'en faire une moi meme.