Литература, уроки по OpenGL 3+

Подскажите пожалуйста литература, уроки и т.п. по OpenGL 3+.
Желательно на русском.

0

Ну вот, другое дело, по крайней мере человек не боится ответить

Сообщение от snake32 Для той же скелетной анимации (на сколько знаю в шейдерах) как раз используют кватернионы, а не углы Эйлера. Не только из-за блокировки осей, но и из-за нормальной интерполяции. Большинство приложений может и показывает юзеру-дизайнеру углы Эйлера, но это абсолютно не значит что внутри они не переводятся в кватернионы и вся работа идёт уже непосредственно с кватернионами. Углы Эйлера вроде чуть проще в понимании, чем вращение вокруг произвольной оси хотя, как по мне, если 3д-дизайнер не может представить вращение вокруг произвольной оси, то он - так себе 3д-дизайнер.

Первое. А как предъявить/дать юзеру кватернион? Какие значения должны быть показаны в диалогах и какие манипуляторы рисовать в окнах с объектами? Не видел таких UI

Второе. Вращаем объект, два ключа (keyframe): RotateY = 0 на кадре 0, RotateY = 720 на кадре 60. Все ясно, за 60 кадров объект делает 2 полных оборота. Но это с "плохими" углами Эйлера. Как это сделать с "хорошими" кватернионами? Да никак, там +/- 180, и вся любовь.

Сообщение от snake32 Не только из-за блокировки осей, но и из-за нормальной интерполяции.

Легенды. Вот чем Вам мешает "блокировка осей"? Что она Вам сделала плохого? Если "средний" поворот 90 (напр по Y), то 2 остальные (напр X и Z) взаимно компенсируют друг друга. И что с того? Интерполяция - где-то читал что с кватернионами на 2-3% точнее. Ладно, пусть на 5%, не мелочимся. Видел в приложениях опцию "интерполировать в кватернионах", заметьте - опцию, т.е. в углах вполне приемлемо. Правда в ситуации когда угол меняется резко (типа на 100 гадусов) - там да, нужны кватернионы.

Так что интерполяция - это цветочки. Углы Эйлера обладают другими подлыми свойствами. Ну это пусть Ваня расскажет, он там сейчас с ИИ подружился, для него любой вопрос - не проблема

0

Сообщение от Igor3D Второе. Вращаем объект, два ключа (keyframe): RotateY = 0 на кадре 0, RotateY = 720 на кадре 60. Все ясно, за 60 кадров объект делает 2 полных оборота. Но это с "плохими" углами Эйлера. Как это сделать с "хорошими" кватернионами? Да никак, там +/- 180, и вся любовь.

Сделать N кадров религия не позволяет?

Сообщение от Igor3D Первое. А как предъявить/дать юзеру кватернион? Какие значения должны быть показаны в диалогах и какие манипуляторы рисовать в окнах с объектами? Не видел таких UI

Тут конечно сложнее. Эйлер проще однозначно. Хватает 3 edit'ов.
Пока кроме сферы со стрелочкой в голову ничего не приходит.

Добавлено через 9 минут

Сообщение от Igor3D Интерполяция - где-то читал что с кватернионами на 2-3% точнее. Ладно, пусть на 5%, не мелочимся.

Это даже визуально видно. Но есть задачи где даже если визуально не видно результат будет не удовлетворительным.

Сообщение от Igor3D Легенды. Вот чем Вам мешает "блокировка осей"? Что она Вам сделала плохого? Если "средний" поворот 90 (напр по Y), то 2 остальные (напр X и Z) взаимно компенсируют друг друга. И что с того?

В смысле что с того?? Пользователю становится не доступно вращение. Этого не достаточно?

0

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

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

Сообщение от snake32 Только Vulkan по-идеи может эффективнее использоваться GPU, чем OpenGL.

Но надо хорошо разбираться в вопросе, знать как работает видеокарта и тд. При чем еще надо хорошо уметь писать многопоточный код грубо говоря, так как в вулкане надо самому заботиться о синхронизации кадров. Еще для каждого кадра нужен свой буфер юниформ, чтобы случайно обновлением буфера не испортить данные которые используются. Кадры тут в смысле один рисуется в задний буфер, другой показывается на экран в передний, в уроках vulkan-tutorial так вообще используется минимум 3 кадра (может и больше если железо имеет больший нижний предел) и все их нужно синхронизировать, без этого сам вулкан плюется ошибками

