Войти
ПрограммированиеФорумОбщее

Asset pipeline - CResource vs CAsset (2 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 Следующая »
#15
17:20, 4 фев. 2006

Объясните человеческим языком суть проблемы, кто нибудь?

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


#16
20:58, 4 фев. 2006

_Winnie

>Что неизвестно, будет построено здание или нет, и зависит от воли играющего и клика мышкой...

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

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

>а грузить уже сериализованный после SAVE_GAME в самом начале игры

Черт побери! Если рендер не имеет фичи "грузи статический scene graph", то грузить его сериализованное состояние - как мертвому припарки. Ну, будет загрузка чуть быстрее - а проблемы рантайма останутся. Попутно умрешь, синхронизуя кеш с текущей версией карты.

#17
5:41, 5 фев. 2006

IronPeter

Уверен, что про строго статические системы ты можешь догадаться и сам.
("Строго статические" == точка сборки большинства ресурсов - до запуска игры.)

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


1. Bloating vs Genericity: один и тот же объект в разных контекстах.

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

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

Т.е. вопрос размера и структуры модели - из серии "сколько байт занимает метод inline T max(T a,T b)".
В разных контекстах-специализациях и в разных контекстах-inline и в разных контекстах-a==0 - разный размер, иногда просто невычисляемый в силу реордеринга и частичной вычисленности.

Компромиссность: genericity - мы фиксируем хуки (vector<T*: void*>), bloating - мы убираем хуки (vector<T: float,int>).


2. CSE и loop unrolling: одинаковые фрагменты в одном контексте.

В силу сложности задачи типично базируется либо на эвристиках (текстуры, шейдеры) либо на явном разделении в смысле "sharing" (геометрия + instance points, разные скины на одинаковых костях, материалы).
После оптимизации невозможно сказать, "что" от одного объекта, а "что" - от другого.
Более того, явным образом "одно и то же" может быть размножено (потому что в одном случае - с прозрачностью, в другом - без и т.п.).

Яркий пример: инстансинг как CSE и инстансинг как loop unrolling.

#18
6:15, 5 фев. 2006

3. Оверлеи, страницы и монолиты: фрагментирование для инкрементального движения по локациям

Монолиты - устойчивые крупные части сцены, сохраняются между/внутри локаций.
Преимущества: обширные оптимизации, предвычисление графов обновления (dependencies), отрисовки (rendering) и т.п.
Оптимальный расход памяти (не требуются вспомогательные ресурсы при дозагрузке/выгрузке).
Очень простая схема сборки.
Недостатки: требуют, чтобы всё умещалось в памяти, ригидны.

Оверлеи - "типизированные по контексту использования чанки".  "Арены".
Типизация макрофрагментов.
Разделение на чанки на уровне геймдизайна.
Два подхода.

Явная типизация (explicit typing) - руками говорится, что Пушыстик в этой зоне возможен только как антураж.
Легко реализовывать.
Практически невозможно использовать в реальной жизни - нужно слишком много явно квалифицировать.
YMMV, впрочем.  Если вменяемые геймдизайнеры...

Неявная (type inference) - на уровне есть Пушыстики и агенты А и Б.
Из описания А и Б видно, что А рассматривает Пушыстиков как элемент антуража с параметризуемой длиной шерсти, а Б - вообще никак.

Легко использовать, тяжело реализовывать.
За исключением простых случаев - жёсткая бюрократия.

Страницы - "типизированные по фукционалу чанки".  "Аллокаторы".
Типизация на уровне микрофрагментов.
Пул ("библиотека") текстур, пул буферов.

Легко реализовывать, тяжело поддерживать: слишком мало информации.
За исключением простых случаев - тяга к резкой динамике.

Из недостатков и страниц и оверлеев - потери памяти для доп.буферов.
Оверлеи еще к тому же фрагментируются в реальных лесах containment.

#19
6:29, 5 фев. 2006

5.  Constants propagation - предвычисление на основе знания о возможности изменения.
Забыл сказать, что при агрессивной оптимизации теряется возможность написания generic игрового кода.
Поскольку ассеты полностью перестают быть экземплярами классов.
Грубо говоря, как max(T,T) перестает быть функцией и начинает зависеть не только от T, не только от inline, но от конкретных значений аргументов, если это даёт возможность агрессивно оптимизировать.
Примеры: анимации vs их отсутствие, заинтересованность игрового кода в параметре "прозрачность" vs незаинтересованность+прозрачность в материале == 0 и т.п.

6.  Sharing, prototyping и cloning - явное определение семантики разделения ресурса против его копирования.
Актуально даже при простейших способах оптимизации.
Sharing - атрибуты глобально разделяются внутри всего контекста.
Пример - погодные артефакты, флаги враждующих сторон и т.п.
Prototyping - атрибуты "наследуются" от родителей.
Преимущества - по памяти можно сжимать.
Недостатки - по скорости чаще проще разложить и мучаться при обновлении.
Cloning - всё копируется.

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

#20
6:45, 5 фев. 2006

4.  DLL exports и callbacks - как игровой код использует хуки.
Если действительно полностью статическая структура - DLL exports - т.е. фиксапится игра, а не контент.
Если не полностью статическая или не имеет смысла так агрессивно оптимизировать - callbacks - фиксапится контент.
Еще одна альтернатива - в игре "умные указатели" или в игре "поиск атрибута", но типично это попа.

#21
7:03, 5 фев. 2006

7. View - попытки соптимизировать разные способы использования ресурсов.
Физически - разные взгляды на один и тот же компот микрофрагментов.
Цель - максимизировать locality для наиболее популярного взгляда.
Скажем - "игра редко изменяет этот атрибут" -> изменение атрибута превращается в комплект фиксапов, зато физически атрибут располагается так, чтобы рендеринг проходил быстрее или объект занимал меньше памяти.
Связано с тем, что предвычисленные бандлы (bundles) как правило атрибутов из DOMа (оригинальной модели описания, скажем, "прозрачность" или "ржавость" или матрица трансформации узла "Node17") в простом виде не содержат.
Половина графа уже вычислена, оставшееся держится на анимациях или, возможно, на сгенерированном коде/байткоде.

Пример: в "спецификациях" после сборки игра не могла (даже если б хотела) найти то, что она не попросила заранее.
Единственный способ радикально фаршануть - это сказать Root: node("SceneRoot"); Objects[]: pobject("*") или как-то так (уже не помню, если честно).  Фактически такой фарш позволял сказать оптимизатору "игре доступно всё", что отключало нафиг бОльшую часть оптимизаций.  Зато у node был метод clone() и find().

Другой пример (больше из области LTCG и PGO, то есть из слабодинамических моделей): связывание нового rendering traverse при добавлении нового объекта в сцену.
Скажем, встраивание прозрачных объектов, теней, перелинковка dependencies и т.п.

#22
7:24, 5 фев. 2006

IronPeter
> Вот тут видна сложность номер 1. Она связана с тем, что все редактирование сцены приходится производить
> в программе моделирования. Вот хотим мы оттьюнить материалы.
> Так мы не можем использовать свой красивый редактор!

Можно использовать свой красивый редактор как плагин к DCC пакету.
Экспортировать сразу правильный ассет.

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

Альтернативно, экспортируется ссылочный словарь.

Почему нет?

> Ибо .dae файл является результатом экспорта, если мы залезем в него и засунем какие-то свои
> личные теги, то при переэкспорте мы все потеряем.
Нет, патчить dae - это либо в морг, либо постпроцесс прямо во время экспорта.

> Вешать какие-то модификаторы, которые лезут по xpath#xpointer внутрь файла и "фиксапят" данный материал?
> Выглядит криво.
Звучит криво.
Почему не экспортировать сразу правильный материал или сразу не экспортировать мягкие ссылки?

> И для того, чтобы грамотно перевязать пользователя и рендер, необходимо запрашивать
> список анимаций для данной модельки внутри ассета.
> А еще моделькам надо уметь менять материалы...
Не очень понял, в чём здесь проблема.

> Ассет не является такой уж единой информационной сущностью,
> надо лезть внутрь грязными руками с помощью xpath#xpointer.
Ну, ссылки тебе в любом случае понадобятся.
Вопрос здесь скорее в том, чтобы эти ссылки были не ad hoc, а известны до точки сборки.

> Мы с сожалением видим, что наша концепция ассета перпендикулярна происходящему.
> Короче - сложно, надо думать и говорить.
Почему перпендикулярна? :)

