Должны ли кватернионы 3D-камеры накапливать кватернионы или углы Эйлера?
Итак, я написал 3D-камеру на основе Quaternion, ориентированную на новых программистов, поэтому им очень легко интегрироваться и начать использовать.
Пока я его разрабатывал, сначала я принимал пользовательский ввод как углы Эйлера, а затем генерировал кватернион, основанный на входе для этого кадра. Затем я возьму Camera Quaternion и умножу его на тот, который мы сгенерировали для ввода, и теоретически это должно просто добавить входное вращение к текущему состоянию вращения камеры, и все будет жирным и счастливым. Давайте назовем это: Накопление кватернионов, потому что мы сохраняем и добавляем только кватернионы.
Но я заметил, что с этим методом возникла проблема. Чем больше я использовал его, даже если бы я вращался только на одном уголке Эйлера, скажем, Yaw, то по некоторым итерациям он начнет кровоточить в другой, скажем, Pitch. Это было незначительно, но довольно неприемлемо.
Итак, я сделал еще несколько исследований и нашел статью, в которой говорится, что лучше накапливать углы Эйлера, поэтому камера сохраняет его текущее вращение как углы Эйлера, а вход просто добавляется к каждому кадру. Затем я генерирую из них кватернион каждый кадр, который, в свою очередь, используется для генерации моей матрицы вращения. И это фиксировало проблему кровотока вращения в неправильные оси.
Итак, есть ли у каких-либо членов Stackoverflow какое-либо понимание этой проблемы? Это правильный способ сделать что-то?
Ответы
Ответ 1
Умножение кватернионов будет страдать от накопления вопросов округления с плавающей точкой (даже простые углы, такие как 45 градусов, не будут точными). Это отличный способ для сложных поворотов, но точность каждого из ваших компонентов кватерниона будет снижаться с течением времени. Проникновение - это один побочный эффект, визуально худший, хотя ваш кватернион может начать включать масштабный коэффициент - чтобы восстановить это, вам придется перенести обратно на углы Эйлера в любом случае. Угол Эйлера с фиксированной точкой не собирается накапливать округление.
Пересчет кватерниона за кадр минимален. Я бы не стал пытаться его оптимизировать. Вероятно, вы могли бы позволить нескольким кватернионам накапливаться, прежде чем перенормировать, чтобы вернуть точность, но это действительно не стоит усилий.
Ответ 2
Накопление - это неточный процесс. Накопление большого количества инкрементных оборотов будет накапливать ошибку округления, выполняете ли вы это с помощью кватернионов или матриц.
Я представляю себе что-то вроде этого: вы заработали свой код, но заметили, что после некоторой навигации, которую ваша камера трещала из-за досады, - нарушая инвариант, о котором вы не задумывались заранее. Эффективно, вы поняли, что не хотите накапливать вращения; вместо этого вы хотите сделать что-то еще.
Вы можете рассматривать это как проблему дизайна интерфейса, чем проблему с числовой точностью. В принципе, люди ожидают, что камера будет перемещаться в соответствии с шагом, рыскангом и рулоном, поэтому выбор управления и представления углов напрямую может избежать множества проблем.
Облом здесь состоит в том, что кватеры кажутся излишними (для этого конкретного использования, по крайней мере). Вы по-прежнему хотите кватернионов, хотя интерполирование с помощью углов наклона/угла наклона/поворота может быть уродливым. Опять же, это вопрос дизайна интерфейса: вам нужно выяснить, где вам понадобятся кватернионы, и как их вставлять и выходить...
Ответ 3
Я видел, как оба спорили. Я думаю, что реальный вопрос, с которым вам придется иметь дело, - это гибкость в вашей системе камер по линии; IMO-рыскание обычно более интересно в представлении третьего лица (потому что вы собираетесь вращаться вокруг вертикальной оси символа). Хотя вы можете, возможно, "рыскать" вокруг вертикали в представлении от первого лица, я не уверен, что это действительно то же самое.
Однако, я считаю, что это пустая трата, чтобы пересчитать ваши кватернионы за кадр. Возможно, было бы лучше сохранить последние кватернионы и пометить их грязными, если ваш кадр получит вход?