Добавлено через 20 минут
И к тому же тут один человек советует писать код с помощью негросети ИИ, мне кажется там ничего без ошибок не выйдет не говоря про производительность уровня OpenGL
Даже самому прилично все изучив хорошо если выйдет добиться уровня OpenGL, а для лучшего будет нетривиальная задачка.
Да и в книгах уроках все довольно упрощенно и некоторые вещи делаются в упор понятливости вместо оптимальности подхода. Например выделение буферов, у вулкана ограничено число выделений и в уроке пишется мол надо либо самому писать менеджер памяти (выделяя больше блоки и используя оффсеты при использовании памяти где нужно) либо использовать готовые сторонние либы, например vma, а так как в уроках не будет достигнут лимит, то будем выделять все напрямую.

Я уже который раз берусь за серию уроков vulkan-tutorial, хотя он и по старой версии вулкана (1.0) но сойдет (да и к тому же моя видеокарта самые свежие не поддерживает, вроде у 10 серии нету поддержки 1.4 вулкана) особенно для обучения. Пока переписываю Сишный код уроков на плюсы, так как у Вулкана появился плюсовый апи, который куда компактнее получается, вместо заполнения структур построчно просто создаешь с помощью конструктора указывая только то что нужно или вызываешь методы возвращающие что нужно а не через указатели в параметрах. Но я пока никак не могу понять основные концепции, например чтобы сделать чтото в духе OpenGL, то есть разделить служебные части (инстанс, девайс, очереди, синхронизацию и тд) от рендера объектов. Тут много что связано, например графический пайплайн (включающий в себя настройки растеризатора и кучу всего) в который внезапно входят и шейдеры и и описание вершинных данных, но при этом описание юниформ буферов туда не входит. А все драв колы происходят в коммандных буферах, где привязывается рендерпасс, пайплайн, буферы, описания юниформ и сам дравкол. И только потом в каждом кадре с кучей синхронизации для непосредственно рисования запускается командный буфер. Еще надо учитывать что свапчейн можнт протухнуть и его надо пересоздавать (например при ресайзе окна) и при его пересоздании надо пересоздавать почти все, остаются только грубо говоря буферы и немного служебных объектов, шейдеры, описания вершин и пайплайн надо пересоздавать с нуля (то есть почти всю геометрию обновлять, благо без перезагрузки вершинных данных). Не говоря уже про зависимости, что нужно для создания всего.

0

Сообщение от alecss131 Вообще шейдеры не работают с углами, им нужны матрицы. Они эффективней работают с матрицами, перемножают их между собой и с векторами (что является вершинами), переводить кватернионы в матрицы затратная задачка (хотя тут скорее про углы в матрицы точно, так как там при переводе вроде используется тригонометрия) особенно учитывая что шейдеры будут выполняться (все вычисления с нуля) для каждой вершины, да и шейдеры между кадрами ничего не интерполируют. Тут имхо лучше посчитать все на процессоре и загрузить на видеокарту уже готовый результат в виде матриц, особенно для больших мешей.

Сам лично до скелетной анимации не дошёл, когда интересовался графикой 15 лет назад. НО тогда было актуально экономить юниформ буфер. Всё таки 4 флоата заметно меньше 9 матичных для поворота. Тут ребята вроде делали и о потери производительности речи не шло. Хотя ВК тогда были по современным меркам дохлыми.

Сообщение от alecss131 Но надо хорошо разбираться в вопросе, знать как работает видеокарта и тд.

Сегодня ИИ может помочь в этом вопросе. Точного работающего готового ответа конечно от него лучше даже не ждать, но как точка старта для решений возникающих проблем вполне сгодится...

Добавлено через 9 минут

Сообщение от alecss131 Пока переписываю Сишный код уроков на плюсы

Вот я так же и пока не осилил Vulkan - начал переписывать Сишные заголовки Vulkan'a на Delphi ибо в нём программирую

0

Сообщение от snake32 НО тогда было актуально экономить юниформ буфер. Всё таки 4 флоата заметно меньше 9 матичных для поворота.