Или твой ассет - это и есть финальный бандл (bundle)?
Так не бывает.
Точнее бывает, но тогда на половину оптимизаций ты можешь сразу забить.

Для простоты предлагаю термин "Ассет" оставить для "Управления ассетами" - т.е. то, что у тебя в системе контроля версий.
А то, что у тебя грузится inplace - в зависимости от контекста - чанк, фрагмент, бандл (bundle).

#23
7:51, 5 фев. 2006

IronPeter
> Да, хочется именно наличия атомарных блоков загрузки и рендеринга.
Не очень понимаю, почему так не получается даже в случае "плохой кухни".

В FighterAce 3.х был Quark - это мягко говоря очень динамизированный движок.
Там можно было любой узел откопировать, в меше поменять пару материалов на каждом уровне иерархии.
Плюс гениальная схема загрузки была очень рекурсивной в плане меша, создавала микрофрагменты и по ходу их связывало в граф объекта. Потом он добавлялся в сцену и т.п.

Но даже с этим стало возможно жить.  Потом.
Когда я добавил так называемые "pre-bundled" объекты.
Тупо бегал скрипт, собирал реальные объекты, оптимизировал, делал максимально что возможно.
Очень ощутимый прирост.

Правда, это скрипт многое знал, поскольку в Quark MAX-Export при экспорте указывалось, что это за модель - что она самолёт, вот такие метаданные и т.п.
Собственно, благодаря написанию ряда оптимизаций в экспорте я и пошёл думать насчёт "спецификаций".

