by En cours de maths... ne me demandez pas pourquoi, mais en voyant le prof tracer la représentation graphique d'une fonction (avec des log et des shx et des chx = il voulait nous épater parce que c'était pas au programme, mais qu'on comprenait tous) J'ai eu une lumière...
Je savais depuis longtemps que l'optimisation se ferait au niveau de l'affichage des lignes, car pour les points, à moins d'être moins précis, le calcul ça reste du calcul. Seulement, pour les lignes c'est un judicieux amalgame entre accès à matrice et à liste, ce qui ralenti considérablement le système au niveau du traitement des données..
Je vais essayer d'être le plus clair possible pour pas obliger à ouvrir le classeur tns pour comprendre ^^
Avant (car je viens de le modifier) : Pour tracer une ligne (avec le point compris) je fais :
- On calcule les coordonnées X et Y du point sur l'écran (avec algo pour connaître les sens des normales et tracer la face mais ça on s'en fou pas notre problème..)
- On stock X dans xspp1 et Y dans yspp1
// Tracage d'une face
- On extrait les points à relier de la matrice (on les stock dans des variables pour éviter l'accès à la matrice plusieurs fois)
- On trace une ligne entre point 1 et point 2
- On essaye de savoir si c'est un quad/tri en fonction du nombre de colonnes de la matrice
- On trace 3 lignes de plus si c'est un quad (23 puis 34 puis 41)
- Sinon on trace 2 lignes de plus pour le tri (23 puis 31)
- Et enfin si erreur on renvoie rien (donc on a tracé une ligne pour rien, remarquez comme l'algo est cochon...)
// Pour tracer une ligne :
- On rajoute X et Y dans les listes des lignes ET On provoque une erreur ( 1/0 )
C'est là que le code perd de son optimisation... A CHAQUE ligne on provoque une erreur. L'intérêt de provoquer une erreur est que la ligne ne se trace pas, et on peut ainsi utiliser une seule liste pour tracer toutes les lignes. Ok... mais pas A CHAQUE lignes... je ne sais pas où j'avais mis mon cerveau le jour où j'ai fait l'algo !!
En effet, c'est complètement inutile de provoquer l'erreur entre les lignes d'une meêm face puisqu'elle sont reliées entre elles par un même point à chaque fois...
En gros j'avais dans une liste :
{1,2,undef,2,3,undef,3,4,undef,4,1,undef....} soit 1/3 de "undef" d'erreur en fait..
Maintenant : Je revus l'algo pour ne tracer que manuellement l'erreur entre chaque face, ce qui épurge les 1/3 d'erreur et en met que 6 (car 6 faces) au lieu de 12 (car 12 lignes) avant pour un simple cube...
Bien que ceci raccourcis le temps de rendu de 20% ... (oui 20% sur un gros modèle ça fait beaucoup hein), il reste toujours une grosse opti à faire encore. En effet, ma liste actuelle ressemble à ça :
{1,2,2,3,3,4,4,1,undef,...}
Avouez, vous avez envie de me taper ? C'est encore inutile de faire une ligne entre 2 et 2, ce sont les mêmes points !
Après (projet) :
je travaille donc sur la réalisation de fonction créatrices de triangles et de carrés 2D (non pas en 3D, car ça c'est pour la librairie), en gros, un code modifié de la ligne mais qui accepte plus d'arguments.
Vala vala je vous tiens au courant !
ps : Si vous avez une idée de pourquoi les cosinus et Sinus hyperbolique et logarithme m'ont fait faire cette déduction, je vous en remercierais ! xD
