Углы Эйлера против кватернионов-проблемы, вызванные напряжением между внутренним хранилищем и представлением пользователю?
кватернионы, возможно, являются подходящим выбором для представления внутренних вращений объектов. Они просты и эффективны для интерполяции и однозначного представления одной ориентации.
однако представление кватернионов в пользовательском интерфейсе обычно неуместно - углы Эйлера, как правило, гораздо более знакомы пользователям, и их значения немного более интуитивны и предсказуемы.
углы Эйлера страдают от сложности на уровне кода - они требуют, чтобы порядок вращения сохранялся, и составление практической ориентации (будь то матрица или кватернион) с использованием этого порядка и связанных углов является громоздким, если не сказать больше.
надежные интерполяции наиболее удобно выполняются с использованием представления кватернионов-значит ли это, что мы должны постоянно преобразовывать между представлением Эйлера и представлением кватернионов? Возможно ли это с точки зрения эффективности?
можем ли мы хранить ориентации как кватернионы и конвертировать их только для отображения пользователю? Это может быть невозможно, потому что для любой заданной ориентации существует ровно одно представление кватерниона, но много представлений Эйлера. Как мы "выбираем" представление Эйлера, соответствующее тому, которое изначально определяло эту ориентацию? Это кажется невозможной задачей - мы фактически потеряли информацию при преобразовании в кватернион.
можем ли мы Сохранить как углы Эйлера, а затем преобразовать в кватернионы как нужна? Это, вероятно, не масштабируемо - преобразование из угла Эйлера в кватернион, интерполяция, а затем преобразование обратно, вероятно, будет относительно дорогим кодом.
можем ли мы просто сохранить оба представления и использовать наиболее подходящие для любой данной ситуации? Большая стоимость с точки зрения памяти (представьте себе анимационные кривые для скелета с примерно шестьюдесятью костями) и сохранение этих значений синхронизированными может быть дорогостоящим или, по крайней мере, громоздким.
кто-нибудь видели, использовали или хотя бы какое-то умное решение этой проблемы? Конечно, три варианта выше не только одни? Есть ли другие проблемные Домены, подобные этому, что есть решена?
6 ответов
Я аэрокосмический инженер; я использую кватернионы для управления ориентацией и навигации космических аппаратов в течение трех десятилетий. Вот некоторые мысли о вашей ситуации:
- выполнение любого процесса, который изменяет ориентацию с углами Эйлера, граничит с невозможным. Углы Эйлера страдают от особенностей-углы будут мгновенно меняться до 180 градусов, поскольку другие углы проходят через особенность; углы Эйлера практически невозможно использовать для последовательных вращений. Кватернионы не страдают ни от одной из этих проблем
- существует 12 различных возможных последовательностей вращения угла Эйлера-XYZ, XYX, XZY и т. д. Нет ни одного "простейшего" или "правильного" набора углов Эйлера. Чтобы получить набор углов Эйлера, вы должны знать, какую последовательность вращения вы используете, и придерживаться ее.
- Я предлагаю вам выполнить все операции хранения и вращения с кватернионами и только преобразовать кватернион в углы Эйлера, когда выход требуемый. При этом необходимо определить, какую последовательность вращения Эйлера вы используете.
У меня есть алгоритмы для всех этих операций и многое другое: кватернионы к/от углов Эйлера любой последовательности вращения к/от матриц вращения (косинусные матрицы направления), интерполяция кватернионов, соответствующая позиция, скорость и т. д. в конечных или промежуточных точках жесткая и гибкая динамика тела и кинематика с использованием кватернионов.
пожалуйста свяжитесь я если я могу быть помощь в nhughes1ster@gmail.com
Я поклонник кватернионов. Чтобы заставить их работать, не могли бы вы пересмотреть свою презентацию пользователю? Вместо того, чтобы представлять вращение пользователю в виде серии углов Эйлера в текстовой форме, вы можете вместо этого выбрать какой-то простой 3D-объект и применить вращение кватерниона к объекту для визуального отображения вращения.
Почему бы не использовать кватернионы в коде и преобразования Q в углы, когда это необходимо для отображения ?
вы можете представить вращение как ось + угол поворота, который по существу совпадает с кватернионом (до знака)
Я не думаю, что имеет смысл использовать углы Эйлера внутри-вы захотите использовать кватернионы для всех своих вычислений и обычно не сможете позволить себе преобразования, происходящие повсюду. Что касается преобразования его обратно в углы Эйлера для пользовательского интерфейса - было бы так плохо, если бы пользователь получал только угол, эквивалентный исходному входу, но представленный по-другому? Если вы сделаете преобразование правильно, вы должны получить "простейшие" углы Эйлера для любого заданного кватернион.
сколько конверсий мы говорим. Похоже, вы платите за две трансцендентальные операции за конвертацию, которые на современном оборудовании доступны порядка 100 миллионов в секунду. Я бы сохранил оба, кватернионы для точности и эстетики и вращения Эйлера для сохранения информации о пользователе. Возможно, добавьте флаг, чтобы указать, что предпочтительнее для любого данного объекта. Кроме того, вам нужно только выполнить преобразование раз в поворачивается члена. Однажды вы вычислили матрицу преобразования, ее умножение-сложение, пока у вас не закончатся вершины.