> У меня плохо даже не то, что монстр превращается в кучу суеты на диске.
> Плохо то, что монстр превращается в кучу суеты на каждом из уровней иерархии.
> От суеты на диске до malloc и CreateTexture суеты внутри рендера.
Вот это можно соптимизировать даже при плохой кухне.

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

Базовая функция у рендера может быть только одна: RenderScene().
Максимум - расширения по вьюпортам, но даже они типично зашиваются внутрь.
Имхо.

> Проблема в том, что layer оптимизации SG никак не протаскивается из рендера навверх.

Я вот, если честно, не очень понимаю, что такое SG вообще.
В смысле - для чего она нужна.
Просто не понимаю.
Ни один данный мне пример не выдержал сколько-нибудь вменяемого обсуждения.

Что такое SG для трансформационного (в смысле - tools!) пайплайна - я понимаю.
А вот нафиг он в игре - не понимаю.


> Еще раз повторю, что лично мне интересно обсудить правильный язык статических SG.
Мне тоже.  Только я не очень понимаю, что такое (статические) SG.

> Насколько я понимаю, layer оптимизации SG и выделения атомарных блоков загрузки-рендеринга
> плохо стыкуется с концепцией CResource.
Я бы сказал, что концепция CResource вообще мало с чем стыкуется.

> Зубную пасту легко выдавить из тюбика и сложно засунуть обратно.
У меня постоянное ощущение (еще по топику об атласах), что ты пытаешься придти к спецификациям.
Это неправильное направление, Пётр, правда.  Меня к тому времени постиг серьёзный деформирующий дзен.
Будь проще, как Дима Долгов или как Рома Арсенихин.  Простые идеи намного более жизнеспособны.

Не путай efficiency с effectiveness.

#24
12:07, 5 фев. 2006

aruslan

Руслан, о чем я  догадаюсь про строго статические системы? Вот если взять Диму Долгова, образец простоты, то он работал с монолитами, которые одновременно являлись страницами. Строго статическая система, художники вместе с геймдизайнерами плачут и режут все на одинаковые куски. Скрипты и зоркий глаз программиста  помогают соптимизировать что-то внутри куска.

