Dark Engine Viewer

[Chuzhoi]

хотел модели персонажей приделать

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

А анимация будет показываться? Или пока это совсем фантастика?

В общем, стрелки это архаика.

[off]Макс, я играю не стрелками. У меня ПКМ - вперед, M - назад, <> - вправо-влево. Остальное вокруг. Могу и WASD'ом играть (мне попадались игры, в которых управление не переназначается), но мне это не так привычно.[/off]

[Force]

Ковыряюсь тут в модельках, пока фиксил ориентацию костей друг относительно друга, выяснил одну любопытную вещь...

Я вижу исправление бага позиционирования костей в отдельной модели:



Но, по всей видимости, в DromEd'е есть некий дополнительный параметр ориентации модели, который я не учитываю, некоторые проблемные модели в миссиях так и остались кривыми:


Кто-нибудь может подсказать, что это за параметр может быть, или где он хотя бы в меню DromEd'а находится?

[nemyax]

Force
Там в модели массив матричек 3х4, и у каждого чайлда индекс в туда. Но жизнь была бы пуста, если бы вместо единичных матричек не попадались бы массивы нулей.
Трансформы вроде в системе координат родителя.

[Force]

nemyax
Матрицы разве не 3х3?
С нулями в родителе я разобрался, а вот в остальных местах - посмотрю. Надо эти бажные модели исследовать.

[nemyax]

3x3, а сразу после неё вектор трансляции.

Ну вот оно (matrixs.h):

Код Выделить Развернуть

typedef float mxs_real;

typedef struct mxs_vector {
   union {
      struct {mxs_real x,y,z;};
      mxs_real el[3];
   };
} mxs_vector;

typedef struct mxs_matrix {
   union {
      struct {mxs_real m0,m1,m2,m3,m4,m5,m6,m7,m8;};
      struct {mxs_vector vec[3];};
      mxs_real el[9];
   };
} mxs_matrix;

typedef struct mxs_trans {
   mxs_matrix mat;
   mxs_vector vec;
} mxs_trans;


Насчёт массива гоню, прямо на подобъекте хранится трансформ. В массиве там настройки лимитов вращения-скольжения. Забыл уже всё.

[Force]

Ву-ху! 

Исправлена давнишняя проблема ориентации объектов на миссии. Теперь все объекты должны четко стоять на своих местах, как задумано!
Было и стало:


Связано это было с какой-то загадочной особенностью инициализации кватернионов в библиотеке glm. В механизме считывания самих моделей всё было нормально.

Сборка будет чуть позже.

[Force]

Последние изменения

2020-01-04 00:55 MSK
+ исправлена ошибка вращения объекта сразу после его открытия, без предварительного движения мышью
+ исправлена ориентация некоторых объектов в миссиях, связанная с особенностью указания ориентации кватернионов в библиотеке GLM
+ исправлено построение AABB и OBB для объектов и их костей
+ шейдеры теперь умеют принимать на вход массивы данных
+ добавлена заготовка схемы отрисовки для дебажного вывода bounding boxes

Последняя актуальная сборка:
deviewer_build.zip 2020-01-04 00:55 MSK

Первый пост обновлен.

[nemyax]

В формате уровней используются кватернионы?

[Force]

Нет, углы Эйлера. Я просто преобразую их в кватернионы для ориентации объектов, а GLM, имея конструктор кватерниона из углов Эйлера, накладывает их в порядке x, y, z. В общем, какая-то дурацкая ситуация. Как можно правильно наложить трансформацию на объект по углам Эйлера по дефолту, когда ты не знаешь договоренности, в какой последовательности это надо делать? Короче, зачем в GLM такой конструктор? Может ты, как опытный моделлер прольешь свет? Я чего-то не понимаю?

[nemyax]

Ну скорее всего в глм дефолтный порядок углов - xyz. Ты такой эйлер создал, он так дальше и живёт.
А в движке какой используется порядок для эйлеров? Если взять не тот порядок, то само собой будет фейл. И зачем промежуточные кватернионы, если ты можешь переводить эйлеры сразу в матрицы, не накапливая ошибок.
http://www.songho.ca/opengl/gl_anglestoaxes.html

[Force]

А в движке какой используется порядок для эйлеров?

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

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

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

[nemyax]

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

[Force]

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

Да, сами модели я так и переориентирую в итоге. Но размещение их на уровне надо обрабатывать через отдельные повороты по углам Эйлера в исходной последовательности. Я подумал и пришел к выводу, что тут ничего нельзя сделать из-за того что оси другие - только исходные оси и исходные повороты. Сейчас работает, насколько я могу судить, но всё равно есть странные модели, выглядящие разобранными (Thief 2):
camera02.bin
camera03.bin
camera04.bin
но они, вроде как, не используются в игре... Но всё равно, подозрительно.

Из используемых странно выглядят:
turnew0.bin
turnew1.bin
turnew3.bin

[nemyax]

turnew0.bin

Эта состоит из одного подобъекта, там нечему разваливаться.

turnew1.bin
turnew3.bin

У этих иерархия корень-дочка-внучка, притом у turnew1.bin ориджины дочки и внучки чёрти где. Впрочем, их оси X проходят как надо для локального вращения.

[Force]

nemyax
А у тебя есть возможность открыть эту модель в каком нибудь редакторе и посмотреть, целая ли она?