AT
поправка дешевый в хранении
Size: a a a
2020 October 19
AT
у матриц есть преимущество в том что мы сразу знаем информацию об направлениях и скейлах, в отличии от кватернионов
AT
хотя я наверняка лезу не по теме уж простите тогда
AT
технически более дешевый вариант вычеслений это Quaternion + Vector3
https://computergraphics.stackexchange.com/a/144/5430 нет
multiply-add, transforming a vector by a quaternion is more expensive than transforming a vector by a matrix. Transforming a vector by a 3x3 matrix is 3 multiplies and 6 multiply-adds, and transforming a vector by a quaternion is two quaternion multiplies, each of which consist of 4 multiplies and 12 multiply-adds
AT
я же сказал что в хранении
AT
но для чего экономить 6 флоат?
AT
опять же при условии что мы откидываем в сторону такие вещи как искажения
MK
Если матрицы друг на друга умножать долго, то они потеряют ортогональность из-за ошибок округления
MK
Кватернион поворота просто перенормировать назад
AT
я же сказал что в хранении
там же написано, что это может превратиться в выигрыш по времени, если у тебя узкое место в коде — это заргузки из памяти
AT
только в этом случае, но это условность опускается довольно часто ибо в нынешнее время нет пней 2 или 3, сейчас даже телефоны это обычно прожевывают без особых проблем
AT
если желаете угареть по оптимизации да это хороший вариант когда пишете крайне супер оптимизированный двиг
AT
я себе могу представить ситуацию, когда какие-то анимации требуют большого количества загрузок этих кватернионов. Но вряд ли там опять же это основная проблема
AT
все зависит от направления
K
кстати, преждевременная оптимизация - это отстой
пока валгринд не начнёт показывать, что ботлнек именно в месте хранения матриц - не стоит ничего там трогать
пока валгринд не начнёт показывать, что ботлнек именно в месте хранения матриц - не стоит ничего там трогать
AT
анимации обычно грузят один раз в память или подгружают в момент требования с рассчетом на время загрузки
AT
да тут больше даже не про память, а про незакешированный доступ
AT
преждевременная оптимизация требуется только в тот момент когда ты уверен что это место требует оптимизированного решения заранее ибо опыт показывает что в этом месте ведется просадка в будущем
AT
да тут больше даже не про память, а про незакешированный доступ
а я разве что-то другое имел введу? Анимацию либо грузят заранее либо в момент востребованности, с УЧЕТОМ среднего времени на загрузку до того как пользователь может увидеть эту анимацию
AT
не знаю о чём ты, в таком случае. Что ты имеешь ввиду, когда говоришь "загрузят"? При чём здесь время на загрузку?