В рантайме конкретному объекту можно залезть внутрь и изменить позицию, но ни убить, ни родить новый, ни сказать clone. Прекрасная система, стройная, простая и работающая. Хочу так же.

И когда я говорил про атласы, то имею в виду, что очень неплохо в этом куске ("монолит") взять текстуры и положить в один атлас. Потому как это решает две конкретные проблемы: проблему слишком мелких кусков и проблему типизации микрофрагментов в твоей терминологии. Если на target платформе ( PS2 к примеру ) проблемы мелких кусков и типизации микрофрагментов не стоят, то никаких атласов строить не надо. Есть опция копать, есть опция не копать. И я как-то не понял, почему на меня в этот момент шикнули :).

Мой ассет - это твой монолит, в котором проведены оптимизации "графов обновления (dependencies), отрисовки (rendering)", вплоть до определения порядка отрисовки и протокола смены рендерстейтов.  Сделано построение текстурных атласов, оптимизация VB & IB по локальности и многие прочие финты ушами. Если встает вопрос, что такое SG - он и есть граф обновления, рендеринга. Грубо говоря, AABB дерево + порядок рендеринга. У Димы, кстати, есть заклинание "no dependency graph". Очень мощное заклинание.

Что до частичных вычислений, то ты принижаешь мощь человеческого разума. Нет никаких таинственных полиморфных Пушыстиков. Есть, скажем, деревья, которые ставятся на уровень. В окошке Maйки видно число faces & vertices, FVF известен. И ничего не стоит взять калькулятор, взять число деревьев на уровне и тупо так умножить на размер IB + VB. Почему умножить? Потому что warfog на CPU считается, отдельно для каждой инстанции. Полученное на калькуляторе окошко и будет потреблением памяти на деревья. Плюс 10% на объектную обвязку, slack в memory allocator. Вот тебе и Bloating. Не абстрактный, а живой.

Если результат вычислений не совпадают с тем, что показывает дебажный аллокатор памяти, который раскручивает стек, то надо срочно читать исходники и подправлять формулу вычислений. Моя простая идея состоит в том, что такие вычисления на калькуляторе должны проводиться как можно раньше, желательно на этапе preproduction. Еще лучше, если такой калькулятор будет встроен в редактор уровня и его результат будет капать дизайнерам на мозги.


Вторая идея состоит в том, что поведение должно быть предсказуемым. Если в коде есть итеративное вычисление последовательности n-того числа Фибоначчи и вынесено в скриптовую функцию ( из-за чего игра задумывается иногда по полчаса ), то давайте оштрафуем автора. Если в коде есть template, который разворачивается в 1 мегабайт кода из-за рекурсии - давайте оштрафуем автора еще раз. И никакие отмазки про CSE и loop unrolling вместе с Bloating не должны помешать.

Посему схема Долгова мне кажется идеалом.


Правка: рефакторинг.

#25
14:11, 5 фев. 2006

IronPeter
>Руслан, о чем я догадаюсь про строго статические системы?

Пётр, я не мог не написать disclaimer отвечая бОльшей половине ума планеты.
Мне виделся в твоих декларативных постах вопрос.
Вот только я не мог понять, какой :)

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

Мой рецепт: прекрасный коньяк/глинтвейн, камин, терпеливый знающий собеседник и подобающий антураж.
Камин нужен, чтобы согревал и чтобы кидать в него карикатуры из спичек.


>Строго статическая система, художники вместе с геймдизайнерами плачут и режут все на одинаковые куски.
>В рантайме конкретному объекту можно [...] изменить позицию, но ни убить, ни родить новый, ни сказать clone.
>Прекрасная система, стройная, простая и работающая.
>Хочу так же.

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

>И когда я говорил про атласы, [...] очень неплохо в этом куске ("монолит") взять текстуры и положить в один атлас.
> И я как-то не понял, почему на меня в этот момент шикнули :).

Mea culpa.
Атласы - безусловно.  Конечно же, только для платформ, на которых это делает жизнь лучше.

Просто мне показалось, что ты глубже копаешь.

>Мой ассет - это твой монолит, в котором проведены оптимизации графов [...]
>У Димы, кстати, есть заклинание "no dependency graph". Очень мощное заклинание.
Даже догадываюсь отчего/от чего ;)

