Euler angles vs. Quaternions - problèmes causés par la tension entre stockage interne et présentation à l'utilisateur?

Question

Les quaternions sont sans doute un choix approprié pour représenter les rotations d’objets en interne. Ils sont simples et efficaces pour interpoler et représentent une seule orientation sans ambiguïté.

Cependant, la présentation des quaternions dans l'interface utilisateur est généralement inappropriée. Les angles d'Euler sont généralement plus familiers aux utilisateurs et leurs valeurs sont un peu plus intuitives et prévisibles.

Les angles d'Euler souffrent d'une complexité au niveau du code - ils nécessitent la mémorisation d'un ordre de rotation et la composition d'une orientation pratique (matrice ou quaternion) à l'aide de cet ordre et des angles associés est pour le moins encombrante.

Les interpolations fiables sont plus facilement exécutées avec une représentation en quaternion. Cela signifie-t-il que nous devons donc convertir en permanence entre une représentation Euler et une représentation en quaternion? Est-ce faisable en termes de performance?

Peut-on stocker les orientations sous forme de quaternions et les convertir uniquement pour les afficher à l'utilisateur? Cela peut ne pas être possible car, quelle que soit l'orientation, il existe exactement une représentation quaternion mais de nombreuses représentations d'Euler. Comment pouvons-nous «choisir» la représentation d'Euler qui correspond à celle qui a défini cette orientation à l'origine? Cela semble être une tâche impossible: nous avons effectivement perdu des informations lors de la conversion en quaternion.

Pouvons-nous stocker les angles d’Euler puis les convertir en quaternions selon les besoins? Ce n'est probablement pas évolutif - la conversion d'un angle d'Euler en un quaternion, une interpolation, puis une conversion ultérieure seront probablement des codes relativement coûteux.

Pourrions-nous simplement stocker les deux représentations et utiliser la plus appropriée dans une situation donnée? Un coût élevé en termes de mémoire (imaginez les courbes d’animation pour un squelette avec une soixantaine d’os) et le maintien de ces valeurs synchronisées pourrait être coûteux, ou du moins fastidieux.

Quelqu'un a-t-il déjà vu, utilisé ou pensé une solution intelligente à ce problème? Les trois options ci-dessus ne sont sûrement pas les seules? Existe-t-il d'autres problèmes similaires à celui-ci qui ont été résolus ?

Answer 1

Je suis un ingénieur en aérospatiale; J'utilise les quaternions pour le contrôle d'attitude et la navigation des engins spatiaux depuis trois décennies. Voici quelques réflexions sur votre situation:

1. Exécuter tout type de processus qui change d'orientation avec les angles d'Euler est presque impossible. Les angles d'Euler souffrent de singularités - les angles changeront instantanément jusqu'à 180 degrés à mesure que d'autres angles franchissent la singularité; Les angles d'Euler sont pratiquement impossibles à utiliser pour les rotations séquentielles. Les quaternions ne souffrent d'aucun de ces problèmes
2. Il y a 12 différentes séquences de rotation d'angle d'Euler possibles: XYZ, XYX, XZY, etc. Il n'y a pas un "plus simple" " ou " right " ensemble d'angles d'Euler. Pour obtenir un ensemble d'angles d'Euler, vous devez connaître la séquence de rotation que vous utilisez et vous y tenir.
3. Je vous suggère d'effectuer toutes les opérations de stockage et de rotation avec les quaternions et de convertir un quaternion en angles d'Euler uniquement lorsque la sortie est requise. Pour ce faire, vous devez définir la séquence de rotation d'Euler que vous utilisez.

J'ai des algorithmes pour toutes ces opérations et bien d'autres: quaternions vers / depuis les angles d'Euler de toute séquence de rotation vers / depuis les matrices de rotation (matrices en cosinus directeur), position de correspondance d'interpolation quaternion, vitesse, etc. aux points extrêmes ou intermédiaires, dynamique du corps rigide et flexible et cinématique à l'aide de quaternions.

S'il vous plaît contactez-moi si je peux être utile à nhughes1ster@gmail.com

Answer 2

Je suis un fan de quaternions. Pour les faire fonctionner, pourriez-vous reconsidérer votre présentation à l'utilisateur? Au lieu de présenter la rotation à l'utilisateur sous la forme d'une série d'angles d'Euler sous forme de texte, vous pouvez choisir un objet 3D simple et appliquer la rotation quaternion à l'objet pour afficher visuellement la rotation en cours.

Answer 3

Pourquoi ne pas utiliser les quaternions dans le code et convertir le Q en anges lorsque cela est nécessaire pour l'affichage?

Answer 4

Vous pouvez représenter la rotation en tant qu'axe + angle de rotation, qui est essentiellement identique à celui d'un quaternion (jusqu'à un signe)

Answer 5

Je ne pense pas qu'il soit logique d'utiliser des angles d'Euler en interne. Vous voudrez utiliser des quaternions pour tous vos calculs et vous ne pourrez généralement pas vous permettre les conversions se déroulant partout. Pour ce qui est de la reconvertir en angles d'Euler pour l'interface utilisateur, ne serait-il pas si grave que l'utilisateur obtienne un angle équivalent à celui de l'entrée d'origine, mais représenté différemment? Si vous effectuez la conversion correctement, vous devriez vous retrouver avec le fichier "le plus simple". Angles d'Euler pour un quaternion donné.

Answer 6

De combien de conversions parle-t-on. On dirait que vous payez environ deux opérations transcendantales par conversion, disponibles sur le matériel moderne de l'ordre de 100 millions par seconde. Je voudrais stocker les deux, Quaternions pour la précision et l'esthétique et les rotations euler pour préserver les informations des utilisateurs. Peut-être ajouter un drapeau pour indiquer lequel est préféré pour un objet donné. De plus, il vous suffit d'effectuer la conversion une fois par membre pivoté. Une fois que vous avez calculé une matrice de transformation, sa multiplie-ajoute jusqu'à épuisement des sommets.