Forum TI-Planet.org

Bonsoir à tous,
actuellement je travaille sur un moteur 3D, tous est dans le titre
Le problème c'est que pour la rotation du cube il me faut des calculs rapides de sinus et cosinus
car j'utiliserai une matrice permettant de faire tourner le cube de la manière suivant :

sinus angle_alpha = sina
cosinus angle_alpha = cosa
sinus angle_beta = sinb
cosinus angle_beta = cosb
sinus angle_gama = sinc
cosinus angle_gama = cosc

avec la matrice que l'on applique à chaque point
[cosb * cosc cosb * sinc -sinb ]
[sina*sinb*cosc - cosa*sinc sina*sinb*sinc + cosa*cosc sina*cosb]
[cosa*sinb*cosc + sina*sinc cosa*sinb*sinc - sina*cosc cosa*cosb]

Et je voudrai connaitre une façon rapide de calculer tout ça , ou quelque chose de plus simple.

Une des seul façon de faire : retravailler la matrice avec les équations trigonométriques afin de virer au maximum les multiplications, puis après une LUT pour les sin/cos et c'est parti
Il est bien de noter que en plus comme les deux angles sont sur [0-255], tout les calculs peuvent être fait avec a.
Tu peux toujours regarder le code source de gLib, (bien que la matrice ne gère que 2 angles X,Y) pour te donner une idée (c'est un axiom, mais tout est en asm donc bon )
src par là : http://codewalr.us/index.php?topic=199.msg3857#msg3857

Merci,
ça a l'aire vraiment bien.
Aussi j'ai vu qu'il y avait pas mal d'options mais je crois que je ne les coderais pas toutes sauf le tri des faces visibles.
Dis moi aussi, quand tu recalcule les points, tu les calcules tous ou juste ceux qui sont à l'écran et un peu au bord ??
Sinon pour le précalcul, tu fais comment ?? pendant la compilation du programme Axe ??

Tout les points sont recalculé : chercher quels points il faudrait calculer serait plus lourd en terme de calcul que de tout rotationner
Le précalcul des tables se fait à l’exécution du programme, au début - mais on peut très bien utiliser des tables déjà faites au début et juste les charger en mémoire.

Merci pour ta réponse rapide
bon j'ai trouvé un moyen de remplacer la matrice orthogonale(9 nombres) utilisée pour la rotation par un quaternion (4 nombres) .
Cela a cependant l'aire plus complexe mais si ça pouvait alléger le moteur
cf : http://openclassrooms.com/forum/sujet/c ... gonometrie

EDIT : enfin je trouve pas ça super complexe mais le problème c'est que c'est un peu moins rapide mais plus précis (tout est relatif)
cf: http://fr.wikipedia.org/wiki/Quaternion ... l%27espace
regarder en bas de la page pour les tableaux

REEDIT : Dis moi, comment tu fais pour stocker des nombres à virgule dans la LUT ??

Franchement les quaternions, c'est que si tu veux te débarrasser d'un lock dans las axes avec la matrice de rotation - mais c'est trop couteux en calcul.... sauf faire quaternion->matrice de rotation->rotation de vecteur (precision+rapidité)
Les rotations de vecteur avec les quaternions sont trop lourdes.

Les nombres à virgules sont pas gérés, mais j'utilise un format "fixed point" (tout les nombres multipliés par 64) (soit 0.7 en format)

Une multiplication de deux nombres en fixed point revient à : a*b/64

C'est vrai que niveau calcul il y a mieux.
Mais j'ai réussi à écrire une routine qui normalise le quaternion en moins de 4500 T-states ce qui est pas mal vu la complexité à mettre en place les multiplications et les divisions ainsi que les sqrt en asm.
Mais le problème c'est qu'il faut impérativement trouver quelque chose pour ne calculer que les points de l'écran et une petite marge autour (en cas de rotation rapide)ce qui pourrait allerger les calculs pour un grand espace avec bcp de points.
Aussi une autre routine pour actualiser l'écran buffer pour un déplacement de caméra,etc.
Aussi pour les quaternions il est possible d'utiliser le format fixed point 128 car les valeurs vont de -1 à 1.
Merci à toi

EDIT: sinon pour les autres transformations que la rotation, j'utiliserai les matrices 4*4 aux coordonnées homogènes

Bah si tu veux vraiment faire ça, il faut déterminer les équations de droites régissant ton frustrum et le tester avec ton point dans les coordonnées non transformée.
Le problème de cette méthode c'est qu'elle requiert 3 mul / droites et y'a 5 droites à traiter, soit 15 mul (5 dot product) là où la rotation n'en prend *que* 9. (sachant que le cliping sera aussi plus pénible sans pré-rotation). Pour actualiser l'écran je conseille la routine ifastcopy de ion, trouvable un peu partout - après tu peux essayer de mettre des calculs "utile" à la place du delay utilisé pour l'écran - pas simple mais possiblement rapide.
Et si tu veux de l'aide pour optimiser moi je veux bien aider

Oui mais c'est quoi la 5eme droite ??
J'ai déjà écris un NLERP pour la rotation mais je ne comprends pas à quoi sert l'angle theta dans la formule.
Qu'appels tu pré-rotation ?
Je vais m'expliquer sur la routine dont je parlais: alors le moteur lira une map codée en offsets qui correspondrons à un suite d'offsets pour les faces du cube sachant que tout les objets sont modélisés par des cubes. C'est pas pour tout de suite mais c'est le but final du moteur.
Je connais ionfastCopy: ça fonctionnent avec ldir .
Aussi ton aide ne sera pas de refus pour l'optimisation mais aussi pour les choses que je ne comprends pas faute de niveau .

La 5e droite est le plan z=0. Pour la prérotation, c'est juste que c'est immensément plus simple de faire les calculs de cliping avec les coordonnées rotationnées au lieu des coordonnées dans le monde.
Je peux pas trop d'aider pour les quaternions, ça fait trop longtemps que j'ai plus fait de math et j'aai pas trop le temps de me pencher sur la question
Au vu de ce que va devenir le moteur (un minecraft like ? ) une optimisation majeur serait déjà plutôt ne rendre que les faces potentiellement visibles du cube, et de gérer les cubes par zone : et rendre les zones en fonctions de la position.
Btw, ionfastcopy n'utilise absolument pas ldir