>Что до частичных вычислений, то ты принижаешь мощь человеческого разума.
>Нет никаких таинственных полиморфных Пушыстиков.
Уже понял.

>Почему умножить? Потому что warfog на CPU считается, отдельно для каждой инстанции.
Думаю, 17-18 спичек будет достаточно.  Это если стилизованной латиницей.

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

Очень правильные мысли.
Не всегда возможные (особенно - на этапе preproduction), но если принять на сердце здоровый пессимизм...

>Вторая идея состоит в том, что поведение должно быть предсказуемым.
>И никакие отмазки про CSE и loop unrolling вместе с Bloating не должны помешать.

Я говорил немножко о другом: монолиты/страницы - это peephole оптимизации, т.е. одни из самых слабых.
Все остальные могут соптимизировать сильнее, но предсказанию и быстрой оценке они поддаются слабее.
Поэтому пришлось бы ориентироваться на худшие показатели, как более предсказуемые.

Ты и так уже только на них ориентируешься, поэтому калькулятор можно вструнить куда угодно.

>Посему схема Долгова мне кажется идеалом.
Понимаю и согласен.

"A ship in harbour is safe, but that is not what ships are built for."
-- William Shedd

#26
16:38, 5 фев. 2006

Я тут посидел, подумал, и решил, что одним коньяком ты не отделаешься.

Помимо декларативной части были вполне конкретные вопросы.
Язык статического SG.

Раскрой тему?

#27
21:27, 5 фев. 2006

/me подписалсо

#28
22:42, 6 фев. 2006

>Язык статического SG.

Ну, я послушал Долгова и посмотрел на Колладу.

У Димы весь игровой мир загружается inplace, со всеми игровыми объектами, которые сами себя и рисуют. Конечно весьма прикольно импортировать из Майки готовый игровой мир со всякими сущностями вроде CSun или СМужикНаМотоцикле. Прямо в том виде, в котором этот мужик на мотоцикле будет выглядеть на target platform. По-бай-то-во, как высокоуровневая сущность. Однако все жа разумнее сосредоточиться на графической части. Пусть мы умеем лазить внутрь ассета по каким-то хендлам, в которые превращаются xpath#xpointer на этапе экспорта. И пусть этот ассет отражает исключительно графическую и физическую метафоричность, а весь конкретный DSL сидит снаружи и дергает за хендлы.

Моей идеей было посмотреть на Колладу и делать так же, как там, только в бинарном представлении. Начинается Коллада-файл весьма пафосно, в стиле:

<asset>
    <authoring_tool>Maya 6.0.1 COLLADA exporter</authoring_tool>
    <source_data>.../Archangel_Idle00.mb</source_data>
    <up_axis>Y_UP</up_axis>
    <unit name="centimeter" meter="1.e-002"/>
    <author>peter.popov</author>
    <modified>2005-09-12T08:17:32Z</modified>
</asset>,
поэтому я и называю полученную сущность ассетом - апгемахт!


Коллада-файл содержит внутри libraries:

<library type="IMAGE">
Ну, обычные текстуры - разумно делать атласы, swizzlить в формате target платформы, но в целом никаких загадок нету.
<library type="TEXTURE">

Настройки фильтрации, врап-мод и прочего. Опять ничего сложного, вполне разумные блоки D3D ( OpenGL ) стейтов, а может даже и куски push_buffer.

<library type="MATERIAL">

