Углы Эйлера против кватернионов - проблемы, вызванные напряжением между внутренней памятью и представлением пользователю?

Кватернионы, возможно, являются подходящим выбором для представления внутренних вращений объектов. Они просты и эффективны для точной интерполяции и представления одной ориентации.

Однако представление кватернионов в пользовательском интерфейсе, как правило, неуместно - углы Эйлера, как правило, гораздо более знакомы пользователям, а их значения немного интуитивны и предсказуемы.

Углы Эйлера страдают от сложности на уровне кода - они требуют сохранения порядка вращения и составления практической ориентации (будь то матрица или кватернион) с использованием этого порядка и связанных углов, по меньшей мере, громоздко.

Надежные интерполяции наиболее удобно выполняются с использованием представления кватернионов - так значит ли это, что мы должны постоянно переходить между представлением Эйлера и представлением кватернионов? Возможно ли это с точки зрения производительности?

Можем ли мы сохранить ориентацию как кватернионы и преобразовать их только для отображения пользователю? Это может быть невозможно, поскольку для любой заданной ориентации имеется ровно одно кватернионное представление, но много эйлеровых представлений. Как мы выбираем "представление Эйлера, которое соответствует тому, которое первоначально определяло эту ориентацию? Это похоже на невозможную задачу - мы действительно потеряли информацию при преобразовании в кватернион.

Можно ли хранить как углы Эйлера, а затем преобразовывать в кватернионы по мере необходимости? Это, вероятно, не масштабируемо - преобразование из угла Эйлера в кватернион, интерполяция, а затем преобразование обратно может быть относительно дорогостоящим кодом.

Можно ли просто сохранить оба представления и использовать наиболее подходящие для любой ситуации? Большие затраты с точки зрения памяти (представить анимационные кривые для скелета около шестидесяти костей) и сохранение этих значений могут быть дорогими или, по крайней мере, громоздкими.

Кто-нибудь видел, использовал или хоть какое-нибудь умное решение этой проблемы? Конечно, три варианта выше не только одни? Существуют ли какие-либо другие проблемные области, подобные этому, которые были решены?

Ответ 1

Я инженер аэрокосмической промышленности; Я использую кватернионы для управления ориентацией космического корабля и навигации для перехода на три десятилетия. Вот некоторые мысли о вашей ситуации:

Выполнение любого процесса, который изменяет ориентацию с углами Эйлера, становится невозможным. Углы Эйлера страдают от особенностей - углы мгновенно меняются на 180 градусов, так как другие углы проходят через сингулярность; Углы Эйлера практически невозможно использовать для последовательных вращений. Кватернионы не страдают ни от одной из этих проблем.
Существует 12 различных возможных последовательностей поворота угла Эйлера - XYZ, XYX, XZY и т.д. Нет ни одного "простейшего" или "правильного" набора углов Эйлера. Чтобы получить набор углов Эйлера, вы должны знать, какую последовательность вращения вы используете и придерживаетесь.
Я предлагаю вам выполнить все операции хранения и вращения с кватернионами и преобразовать только кватернион в углы Эйлера, когда требуется выход. Когда вы это сделаете, вы должны определить, какую последовательность вращения Эйлера вы используете.

У меня есть алгоритмы для всех этих операций и многие другие: кватернионы к/от углов Эйлера любой последовательности вращения в/из матриц вращения (матрицы косинуса направления), положение согласования интерполяции кватернионов, скорость и т.д. в конце или в промежуточных точках, жесткую и гибкую динамику тела и кинематику с использованием кватернионов.

Пожалуйста, свяжитесь со мной, если я могу помочь [email protected]

Ответ 2

Я поклонник кватернионов. Чтобы заставить их работать, не могли бы вы пересмотреть свою презентацию для пользователя? Вместо того, чтобы приводить к вращению пользователя в виде ряда углов Эйлера в текстовой форме, вы можете вместо этого выбрать какой-либо простой 3D-объект и применить поворот кватерниона к объекту для визуального отображения вращения.

Ответ 3

Почему бы не использовать Quarternions в коде и преобразовать Q в углы, когда это необходимо для отображения?

Ответ 4

Вы можете представить поворот как ось + угол поворота, который по существу совпадает с кватернионом (до знака)

Ответ 5

Я не думаю, что имеет смысл использовать углы Эйлера внутри - вы захотите использовать кватернионы для всех своих вычислений и, как правило, не сможете позволить себе конверсии, происходящие повсюду. Что касается преобразования его обратно в углы Эйлера для пользовательского интерфейса - будет ли это так плохо, если пользователь получит только угол, эквивалентный исходному входу, но представлен по-разному? Если вы делаете правильное преобразование, вы должны получить "самые простые" углы Эйлера для любого данного кватерниона.

Ответ 6

Сколько конверсий мы говорим. Похоже, вы платите за две трансцендентные операции за конверсию, которые на современном оборудовании доступны в порядке 100 миллионов в секунду. Я бы сохранил оба, Quaternions для точности и эстетики и вращения эйлеров для сохранения информации о пользователе. Возможно, добавьте флаг, чтобы указать, какой из них является предпочтительным для любого данного объекта. Кроме того, вам нужно выполнить преобразование только один раз за каждый член. Как только вы вычислили матрицу преобразования, ее умножить-добавляет, пока вы не закончите вершины.