Quaternion + Position vs Matrix 4x4

Намедни просматривал код своего мега прожэкта, и на глаза попался фрагмент, где происходит преобразование анимации кости (анимация хранится в Quat + pos) в локальный объект трансформации (хранящийся в виде матрицы), далее идет расчёт глобальной трансформации (в матрицах) и преобразования обратно в кватернион и позицию и отправка сего чуда в шейдер. Посмотрел на всё это ... и подумал об одной заманчивой идее, а что если во всём проекте отказаться от матриц, в принципе, как от класса, а хранить всё и всегда в Quat + pos, и рендерить вершины тоже через них в шейдерах. Подумал ... и увидел ... яркое небо, и солнце встающее над горизонтом, и ощутил чувство гармонии и единения с интеллектом. Но как всё хорошее, Щастье моё было не долгим - поговорив с 2мя людьми убедил себя и их, что идея бредовая, но все-таки не даёт она покоя мне.

Smile

ПЫСЫ: Если кто встречал материал на данную тему скинте плиз, первый заброс в гугл ничего не дал.

ПЫПЫСЫ: Да я знаю что меня посещают иногда бредовые идеи.

Последняя правка: вс, 13/11/2011 - 02:02
Submitted by Relyer on

Комментарии

Идея бредовая просто потому что в паре QP отсутствует scale, т.е. нужно всё-таки QPS. Отказаться во всём проекте от матриц не получится потому, что время от времени нужны всякие обратные матрицы и т.п.

Плюс вычисления с кватернионами в щейдерах -- какие-никакие а дополнительные тормоза.

У Грегори ("Game Engine Architecture") было про всякое такое.

Submitted by BLK Dragon on

Про scale понятно, просто я даже и не помню где его пользовал впоследний раз, для эффектов разве что. Но для них, можно протянуть отдельно параметр в шейдер. Потом по поводу тормозов не уверен что намного больше их будет, видовое преобразовани тоже на кватернионах, вопрос с проекцией но нада думать, да и вершин в принципе не много по сравнению с количеством пикселей на экране, хотя тоже спорный момент. Обратное преобразование из кватерниона и позиции проще получить чем из матрицы, хотя если обратную матрицу считать для афинного преобразования (а если учесть, что только pos и rot, и контролить положительную определённость), а не тупо влоб, то тоже спорный момент.

ПЫСЫ: Пойду выкачаю книжку.

Submitted by Relyer on

Вот пример реальной задачи с матричной математикой: повернуть кость скелета так, чтобы она смотрела в заданную точку в мировом пространстве.

Что-то очень сомнительно, что получиться на одних кватернионах+смещениях вычислять такие вещи.

Scale опять же нужен, причём non-uniform -- для статической геометрии.

Submitted by BLK Dragon on

Если брать грубо то мы используем 2 вида матричных оперций.

T=M*N и T=T-1 c их помощью можно решить задачу описаную выше.

На самом деле всё что мы меняем это представление матриц раньше оно было float[16] щас Quat + pos

T[Qt; Pt] = M*N[Qm+Qn; Pm + Pn*Qm]

T[Qt; Pt] = T-1[Qt-1; Pt*Qt-1]

Писалось из головы, так что может не совсем точно, но гдето рядом.

Submitted by Relyer on

Эм. К чему этот цирк? Операций что ли меньше? А если scale добавить?

Т.е. вот к примеру на позапрошлом PSP-проекте я вообще не замечал никаких проблем с памятью/скоростью из-за матричных операций. В смысле переход на SQP ничего не улучшил бы, только гемороя добавил бы.

Submitted by BLK Dragon on

Да вопрос не в скорости, а больше в удобстве использования. большинство кода с которым имеет дело программист (физика анимация ai рендер скелета ...) напичкано QuatToMat MatToQuat итп фигнёй. Вот и задумался над этим вопросом.

Biggrin да и подискутировать на абстрактную тему мозг расслабить тоже неплохо.

Submitted by Relyer on

По-моему , проблема слишком мелкая чтобы морочится. Где-то нужны SQP (анимация, физика), где-то матрицы. Не думаю что весь остальной код выглядит настолько красиво, что богомерзкие Quat2Matrix портят всю картину Smile

Submitted by BLK Dragon on
Идея перевести все на кватернионы + позиция + униформ скейл (vec4f + vec3f + float) далеко не бредовая. Просто мы уже по-привычке стали ограничено мыслить (т.е. в рамках матриц). Недавно я наткнулся на подобную координальную идею (How to skip matrices in the graphics pipeline at all. Choose quaternions!).Причем человек явно приводит плюсы своей реализации, хотя есть и очевидные минусы.

http://code.google.com/p/kri/wiki/Quaternions

А насчет твоего случая не знаю в чем плюсы конвертация quat -> mat -> quat. Если операция перевод из кватерниона еще сносная, всмысле без квадратных корней, то обратная очень тяжелая (корни, условия, деления ... ). Или может у тебя какие-то особенные условия?
Я конечно понимаю, что отказываться от кватернионов с их сферической интерполяцией не хочеться, но имхо лучше хранить всю анимацию в quat + pos, затем после очередной интерполяции кадров анимации, переводить все в mat4f и дальнейшие дествия все проводить в матричном виде и отсылать в шейдер тоже в виде матриц, можно ввиде mat4x3 (всего лишь на треть больше чем связка quat + pos, и в шейдере умножение на матрцы, особенно на стром железе имхо лучше будет, т.к. они любят векторизацию (новому по-барабану т.к. там скалярные ALU), чего не скажешь об кватернионах).С этим подходом должны вроде как еще хорошо дружить такие этапы в движке как физика и инверсная кинематика.

P.S. Это обсуждение сферической проблемы в вакууме:)

Submitted by BronX on

А какую задачу собственно решаем?

Память? если делать правильно со всякими align и проч. не сильно выигрываете

Скорость? хм - не сказал бы, особенно учитывая что операции с матрицами идеально simd-ятся а вот с кватернионами совсем нет

Читаемость кода? опять же - зависит.

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

Submitted by discouraged_one (не проверено) on
Quote:
BronX писал(а):
А насчет твоего случая ...
Я как раз и предложил - перевести все на кватернионы + позиция + униформ скейл, просто видимо ты не внимательно прочитал ветку.
Submitted by Relyer on
Quote:
discouraged_one писал(а):
А какую задачу собственно решаем?
Никакую, просто идею, заодно посмотреть насколько живая =)
Submitted by Relyer on

GameDev.by