Вот это реально сложная штука, бо она выглядит примерно как:

       <material id="Arch_main" name="Arch_main">
      <shader>
        <technique profile="COMMON">
          <pass>
            <input semantic="TEXTURE" source="#file1-DIFFUSE"/>
            <program url="PHONG">
              <param name="DIFFUSE" type="float3" flow="IN" sid="diffuse">1. 1. 1.</param>
              <param name="AMBIENT" type="float3" flow="IN" sid="ambient">0.22314 0.22314 0.22314</param>
              <param name="TRANSPARENT" type="float3" flow="IN" sid="transparent">0 0 0</param>
              <param name="TRANSPARENCY" type="float" flow="IN">1.</param>
              <param name="EMISSION" type="float3" flow="IN" sid="emission">0 0 0</param>
              <param name="SPECULAR" type="float3" flow="IN" sid="specular">5.786e-002 5.786e-002 5.786e-002</param>
              <param name="REFLECTIVE" type="float3" flow="IN" sid="reflective">0 0 0</param>
              <param name="REFLECTIVITY" type="float" flow="IN" sid="reflectivity">0.5</param>
              <param name="SHININESS" type="float" flow="IN" sid="shininess">2.</param>
            </program>
          </pass>
        </technique>
      </shader>

Правка: зачекан некомпилирующийся код. Исправлено.

#29
22:42, 6 фев. 2006

С параметрами никаких проблем нету - это опять-таки массивы шейдерных констант, куски push_buffer. А вот с  <program url="PHONG"> закавыка. Ибо "Фонг" - это вполне себе разумное название высокоуровневой функциональности. Однако, Коллада разрешает и прямое указание текста программы на Cg ( HLSL - один хрен ).
Соответственно возникают две альтернативы - или писать в экспортированном ассете какие-то абастрактные имена высокоуровневых Shading техник, либо вхреначивать откомпилированный байт-код. Первое несколько противоречит идее минимальности рендера, второе вносит технические сложности.

Допустим, мы решились таки экспортировать откомпилированный шейдерный байт-код. Тогда надо сразу делать разные трики. Скажем, экспортировать вместе с шейдером некий хеш-код, дабы не создавать в рантайме лишние инстанции одинаковых шейдеров ( ассеты ничего не шарят принципиально!). Кроме того, мы не увидим новые тени в игре, пока не переэкспортим все ассеты - сие выглядит немного странно. Кроме того, все равно придется вводить формальные имена разных проходов - lighting pass, render-to-depth texture pass, apply-depth-texture pass и прочая. Вместо "PHONG" и компании. Непонятно, как жить с разными скелетно-анимированными мешами и прочими стенсельными тенями, которые на target платформе вполне могут исполняться на разных специально приспособленных DSP. Откомпилировать шейдерный код на этапе экспорта - это я понять могу. А вот компилировать байт-код для разных там SPU на этапе экспорта - это обыкновенный фашизм. Короче, сплошная загадка!

<library type="GEOMETRY">

VB + IB с аннотацией FVF. Побольше 16 битных форматов и прочих DEC10N для нормали! А в целом - вполне себе очевидный результат прогона D3DXOptimizeMesh.

<library type="ANIMATION">

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

Это все - сырая начинка, глина. Самое важное поле в коллада-документе - <scene>. AABB дерево с нодами, которые выглядят примерно как:

<node id="R_Shell" name="R_Shell" type="JOINT">
            <boundingbox>
              <min>-0.42324 0.323952 -5.73785e-002</min>
              <max>-0.299455 0.512785 -5.5735e-002</max>
            </boundingbox>
            <translate sid="translate">-0.299455 0.323952 -5.5735e-002</translate>
            <rotate sid="rotateZ">0 0 1 31.1686</rotate>
            <rotate sid="rotateY">0 1 0 -6.87538</rotate>
            <node id="joint50" name="joint50" type="JOINT">
              <boundingbox>
                <min>-8.32236e-003 0.22564 -6.51906e-004</min>
                <max>-8.32236e-003 0.22564 -6.51906e-004</max>
              </boundingbox>
              <translate sid="translate">-8.32236e-003 0.22564 -6.51906e-004</translate>
            </node>
          </node>

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

Вот это ассет на низком уровне. На среднем уровне, вероятно, необходимо выделять отдельные объекты. Это меши, анимированные или нет. Их можно включать на сцене, инстанцировать ( с какими-то трансформациями ) и прочая. Но это уже элементы другого уровня описания.

Вероятно, в дебажном варианте можно вместе с экспортом ассета экспортировать "обвязку" целиком и уметь интерактивно изменять параметры ассета. Скриптами, разными ползунками в гуи на host - неважно. Но это опять дело техники.

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.