Les caméras 3D à base de Quaternion doivent-elles accumuler des angles de Quaternions ou d'Euler?

Question

J'ai donc écrit une caméra 3D à base de Quaternion destinée aux nouveaux programmeurs, de sorte qu'il leur est très facile de s'intégrer et de commencer à l'utiliser.

Pendant que je le développais, au début, je prenais l'entrée de l'utilisateur sous forme d'angles d'Euler, puis je générais un Quaternion basé sur l'entrée de cette image. Je voudrais ensuite prendre le Quaternion de la caméra et le multiplier par celui que nous avons généré pour l'entrée, et en théorie, cela devrait simplement ajouter la rotation d'entrée à l'état actuel de la rotation de la caméra, et tout serait gros et heureux. Appelons cela: Accumulation de quaternions, car nous enregistrons et ajoutons uniquement des quaternions.

Mais j'ai remarqué qu'il y avait un problème avec cette méthode. Plus je l’utilisais, même si je ne tournais que sur un seul angle d’Euler, disons Yaw, qu’il commencerait, après certaines itérations, à se fondre dans un autre, dit Pitch. C'était léger, mais assez inacceptable.

J'ai donc fait quelques recherches et trouvé un article affirmant qu'il valait mieux accumuler les angles d'Euler. La caméra enregistre sa rotation actuelle sous forme d'angles d'Euler. Une entrée leur est simplement ajoutée à chaque image. Ensuite, je génère un quaternion à chaque image, qui est à son tour utilisée pour générer ma matrice de rotation. Et cela a résolu le problème de la rotation des saignements dans des axes incorrects.

Les membres de Stackoverflow ont-ils un aperçu de ce problème? Est-ce une bonne façon de faire les choses?

Answer 1

La multiplication des quaternions va souffrir de l'accumulation de problèmes d'arrondi en virgule flottante (même des angles simples comme 45 degrés ne seront pas exacts). C'est un excellent moyen de composer des rotations, mais la précision de chacun de vos composants de quaternion va se détériorer avec le temps. Le fond perdu est un effet secondaire, mais visuellement pire, votre quaternion pourrait commencer à incorporer un facteur d'échelle. Pour le récupérer, il vous faudrait dans tous les cas renormaliser aux angles d'Euler. Un angle d'Euler en virgule fixe ne va pas accumuler les arrondis.

Le recalcul du quaternion par image est minime. Je ne prendrais pas la peine d'essayer de l'optimiser. Vous pourriez probablement permettre à quelques quaternions de s’accumuler avant de procéder à une nouvelle normalisation, mais cela ne vaut vraiment pas la peine.

Answer 2

L’accumulation est un processus inexact. Accumuler de nombreuses rotations incrémentielles accumulera des erreurs d'arrondi, que vous le fassiez avec des quaternions ou des matrices.

J'imagine quelque chose comme ceci: vous avez votre code opérationnel, mais vous avez remarqué qu'après un certain temps de navigation votre caméra filait de manière ennuyeuse - violant un invariant auquel vous n'aviez pas pensé à l'avance. En réalité, vous vous êtes rendu compte que vous ne voulez pas accumuler des rotations; au lieu de cela, vous voulez faire autre chose.

Vous pouvez considérer cela comme davantage un problème de conception d'interface qu'un problème de précision numérique. En gros, les gens s’attendent à ce que la caméra navigue en fonction de la hauteur, du tangage et du roulis. Le choix de contrôler et de représenter les angles directement permet d’éviter beaucoup de problèmes.

Le problème, c’est que les quaterions semblent être devenues superflues (du moins pour cet usage particulier). Vous voulez toujours les quaternions, cependant - interpoler avec les angles bruts de tangage / lacet / roulis peut être moche. Encore une fois, c’est une question de design d’interface: vous devez déterminer où vous aurez besoin des quaternions et comment les insérer et les sortir ...

Answer 3

J'ai vu les deux se disputer. Je pense que la vraie question à laquelle vous devrez faire face est la flexibilité de votre système de caméra sur toute la ligne; Le mouvement de lacet de l'OMI est généralement plus intéressant dans une vue à la troisième personne (car vous allez effectuer une rotation autour de l'axe vertical du personnage). Bien que vous puissiez sans doute "Yaw", à la première personne également, je ne suis pas sûr que ce soit vraiment la même chose.

Cependant, je pense que c’est un peu un gaspillage de recalculer vos quaternions par image. Peut-être serait-il préférable de stocker les derniers quaternions et de les marquer comme sales si votre cadre reçoit des données?