Только надо не забывать что в скелетных анимациях не только повороты, а так же перемещения и масштабы используются, то есть 4 + 3 + 3, если раздельно, либо 16 если в виде матрицы (mat4).
Допустим 100 костей, 1 матрица это 16 float или 64 байта, что будет чуть более 6кб памяти. Особенно если учесть что у видеокарт сейчас минимум по 4гб памяти, ну даже если взять 1-2, то на фоне размера модели и текстур это ничего. С другой стороны если использовать повороты, то тогда надо вычислять матрицы трансформации для каждой вершины, сейчас скелетные меши довольно тяжелые, думаю 100к полигонов вполне себе средний размер, то есть выйдет очень много однотипных расчетов, тогда как все матрицы можно заранее рассчитать в пределах одного кадра.

0

Один из самый лучших видеокурсов по OpenGL 3, который состоит из 60 уроков, на канале ThinMatrix: OpenGL 3D Game Tutorials. Уроки на Java и LWJGL, но они по сути на чистом шейдерном OpenGL и без особых проблем переписываются на любой другой язык.

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

В этих уроках используется формат Collada (.dae), который был удалён из новых версий Blender, но этот формат намного легче в понимании, чем glTF, в контексте скелетных анимаций. DAE можно парсить XML-парсером, например, библиотекой pugixml (https://github.com/zeux/pugixml) на C++, либо использовать встроенный модуль в Qt. На Python есть порт pugixml: https://pypi.org/project/pugixml/ На JavaScript, C#, Java и т.д. есть встроенные парсеры XML. Если кто-то захочет переписать код примеров на C++ и формат glTF, то можно взять библиотеку simdjson: https://github.com/simdjson/simdjson или использовать Qt, в который встроен парсер формата JSON.

OpenGL Skeletal Animation Tutorial #1: https://www.youtube.com/watch?v=f3Cr8Yx3GGA



OpenGL Skeletal Animation Tutorial #2: https://www.youtube.com/watch?v=F-kcaonjHf8



OpenGL Skeletal Animation Tutorial #3: https://www.youtube.com/watch?v=cieheqt7eqc



OpenGL Skeletal Animation Tutorial #4: https://www.youtube.com/watch?v=z0jb1OBw45I

0

Сообщение от alecss131 И к тому же тут один человек советует писать код с помощью негросети ИИ, мне кажется там ничего без ошибок не выйдет не говоря про производительность уровня OpenGL Даже самому прилично все изучив хорошо если выйдет добиться уровня OpenGL, а для лучшего будет нетривиальная задачка.

Если это про меня, то я в данной теме советовал прибегать к помощи ИИ, когда изучаешь, например, туториалы LearnOpenGL, в этом сообщении:

Сообщение от 8Observer8 Очень сильно помогают Gemini, ChatGPT, DeepSeek и т.д. в изучении чего либо. Вопросы к ИИ лучше всего задавать на английском. Можете даже, к примеру, взять какой-то непонятный абзац из туториала https://learnopengl.com/ и скопировать его в запрос к ИИ и написать "Explain me" (объясни мне) и он может более понятно объяснить. Если совсем непонятно, то можно временно переключаться на русский. Так же и с книгами можно поступать на английском - сначала спрашивать у ИИ "Explain me in English", а если и этого не хватает, то попросить объяснить на русском: "Объясни на русском" и скопировать в промпт абзац или несколько абзацев, которые нужно объяснить.

В этом сообщении я посоветовал копировать абзац или код из туториала и просить ИИ объяснить код или абзац более простыми словами. В контексте Vulkan я советовал попробовать генерировать простые примеры с помощью ИИ в другой теме в этом сообщении: Изучение vulkan

Сообщение от 8Observer8 Мы живём в эпоху ИИ. Gemini может почти любую тему новичку разжевать с заданным уровнем погружения.

Сообщение от 8Observer8 Очевидно, что в 2026 изучать надо с помощью ИИ. Мне больше нравится Gemini от Google. Любую технологию сложно изучать, как только вы копнули чуть вглубь. У каждой технологии своя специфика. У Vulkan вот такая, что сразу много кода нужно написать. Секрет в том, чтобы посвящать этому большую часть свободного времени регулярно и любить это. За одно у вас больше будет накапливаться опыта по работе с ИИ. Эти 1500 строк кода вам постепенно создаст ИИ, вы уберёте их в отдельный файл и вам не придётся их заново писать в каждом учебном тренировочном примере.

Сообщение от 8Observer8 Сообщение от graf_nen Посмотреть сообщение думаю изучить vulkan но у меня мозги плавятся когда я изучаю документацию вулкана Но это хардкор - сразу по документации изучать. Неудивительно, что плавятся мозги. Спросите у Gemini, как рисовать треугольник. Как нарисовать два треугольника разных цветов, чтобы передавать цвет каждого треугольника из главной программы. Спросите, как использовать GLM, чтобы задать координатную сетку в 2D передавать позицию, размер и угол поворота треугольников. Спросите, как превратить треугольники в квадраты и прямоугольники. Для закрепления, напишите простейшую демку игры Змейка - вы увидите, как рисовать тело змейки, еду, может добавить препятствия. Демки типа Змейка, Арканойд будут очень полезны, чтобы лучше закрепить пройденный материал. Любой непонятный код можно скопировать в Gemini и попросить его объяснить. Если не понятно, то можно сказать - объясни простыми словами. Так если регулярно с мотивацией стремиться вперёд, то будет прогресс и будут открываться новые цели. Надо учиться разбивать задачи на подзадачи и активно работать с ИИ. Потом спросите, как с помощью GLM сделать перспективную проекцию, чтобы отображать геометрические фигуры в 3D. Напишите простой парсер для загрузки треугольников из Blender, например, из формата .obj или можете даже попросить Gemini помочь разобраться, как с obj, так и с glTF. Просто спрашивайте ИИ как можно больше, чтобы он вам объяснял и самое главное - проверяйте, как работает это в коде.

Я посоветовал в той теме новичку чаще обращаться к помощи Gemini (мне показалось, что Gemini лучше в помощи в программировании, чем ChatGPT и DeepSeek). Простейшие учебные примеры он может сгенерировать и может объяснить, что делает указанная строчка кода и или блок кода. Конечно, если его попросить сделать пример скелетной анимации, то он даже на OpenGL сделает это криво, либо вообще код не запустится. Маленькие учебные примеры он хорошо делает. Конкретно на Vulkan не пробовал, но сейчас время от времени изучаю WebGPU (на JS) и WebGPU-Native на Си и C++ (с окном на SDL3), а WebGPU - это Vulkan для веб. На WebGPU код получается короче в разы, но он похож на Vulkan. Простые учебные примеры Gemini пишет хорошо. Да по началу примеры чаще всего не работают, но если в процессе учиться правильно подталкивать его в нужном направлении, то ИИ сильно экономит время и мотивирует.

0

Раз уже в теме началось активное обсуждение отношения к Vulkan, то я выскажу свою позицию. Я начал было изучать Vulkan в этом году, но потом быстро понял, что лично мне он не подходит, потому что у меня в приоритете веб-технологии (JavaScript, Bootstrap/HTML5/CSS и C/C++/WebAssembly), чтобы можно было ещё и EXE и APK собирать из той же кодовой базы, а Vulkan, в отличие от OpenGL ES 2.0/3.0 (WebGL 1.0/2.0), не умеет собираться в Wasm (WebAssembly) и запускаться в браузере. Прямой современный аналог Vulkan в веб - это WebGPU. То есть я узнал, что WebGPU есть на Си, C++, SDL3 для Desktop, Android и Wasm, поэтому переключился на WebGPU. Но есть большая проблема для меня, что WebGPU не запускается в браузере на моём Redmi 10 (2021 года), хотя там Vulkan есть, но Vulkan на нём не достаточно новой версии, чтобы запускался WebGPU. Поэтому я решил, что для Android надо использовать WebGL 2.0 (JavaScript) и OpenGL ES 3.0 (SDL3), а для Desktop практиковаться с WebGPU (JavaScript, SDL3). У меня на стационарном ПК в браузере WebGPU работает без проблем, как и при сборке в EXE с SDL3-окном, так как ПК поддерживает Vulkan достаточной версии. WebGPU использует Vulkan.

P.S. Только, пожалуйста, не пишите опять бред, что браузер не предназначен для рисования компьютерной графики. Браузеры не только предназначены для отображения текста и картинок (хотя и то и другое, это тоже компьютерная графика), но ещё умеют проигрывать 3D-звук, показывать видео и даже есть люди, которые стабильно зарабатывают на браузерных играх (что более реально в РФ, чем продажи на Steam из РФ) и на неигровой 3D-графике в браузерах, типа продажи 3D-моделей, которые можно покрутить в браузере перед покупкой или для интерактивной рекламы. В этом году еженедельное скачивание Three.js приблизилось к 7 миллионам и растёт стремительно: https://www.npmjs.com/package/three



Three.js уже поддерживает WebGPU и активно развивается в этом направлении.

0

Сообщение от snake32 Сделать N кадров религия не позволяет?

Ну, покадрово многое прощается, но интерполяция keyframe'ов - вещь/фича фундаментальная, заявлять что она не поддерживается - себе дороже. И если все покадрово - зачем хвалить интерполяцию кватернионов?

Сообщение от snake32 В смысле что с того?? Пользователю становится не доступно вращение. Этого не достаточно?

Чего это недоступно? Давайте пожуем

Вот есть 3 угла поворота, порядок поворотов XYZ (их (порядков) много, может быть напр ZXZ). Пусть поворот Y = 90 (или -90). После поворота по Y "новая" ось Z совпадает (точнее коллинеарна) со "старой" осью X. В результате повороты X и Z вращают вокруг одной и той же оси. Но это совсем не значит что объект как-то "застрял", вращение недоступно и все такое. Просто минус одна степень свободы. Поворота Z можно добиться поворотом X и наоборот. Объект нормально реагирует на все 3 поворота, интерактивность никак не нарушается. И вообще 2 угла достаточны для любого желаемого поворота.

Сообщение от snake32 Это даже визуально видно. Но есть задачи где даже если визуально не видно результат будет не удовлетворительным.

А я вот как-то визуально не видел В конце-концов никто не доказал что "вращение по кратчайшей дуге" - именно то что нужно юзеру

0

snake32 верно говорит, что "большинство приложений может и показывает юзеру-дизайнеру углы Эйлера, но это абсолютно не значит что внутри они не переводятся в кватернионы и вся работа идёт уже непосредственно с кватернионами."

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

Сообщение от Igor3D А как предъявить/дать юзеру кватернион? Какие значения должны быть показаны в диалогах и какие манипуляторы рисовать в окнах с объектами? Не видел таких UI

В Unity в режиме Normal тоже в инспекторе показываются углы Эйлеры. Однако, если нажать на три точки и выбрать режим Debug, то для вращения появится кватернион.



Как видно, если в углах Эйлера у нас было (0°, 90°, 0°), то при переходе на кватернион будет (0, sqrt(2)/2, 0, sqrt(2)/2).

В Godot тоже можно переключаться между режимами. Там даже три режима: Euler, Quaternion и Basis



А вот в UE ничего похожего не встречал (но может я не знаю, где искать), там только углы Эйлера.

Но разумеется через код можно работать с кватернионами на любом движке. Я выше писал именно про инспекторы.

В Blender тоже можно переключаться между углами Эйлера и кватернионом.

0

Сообщение от 8Observer8 В этом курсе есть 4 урока по скелетной анимации. Интерполяция позиций костей и кватернионов между ключевыми кадрами анимации происходит в главной программе, а в шейдер передаётся массив матриц перед рисованием модели, который хранит в себе слепок позы для кадра.

Видео не смотрел (возня с VPN), но верю что хорошее. Вот только.. что с того? Да, освоили, узнали много нового (не все конечно). Теперь умеем загружать и проигрывать анимации char'ов. Дело хорошее, но ведь любое нормальное 3D приложение умеет это делать. Зачем надо было изучать и писать/переписывать не такой уж малый код? Только чтобы повторить все что легко сделать "в 3D редакторе"? Может были мысли связать это с (чудесным) вебом? Ну вряд ли удастся завлечь юзверя парой чмошных char'ов. За последние N лет никакого прогресса не видно, тычутся в нос тьюториалы, а зачем? Давайте все выучим основы CA? Так она не всем нужна/интересна. А кому нужна - хочет большего чем основы 30-летней давности. Выходит ни то ни се

Добавлено через 24 минуты

Сообщение от Royal_X С этими углами Эйлера одни проблемы - лаганутые интерполяции, gimbal lock, погрешности, медленные вычисления, сбои физики и пр.

Да (водка зло), но от них (углов) никто не отказался

Хорошо, вот задачка которая кажется ну совсем простой. В процессе симуляции (всем лежать, работает движок физики) на каждом шаге для движущихся объектов считаются новые матрицы трансформации. Необходимо преобразовать каждую в стандартные данные: позиция + 3 угла поворота. Только просьба без глупостей: не надо рассказывать что есть ф-ция(и) для перевода матрицы поворота в углы. Это всем известно, и ф-ция давно найдена, и работает она верно, но вот.. есть подводные камни. Какие?

0

Igor3D, углы Эйлера из матрицы на каждом шаге это плохой подход. Правильное решение - хранить состояние в кватернионах и конвертировать в углы только для вывода.
На каждом шаге вместо матрицы трансформации (матрица поворота + позиция) советую использовать кватернион + позиция.
Матрицу трансформации, если она нужна для прорисовки, можно получить потом очень просто из кватерниона и позиции.

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

0

Сообщение от Royal_X Igor3D, углы Эйлера из матрицы на каждом шаге это плохой подход. Правильное решение - хранить состояние в кватернионах и конвертировать в углы только для вывода. Вместо матрицы трансформации (матрица поворота + позиция) советую использовать кватернион + позиция.

Ну я движку не указчик в чем хранить, но перевод из матрицы вращения в кватернион - без проблем.

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

Не угадали. И не надо напускать туману с "сингулярностью" Первая проблема очевидна и обсуждалась выше

0

Сообщение от Igor3D порядок поворотов XYZ (их (порядков) много, может быть напр ZXZ)

вот это мне и не нравится, что у каждого движка/продукта свой порядок

Например, в Unity в описании функции Transform.eulerAngles сказано:

Euler angles can represent a three dimensional rotation by performing three separate rotations around individual axes. In Unity these rotations are performed around the Z axis, the X axis, and the Y axis, in that order.

То есть, в Unity используется порядок ZXY.

Допустим наши углы Эйлера это







Поскольку порядок ZXY, то матрицы должны перемножаться в обратном порядке



Получается такая матрица:



Тем не менее, Unity предупреждает

When using the .eulerAngles property to set a rotation, it is important to understand that although you are providing X, Y, and Z rotation values to describe your rotation, those values are not stored in the rotation. Instead, the X, Y & Z values are converted to the Quaternion's internal format.

Матрица поворота обычно нужна для прорисовки, шейдерам. Но вот для получения кватерниона из углов Эйлера необязательно создавать эту матрицу , можно сразу получить этот кватернион из углов Эйлера.









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

0

Сообщение от Royal_X в Unity используется порядок ZXY.

По моим наблюдениям ZXY - самый "ходовой" во многих приложениях

Сообщение от Royal_X вот это мне и не нравится, что у каждого движка/продукта свой порядок

Движок не использует углы, в основном матрицы, хотя в расчетах видел и кватернионы.

Сообщение от Royal_X Матрица поворота обычно нужна для прорисовки, шейдерам. Но вот для получения кватерниона из углов Эйлера необязательно создавать эту матрицу, можно сразу получить этот кватернион из углов Эйлера.

Наверно можно, строить из себя математика не стану. Но наша задача - получать углы из матриц движка. Первый (подводный) камень: нужно натягивать "непринципиальные" значения. Как Вы знаете, тригонометрия возвращает "принципиальные" значения угла, от -180 до +180 (только в радианах). Напр на соседних кадрах получены

RotateY = 179 // frame 1
RotateY = -179 // frame2

В анимации надо сохранить
RotateY = 179 // frame 1
RotateY = 181 // frame2

Следующий камень? (он тоже упоминался выше)

0

Сообщение от Igor3D от -180 до +180

даже если в градусах, пишешь лисапед для нормализации

Теперь NormalizeAngle(-181) будет 179, а NormalizeAngle(181) будет -179

0

Сообщение от Igor3D Ну, покадрово многое прощается, но интерполяция keyframe'ов - вещь/фича фундаментальная, заявлять что она не поддерживается - себе дороже. И если все покадрово - зачем хвалить интерполяцию кватернионов

Юзеру не обязательно видеть все эти кадры. Можем делать это скрытно. Многое в программировании делается скрытно от юзера. Непонятно зачем я вам это объясняю

Сообщение от Igor3D Просто минус одна степень свободы.

Не баг а фича

Добавлено через 1 минуту

Сообщение от Igor3D В конце-концов никто не доказал что "вращение по кратчайшей дуге" - именно то что нужно юзеру

Хорошо что обратное доказано

0

Сообщение от Royal_X даже если в градусах, пишешь лисапед для нормализации

Для плавной анимации нужно так добавить/отнять 360 чтобы новое значение угла было как можно ближе к предыдущему. При этом возможны большие значения угла (объект может делать много оборотов). С этим все ясно, размазывать не стоит

Еще раз напомню: углов нет, цель их получить (из матриц движка), причем такие углы что пригодны для интерполяции

Сообщение от Igor3D Следующий камень?

Да, видел формулы рисуете - это хорошо, скоро понадобится

0

Сообщение от alecss131 Но я пока никак не могу понять основные концепции, например чтобы сделать чтото в духе OpenGL, то есть разделить служебные части (инстанс, девайс, очереди, синхронизацию и тд) от рендера объектов

Вам надо декомпозировать вулкан-приложение, создав программные объекты-обёртки.
1) Инициализация контекста: инстанс, физический + логический девайс, очередь (2 из туториала выкиньте, Вам 1 нужна, для работы с графикой)
2) Представление: сурфейс, свапчейн с VkImage + VkImageView. Сюда относится и функционал, отвечающий за пересоздание свапчейна при изменении геометрии окна. "Минимум 3 VkImage" Вы написали - это не так, в большинстве случаев хватит двух.
3) Создание разделяемых ресурсов: шейдеры, дескрипторы, текстуры, пул комманд буфферов, VkBuffers etc. Имеет смысл создать менеджер ресурсов, который будет следить за их жизненным циклом и уничтожать их в корректном порядке. "Разделяемый ресурс" - я подразумеваю, что, например, можно использовать один и тот же вершинный шейдерный модуль в нескольких пайплайнах (и с разными фрагментными, и незачем несколько раз пересоздавать один и тот же ресурс)
4) Пайплайны. Это то место, где Вы, цитата выше, не можете отделить рендер, но тут всё проще. Во-первых, выкиньте рендерпассы с фреймбуферами, это в вулкане 1.3+ уже лет 5 как не имеет смысла: https://lesleylai.info/en/vk-k... rendering/
Во-вторых, на каждую рисуемую сущность создаётся свой пайплайн. Соответственно, создаёте 2 класса: обёртка для пайплайна и гибкий класс для настройки его состояния, с соответствующими методами на каждый этап пайплайна. Пересоздавать пайплайны, внезапно, необязательно при изменении размеров окна, это лишь рекомендуется, как и запись комманд буферов каждый кадр - они дёшевы (но, конечно, никто не запрещает Вам оптимизировать).
5) Менеджер памяти: он нужен, конечно, (тот самый упомянутый Вами vma вполне подойдёт), но в контексте обучения, когда Вы не пишете условный скайрим, оно пока что ни к чему, это первое усложнение, в которое Вы не захотите вникать
6) Второй сложный момент - это синхронизация, увы, его не обойти. Вулкан весь асинхронен, и на каждый чих нужно расставлять семафоры с фенсами. Для меня лично это самое сложное было (и есть) в нём, необходимо писать собственную стейт машину, если не хотите разбирать тонны варнингов из слоёв валидации.

В общем-то, вот и весь скелет типичного вулкан приложения

0

Igor3D, для интерполяции углы Эйлера не очень подходят. Нужно использовать кватернионы.
Кроме того, вместо обычной линейной интерполяции (LERP), советую использовать SLERP (сферическую линейную интерполяцию): т.е. когда 3d повороты представляются как кватернионы на абстрактной трехмерной сфере. Трехмерная сфера это сфера в 4D.
Как выше было отмечено, игровые движки хранят повороты в виде кватернионов (даже когда пользователь вводит углы Эйлера), что и нужно для SLERP.
Таким образом, первая задача это получить кватернион.
Формулу для получения кватерниона из углов Эйлера я написал выше.

То, про что я пишу, уже реализовано во многих движках. Например, в Unity есть функция Quaternion.Slerp, которая на вход получает два кватерниона и параметр интерполяции, а возвращает интерполированный кватернион.
Если используешь игровой движок, то никаких проблем с анимациями быть не должно, поскольку все функции есть в API движка, ничего даже писать не нужно.
Если же пишешь без использования api игрового движка и этих функций у тебя нет, то значит придется самому реализовать все эти вспомогательные функции для работы с кватернионами.

0