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