Почему методы матрицы трехмерного вращения обычно используют отдельный вектор и угол вместо обычных углов Эйлера?

Question

Почему методы матрицы трехмерного вращения обычно используют отдельный вектор и угол вместо обычных углов Эйлера?

Например, в glm, с учетом mat4 model и vec3 rotation вместо:

model = glm::rotate (model, rotation);

почему я должен написать:

model = glm::rotate (model, rotation.x, glm::vec3 (1, 0, 0));
model = glm::rotate (model, rotation.y, glm::vec3 (0, 1, 0));
model = glm::rotate (model, rotation.z, glm::vec3 (0, 0, 1));

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

Answer 1

Потому что Углы Эйлера вообще не очень хорошая идея. Вы получили 6 комбинации упорядочения преобразований, что означает, что использование такого API приведет к путанице.

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

• Формула вращения Родригеса
• использование перекрестного произведения для получения матрицы преобразования и использования вращения с выравниванием по инкрементальной оси

Но есть и другие, такие как использование кватернионов и т. Д.

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

Answer 2

Почему они не просто реализуют это как единый вектор вращения Эйлера, упрощая практически каждый фрагмент кода для использования библиотеки?

Потому что это «не упрощает практически каждый кусок кода, чтобы когда-либо использовать библиотеку». Углы Эйлера распространены в инструментах моделирования, учебных пособиях и коде, написанных людьми, которые плохо знакомы с графикой. Но когда серьезным графическим приложениям приходит время представлять ориентацию объекта, это обычно делается в виде самой матрицы или кватерниона. Последний из которых можно считать кодированием угла / оси вращения.

Матрицы и кватернионы могут быть составлены. Эйлер углы не могут. Кватернионы можно плавно интерполировать, что позволяет анимацию персонажей. Интерполяция нескольких углов Эйлера приводит к очень неудачным результатам. Применение осевого вращения к углам Эйлера подчиняется блокировке подвеса; применение поворотов к ориентации (матрица или кватернион) не делает. И пр.

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

Действительно, не существует ни одного набора углов Эйлера; порядок, в котором 3 осевых вращения применяются в вопросах результатов. Если вы применяете одинаковые углы в другом порядке, вы получите другой результат. А люди, которые используют углы Эйлера, обычно выбирают разные порядки углов Эйлера в зависимости от своих потребностей.

Так что наличие функции glm::rotate, которая выбирает определенный порядок Эйлера, было бы бесполезно для тех, кому нужен другой.

Answer 3

Во-первых, теоретически элегантно представлять множество вращений как множество всех единичных векторов и углов. Если вы объедините два вращения, вы получите третье вращение.

Внутренне код будет представлять повороты в виде матрицы или, возможно, кватернионов. Если это последний, то его особенно легко пройти между кватернионом и осевым углом модели.

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

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