 Show Posts
|
|
Pages: [1]
|
|
1
|
Русскоязычный Форум / Unreal-кодинг / Re: Околодевелоперские байки :)
|
on: February 11, 2010, 16:48
|
А есть презентации или документашка от ms с этими рекомендациями ?
Увы, нет. Они в привате на сайте Microsoft, вход - только для зарегистрированных разработчиков для XBox 360. Там презентации с сопроводительным аудио (записи лекций). Где то у меня был не активированный купон на elearning от ms  Правда в разрезе w2k3. Наверное к xbox360 не пустят, если это вообще тот сервис |
|
|
|
|
2
|
Русскоязычный Форум / Unreal-кодинг / Re: Околодевелоперские байки :)
|
on: February 11, 2010, 16:14
|
Где-то STL проканает (если проект простенький, или нетребовательный к ресурсам). Для того же XBox 360 Microsoft в лекциях предлагает забыть про STL и отказаться от многих распространённых C++ конструкций, считающихся "признаком хорошего C++ программиста" - больно уж большой просад производительности на таком коде - и причём объясняли на пальцах, почему.
Не зря же полявился stlport А есть презентации или документашка от ms с этими рекомендациями ? |
|
|
|
|
3
|
Русскоязычный Форум / Unreal-кодинг / Re: Околодевелоперские байки :)
|
on: February 11, 2010, 14:58
|
Это касается некоторых разработчиков с которыми я работал раньше и работаю сейчас. "Не критичный код - заюзаем STL". И т.п.
Это тема опасная на мой взгляд Очередной holy war из той же оперы, что и shadow maps vs shadow volumes, unreal warfare vs doom, etc. Конкретно по стл - кто-то считает, что разрабатывать свои контейнеры хорошо и правильно. с++ гики обычно говорят, что использование стл/буста с++ way и глупо создавать что-то свое. ps А я люблю слово depends |
|
|
|
|
4
|
Русскоязычный Форум / Unreal-кодинг / Re: Околодевелоперские байки :)
|
on: February 11, 2010, 13:58
|
Ну это когда уже станет ясно, где он, критический код. preemptive optimization is evil (c) Как то так. Я против того, чтобы некритичный код писался гм ... "через одно место" Передергиваешь мои доводы уходя в крайности Если код не оптимизируется по самое "не могу" это не значит, что он писался через одно место. Собственно практика показывает что практически "любой код можно улучшить возвращаясь к нему через несколько месяцев" (c) |
|
|
|
|
5
|
Русскоязычный Форум / Unreal-кодинг / Re: Околодевелоперские байки :)
|
on: February 10, 2010, 18:12
|
Увы, в UT3 прописана минимальная версия загружаемого пакета (есть такой параметр в движке, причём при компиляции автоматом старый код отсекается). Так вот, в UT3 она прописана на 1 больше чем версия PC Gears of War. Если бы они такого не сделали - можно бы было загрузить. Но некоторые типы ресурсов не менялись в этом промежутке - можно обмануть движок: руками подправить версию будто она новее, и тогда пакет должен подхватиться.
Хитро придумано Функционал есть, но заблокирован Этот функционал доступен всем.
В доступности сомнения нет. Есть сомнение в его практической нужности команде, реализующей что-то на unreal warfare. Нет. Неграмотно - это человеком, который имеет представление об "эффективном коде" по книжкам о программировании на C++  Я частенько критический код проверяю дизассемблером. Ну это когда уже станет ясно, где он, критический код. preemptive optimization is evil (c) Как то так. Если виртуальной памяти нет - считай, что виртуальный адрес совпадает с физическим. Hunk.Touch видел. Это трюк, заставляющий физически выделить память, а не просто зарезервировать. Вообще - я не понял, в чём здесь вопрос? Да, механизмы виртуальной памяти в DOS32, Windows и Linux отличаются. На XBox360 её нет. Честно Про xbox360 нет никаких сомнений. Кроме того я как то и не думал о xbox360, потому как дела с консолями вообще то не имел. Странно, что ты акцентировал внимание на коробке. Есть опыт разработки под него ? В чем вопрос ? Там был не вопрос был Только сомнения на счет твоих слов сравнительной неэффективности и по сути не нужности mm механизма, при всем при том, что даже если физической памяти будет достаточно это совсем не отменяет пейджинг для этого приложения В UE3 есть стриминг и асинхронное чтение. Ты об этом?
Не совсем, ну да не суть. Я считаю, что memory mapping прироста скорости не даст. Если я читаю весь файл за 1 вызов read или через memory mapping - время будет потрачено одинаковое, но кода во 2м случае будет намного больше.
Я склоняюсь, что все же depends... И больше плюсов в сторону mm Впрочем это легко "померять" Возни с инициализацией несколько больше, да. Но совсем не страшно Паттерны не использую и не знаю. Я не любитель умных книжек по C++ Мне нравится архитектура UE. Она очень грамотно написана, очень удобна и расширяема (например, UE3 всё ещё содержит код из UE1). И судя по тем исходникам, что есть в сети (например, ut436pubsrc) движок писался не по Стоуструпу, а по уму Хорошо что я не c++ geek А то бы сжег тебя на костре за такие слова Лично для меня играет роль прежде всего результат. Производительность, стабильность, затраты. А как это было достигнуто уже не важно. Победителей не судят ps А что такого плохого у Страуструпа ? Как по мне Джеф Элджер гораздо приятнее пишет pps Как то плавно мы скатились с анимации в UE на... гхм... на околодевелоперские байки |
|
|
|
|
6
|
Русскоязычный Форум / Unreal-кодинг / Re: Околодевелоперские байки :)
|
on: February 10, 2010, 16:24
|
Что касается выделения памяти в windows. Рано или поздно независимо от того, что мы используем для выделения памяти мы упираемся в функции группы Virtual* (VirtualAlloc и иже с ними). Цитата из книги Рихтера (Windows Via C/C++ by Jeffrey Richter and Christophe Nasarre Microsoft Press © 2008, 5 издание) Committing Storage in a Reserved Region
After you have reserved a region, you need to commit physical storage to the region before you can access the memory addresses contained within it. The system allocates physical storage committed to a region from the system's paging file. Physical storage is always committed on page boundaries and in page-size chunks.
Я имею ввиду, что выделяя память windows, ты выделяешь память в страничном файле. А дальше дело техники. Деманд пейджинг ? |
|
|
|
|
7
|
Русскоязычный Форум / Unreal-кодинг / Re: Околодевелоперские байки :)
|
on: February 10, 2010, 16:03
|
Да. Хотел сделать игру, которая позволяла бы побегать на картах их других игр. Для Quake2 как-то давно всё заглохло. Мне нравились уровни из Quake1 - в своё время накачал их порядочно И из некоторых action-модов для Q3 (Urban Terror и т.п.) Ещё подцепил модельки игроков ... В общем, хотел иметь возможность заюзать ресурсы из других игр. При этом - полная совместимость с оригинальным Quake2 по сети и по game.dll. quake 2 в швейцарский нож ? В UE таймлайн для каждой кости свой. Т.е. если кость анимируется по-сложному - у неё ключей много, а если по-простому - то мало. В последнем UE3 позиция и вращение имеют раздельные таймлайны.
Последний UE3 это тот, что использовался в GOW2 ? Да ничего особенного. Просто научились нормально жать анимацию И дали дизайнеру выбор - как жать. Epic Games занимается компрессией анимации по крайней мере со времён UE2 Runtime (в UT2004 её не было, хотя в формат была заложена ... была только возможность хранить трек, содержаций одинаковые величины, как один ключ). В общем, лет 5-8 эволюции. Наверняка они знают что делают. Умудрились затолкать в приставку с памятью 512Мб игру уровня Gears of War 2. Все одно толком не осознал где компрессия Отложим тогда. Если буду заниматься предметно, тогда обращусь Unreal умеет читать модели от предыдущих версий (естественно, в пределах одного поколения движка). Ещё в его структурах есть блоки данных, которые совпадают по содержимому в памяти и на диске -
Значит ли это, что если я захочу загрузить пакеты с моделями и анимациями скажем из Gears of war в UT3 или наоборот они будут коректно загружены и будет возможность их использовать ? такие блоки грузятся за один вызов read. Но при этом, если мы заходим загрузить пакет от XBox360 на PC - такие структуры будут загружены "по полям" (с перестановкой байтов). Также, такие структуры могут меняться от версии к версии, и при этом загрузка файла, созданного в последней версии движка, будет сделана за 1 read, а загрузка старых версий - поэлементно (надеюсь, что я понятно излагаю мысль; если надо - могу привести примеры).
Да понятно. На надо ли такой функционал лицензиату движка ? От того, читаю я блок 1Мб сразу в память или после чтения по нему пробегаюсь и раскидываю по полям объекта игра медленнее работать не будет. Знаю, что многие компании делают чтение большого блока в память и после
Сама игра нет. Загрузка будет выполняться медленней. Впрочем это не столь критично. этого "выправляют" указатели (так сделано например в том же Havok). IMHO это не даст выигрыша - разве что неграмотно написать чтение объекта "по полям".
Неграмотно это не последовательно ? Cache unfriendly ? Memory mapped files есть только на PC, на приставках (по крайней мере на XBox360) - нет. И вообще - такой механизм в общем случае не даёт выигрыша в скорости (если на компе зватает памяти и не используется swap file).
А на какой архитектуре построен xbox360 ? Сама ос на сколько я помню там модифицированный w2k. Не согласен. mm даст прирост в любом случае по сравнению с обычными операциями чтения. Доступ с использованием mm выполняется быстрее за счет обхода каких-то привычных механизмов файловой системы ос. Подробностей к сожалению не вспомню. Надо копать Рихтера, Руссиновича, msdn. Отдельно скажу на счет хватает памяти или нет. Ты как человек потрошивший уе (кстати, чем ? ida ? driver studio ? ) и анализировавший код q1/q2/q3 ведь понимаешь, что собственно приложение работает лишь с виртуальной памятью. Оно не знает, где именно находится страница с которой оно работает. Вспомни, как в q1 делался touch в hunk менеджере по всей выделенной памяти 'Хватает' физической памяти или нет это исключительно выбор менеджера страниц в ос с его алгоритмами. Политика использования страничных файлов/девайсов в том же linux и win очень сильно отличается. Так что я бы сказал здесь просто - depends Также, если использовать такой подход, код чтения и сохранения объекта будет разным. В UE код сериализации один. При желании в нём можно узнать, идёт сейчас чтение или сохранение объекта.
Локи есть ? И ещё. Memory mapped files не даёт использовать компрессию файлов - а значит, они будут грузиться с диска (особенно с какого-нибудь DVD) медленнее. Намного быстрее загрузить пожатый файл и распаковать его в памяти.
Пожалуй. На самом деле можно мапить страницы с возможностью записи и copy-on-write и получить возможность записи прямо в эти страницы. Правда тогда нужно подумать об увеличении размеров замапленного региона. Если не ошибаюсь, это можно сделать. Вобщем для простоты в отдельный буфер пжалста То же самое сделает и код сериализации приведенный тобой в пример - распаковка все равно будет происходить где-то в стороне. Но вцелом я понял, что ты фанат паттерна сериализации |
|
|
|
|
8
|
Русскоязычный Форум / Unreal-кодинг / Re: Околодевелоперские байки :)
|
on: February 10, 2010, 15:39
|
Лирическое отступление. Заглянул в недра source'а на примере Left 4 dead 2. По ключевым персонажам. Модель рендерится в 7 DIP'ов. Причем я так понял освещение от некоторых источников (вчасности от фонарика) многопроходное. Скининг явно на гпу. Есть сортировка по материалам. Порядок рендера модели - лицо (в том числе челюсти и язык видимо), остальная часть головы (волосы, похоже зубы и 'манишка'), собственно тело (отсутствует либо кисть либо пальцы на руке нажимающей курок я так понял), отдельно кисть, глаз, глаз, кобура. На лицо и голову свой набор текстур. На тело и руки свой. На глаза свой. Вершинный шейдер один (кроме глаз). Мне он на вскидку ничего не скажет. Может быть ты найдешь что-нибудь интересное. //
// Generated by Microsoft (R) D3DX9 Shader Compiler
//
// Parameters:
//
// float4 cBaseTexCoordTransform[2];
// float4 cDetailTexCoordTransform[2];
// float4 cFlexScale;
//
// struct
// {
// float4 color;
// float4 dir;
// float4 pos;
// float4 spotParams;
// float4 atten;
//
// } cLightInfo[4];
//
// float4x3 cModel[53];
// float4x4 cViewProj;
// bool g_bLightEnabled[4];
//
//
// Registers:
//
// Name Reg Size
// ------------------------ ----- ----
// g_bLightEnabled b0 4
// cViewProj c8 4
// cFlexScale c13 1
// cLightInfo c27 20
// cBaseTexCoordTransform c48 2
// cDetailTexCoordTransform c52 2
// cModel c58 159
//
vs_3_0
def c1, -128, -64, 0.0158730168, 1
def c2, 765.005859, 3.05175781e-005, 9.99999975e-005, 0
dcl_position v0
dcl_blendweight v1
dcl_blendindices v2
dcl_normal v3
dcl_texcoord v4
dcl_position1 v5
dcl_normal1 v6
dcl_position o0
dcl_texcoord o1
dcl_texcoord1 o2
dcl_texcoord2 o3.xyz
dcl_texcoord3 o4.xyz
dcl_texcoord4 o5.xyz
dcl_texcoord5 o6
dcl_texcoord6 o7.xyz
mul o6.w, c13.y, v5.w
dp4 o1.x, v4, c48
dp4 o1.y, v4, c49
dp4 o1.z, v4, c52
dp4 o1.w, v4, c53
add r0, c1.x, v3
slt r1, r0, c0.x
add r0, r0_abs, -r1
add r0, r0, c1.y
mad r1.xyz, r1.xzww, -c0.z, c0.y
slt r2, r0, c0.x
add r0, r0_abs, -r2
mad r3.xy, r0.xzzw, -c1.z, c1.w
mad r3.w, r0.y, -c1.z, r3.x
mad r4.z, r0.w, -c1.z, r3.y
mad r2, r2, -c0.z, c0.y
mul r0, r0, c1.z
mov r3.xz, r0.xyyw
nrm r5.xyz, r3.xzww
mul r3.xy, r2, r5
mul r3.z, r1.x, r5.z
mov r4.xy, r0.zwzw
nrm r0.xyz, r4
mul r0.xy, r2.zwzw, r0
mul r0.w, r1.y, r0.z
mad r0.xyz, v6, c13.x, r0.xyww
add r1.xy, c0.y, v1
mul r1.xy, r1, c2.y
add r0.w, r1.y, r1.x
add r0.w, -r0.w, c0.y
mul r2.xyz, c2.x, v2.zyxw
mova a0.xyz, r2
mul r2, r1.y, c60[a0.y]
mad r2, c60[a0.x], r1.x, r2
mad r2, c60[a0.z], r0.w, r2
dp3 r4.z, r0, r2
mov r5.w, v0.w
mov r6.xyz, v5
mad r5.xyz, r6, c13.x, v0
dp4 r6.z, r5, r2
mad r3.xyz, v6, c13.x, r3
dp3 r2.z, r3, r2
mul r7, r1.y, c58[a0.y]
mad r7, c58[a0.x], r1.x, r7
mad r7, c58[a0.z], r0.w, r7
dp3 r4.x, r0, r7
dp3 r2.x, r3, r7
mul r8, r1.y, c59[a0.y]
mad r8, c59[a0.x], r1.x, r8
mad r8, c59[a0.z], r0.w, r8
dp3 r4.y, r0, r8
dp3 r2.y, r3, r8
dp3 r0.x, r2, r2
rsq r0.x, r0.x
mul o5.xyz, r2, r0.x
dp3 r0.x, r4, r4
rsq r0.x, r0.x
mul o3.xyz, r4, r0.x
mul r0.xyz, r4.yzxw, r2.zxyw
mad r0.xyz, r2.yzxw, r4.zxyw, -r0
mul r0.xyz, r1.z, r0
dp3 r0.w, r0, r0
rsq r0.w, r0.w
mul o4.xyz, r0, r0.w
dp4 r6.x, r5, r7
dp4 r6.y, r5, r8
if b0
add r0.xyz, -r6, c29
dp3 r1.x, r0, r0
rsq r2.y, r1.x
mul r0.xyz, r0, r2.y
dp3 r0.x, c28, -r0
mov r1.y, c0.y
mov r2.xz, c0.y
mul r0.yzw, r1.xyxx, r2.xxyz
dp3 r0.y, c31, r0.yzww
rcp r0.y, r0.y
add r0.x, r0.x, -c30.z
mul r0.x, r0.x, c30.w
max r0.x, r0.x, c2.z
pow r1.x, r0.x, c30.x
min r0.x, r1.x, c0.y
mad r0.x, r0.y, r0.x, -r0.y
mad r0.x, c28.w, r0.x, r0.y
add r0.y, -r0.x, c0.y
mad o2.x, c27.w, r0.y, r0.x
else
mov o2.x, c0.x
endif
if b1
add r0.xyz, -r6, c34
dp3 r1.x, r0, r0
rsq r2.y, r1.x
mul r0.xyz, r0, r2.y
dp3 r0.x, c33, -r0
mov r1.y, c0.y
mov r2.xz, c0.y
mul r0.yzw, r1.xyxx, r2.xxyz
dp3 r0.y, c36, r0.yzww
rcp r0.y, r0.y
add r0.x, r0.x, -c35.z
mul r0.x, r0.x, c35.w
max r0.x, r0.x, c2.z
pow r1.x, r0.x, c35.x
min r0.x, r1.x, c0.y
mad r0.x, r0.y, r0.x, -r0.y
mad r0.x, c33.w, r0.x, r0.y
add r0.y, -r0.x, c0.y
mad o2.y, c32.w, r0.y, r0.x
else
mov o2.y, c0.x
endif
if b2
add r0.xyz, -r6, c39
dp3 r1.x, r0, r0
rsq r2.y, r1.x
mul r0.xyz, r0, r2.y
dp3 r0.x, c38, -r0
mov r1.y, c0.y
mov r2.xz, c0.y
mul r0.yzw, r1.xyxx, r2.xxyz
dp3 r0.y, c41, r0.yzww
rcp r0.y, r0.y
add r0.x, r0.x, -c40.z
mul r0.x, r0.x, c40.w
max r0.x, r0.x, c2.z
pow r1.x, r0.x, c40.x
min r0.x, r1.x, c0.y
mad r0.x, r0.y, r0.x, -r0.y
mad r0.x, c38.w, r0.x, r0.y
add r0.y, -r0.x, c0.y
mad o2.z, c37.w, r0.y, r0.x
else
mov o2.z, c0.x
endif
if b3
add r0.xyz, -r6, c44
dp3 r1.x, r0, r0
rsq r2.y, r1.x
mul r0.xyz, r0, r2.y
dp3 r0.x, c43, -r0
mov r1.y, c0.y
mov r2.xz, c0.y
mul r0.yzw, r1.xyxx, r2.xxyz
dp3 r0.y, c46, r0.yzww
rcp r0.y, r0.y
add r0.x, r0.x, -c45.z
mul r0.x, r0.x, c45.w
max r0.x, r0.x, c2.z
pow r1.x, r0.x, c45.x
min r0.x, r1.x, c0.y
mad r0.x, r0.y, r0.x, -r0.y
mad r0.x, c43.w, r0.x, r0.y
add r0.y, -r0.x, c0.y
mad o2.w, c42.w, r0.y, r0.x
else
mov o2.w, c0.x
endif
mov o7.xyz, r6
mov r6.w, c0.y
dp4 o0.w, r6, c11
dp4 r0.x, r6, c8
dp4 r0.y, r6, c9
dp4 r0.z, r6, c10
mov o6.xyz, r0
mov o0.xyz, r0
// approximately 186 instruction slots used
ps Улыбнул рендер ui. На 1-3 буквы по DIP'у это сильно |
|
|
|
|
9
|
Русскоязычный Форум / Unreal-кодинг / Re: Околодевелоперские байки :)
|
on: February 10, 2010, 10:35
|
Исходники от Q2 выкладывать не собирался, хотя Q2 и GPL. В Quake2 engine modding community очень развито (по крайней мере так было пару лет назад) встраивание вещей, разработанных другими "моддерами" в свой движок, причём как правило без спроса и даже без "credits" ... Да и движок у меня уже мало напоминает внутри оригинальный Quake2. Жаль только, что из-за umodel уже 2 года как проект заброшен  Без исходников не интересно Почему жаль ? Была цель создать что-то законченное ? Тут я ничего конкретного сказать не могу - в рендерер не залезал. Сам по себе рендерер (низкий уровень) вряд ли отличается чем-то от других движков - здесь мало что можно выдумать, сделать какое-то "know how".
"Составные" персонажи были в Unreal ещё во время 2й версии движка.
Именно об этом я и говорил изначально - мое непонимание, что можно нового выдумать в рендере. Да. По времени это в основном получение 2х соседних ключей из трека. Саму интерполяцию можно считать "бесплатной".
Трек это таймлайн всех кейфремов ? Я все таки не очень понимаю. Практическую пользу. Имея скелет мы создает несколько ключей-положений. Интерполяция скелета выполняется между этими ключами. Дискретизировать интерполяцию можно как угодно в любой момент времени между двумя ключами. Совокупность всех интерполяций от одного ключа к другому и есть анимация скелета. Что такого революционного сделано в уе3 ? Это балансирует качество и объём занимаемой памяти. LOD только один. Во время самой игры не имеет смысла.
Я не об геометрическом лоде. Впрочем уже понял, что мой вопрос не имел смысла. Из чего и проистекает вышеуказанное непонимание Здесь нет затрат. Только выгода. Затраты CPU будут если неграмотно написать поиск ключей.
Если можно, то хотелось бы некий абстрактный пример но с упоминанием ключевых моментов и исполнителей-участников (цпу, гпу, геометрии) Матрицы отправляются на GPU. Интерполяция, естественно, всегда делается в кватернионах.
Угу, я так и понял. Там был очень старый havok. О нём тогда ещё никто и не знал Анимация в нём появилась позже. Да и не все пользователи havok используют анимацию - это же прежде всего физика? То что старый, да. А что не знали вот уж не правда Он уже тогда 'прогремел'. Причем был какое то время чуть ли не именем нарицательным. Серьезных конкурентов у него тогда не было. Такой механизм используется только из C++ кода. На уровне скрипта используется "сериализация свойств" - несколько иной механизм, активно использующий Unreal RTTI.
Выгода на практике - сериализуем только то, что нужно, и не привязаны к конкретным форматам данных. Мне очень нравится идея, заложенная в UE насчёт сериализации.
Для чего используется подобный паттерн я понимаю, сам пользовался регулярно. Однако польза от такого подхода на мой взгляд есть только в том случае, если необходим механизм версионности объектов. Зачем это нужно в графическом движке не очень понятно. Анриал в состоянии отрендерить модели предшествующих версий ? Исходные тексты ведь открыты для лицензиата. Кто ему мешает использовать скажем для максимальной производительности читать используя проекции файлов (memory mapped files) и обращаться к памяти структурами. Это ведь будет быстрее. |
|
|
|
|
10
|
Русскоязычный Форум / Unreal-кодинг / Re: Околодевелоперские байки :)
|
on: February 09, 2010, 16:17
|
Инструментарий в UE очень удобный. Но и про технологичность этого движка ... Чего в нём (UE3) нет?
Я как раз и говорил об удобстве инструментария UE как о первопричине. Чего в нем нет я ответить не готов Мы в разных весовых категориях. Да и вопрос ведь не в этом Если интересно - как нибудь выложу.
Интересно. Исходники тоже можно будет увидеть или как и с Umodel подождем ? Мне больше нравятся проекционные размытые тени в UT2004 Так ведь космические корабли уже бороздят просторы большого театра UE3 поддерживает динамическое освещение и как следствие тени. А кстати, как у него с самозатенением ? Это всё личные предпочтения, спор здесь бессмысленный Нет-нет, никаких holy war и споров. Я уже слишком стар для этого Про другие движки - это было около 2-3 лет назад. Сейчас конкретику уже и не вспомню.
В UE3 есть поддердка моделек с большим количеством костей (больше 256) - на GPU обычно номер кости байтом задают. Т.е. режут модельку на несколько частей. Зеркалирования не видел. Есть распаковка позиции и нормали. Есть упакованные текстурные координаты.
Под зеркалированием я имел ввиду не столько архитектурную фишку движка, сколько зависимость от апи. Ситуация, когда кроме видеопамяти (локальной или не локальной) копия ресурса хранится еще и в системной памяти. В opengl зеркалирование есть всегда. Во всяком случае раньше было. В d3d тот же эффект мы получаем при создании статики в managed пуле. Сейчас на несколько частей многие режут. Недавно смотрел рендер Overlord 2. Там ключевые персонажи состоят из нескольких мешей. То же самое с Armed Assault 1/2. Герои Меча и Магии 5 (от Nival)
Не видел. А у них что за компрессия ? Или это NDA ? Компрессия анимации в UE3 - удаление ключей, которые могут быть получены интерполяцией двух соседних ключей (с допустимой ошибкой) - key reduction. Также используются несколько вариантов сжатия кватернионов - в 4 или 6 байтов. Вид сжатия выбирает дизайнер в UnrealEd, он может сравнить сжатый и несжатый варианты и только после этого удаляется оригинал (во время cooking). Распаковка делается "на лету". Некоторые игры (на базе UE3) используют другие методы сжатия (например Batman). В Gears of War 2 (и UDK) появились time tracks раздельно для позиции и вращения. Собственно, до этого key reduction как такового и не было - например, в UT2004 есть трек времени, но он всегда содержит числа 0,1,2,3,...N-1.
Есть ещё компрессия в Havok - там используются более сложные алгоритмы - wavelet и т.п. Я так понимаю, что жмут кривые. Для распаковки используют буфер (кеш).
Интерполяция и получение недостающего кейфрейма происходит в рантайме ? Или это все таки средство оптимизации для аниматора на этапе создания модели ? Можно ли влиять на этот процесс из движка таким образом получая эдакий анимационный lod ? Затраты на такой трюк не привышают ли выгоду ? О кватернионах не очень понял. Интернал представление же все равно в матрицах. А кватернионы используются лишь при расчетах на цпу ? Я неправ ? Havok это вообще отдельная песня. В 'исходниках' hl2 была какая то версия хавока, правда без модуля анимации. Если сравнивать с Quake - то в Unreal используется совершенно иной подход для сериализации данных. В Quake: читаем большой блок памяти, переставляем байты (для big-endian), и рендерим прямо отсюда. Это не даёт возможности расширять формат (иначе все данные "съедут"). В Unreal всё по-другому: сериализуется каждое поле по-отдельности. В пакете имеется номер версии, и движок читает поля так, как они были сохранены в той версии, которая указана в пакете...
Мысль понял. А большая ли польза от этого на практике ? Или десереализация идет исключительно на уровне Unreal Script'а и сам движок лишь шасси ? |
|
|
|
|
11
|
Русскоязычный Форум / Unreal-кодинг / Re: Околодевелоперские байки :)
|
on: February 09, 2010, 11:16
|
Т.к. от современных технологий я уже отстал, возможно где-то буду нести чепуху. Сильно не пугайся Я выбрал самый успешный (не только по моему мнению) движок - Unreal Engine. На тот момент это был Unreal Engine 2 (UT2004). Меня его анимация более чем устраивала, плюс я вроде преследовал цель - использовать модельки из UT2003/UT2004 в своём моде Quake2. Модельки для UT2004 очень качественные, их в самой игре довольно-таки много, да ещё и большое community. Для Doom3 такого количества моделек нет.
С успешностью не поспоришь. Не смотря на то, что я не большой фанат творения Тима Суини, раньше (да и сейчас, с выходом udk) знакомым 'энтузиастам' жаждущим творчества советовал именно Unreal Warfare 2. Но успешность еще не значит предельную технологичность о которой ты столько писал Имхо это больше доступность (инструментарий, восприятие и прочее), мастшабируемость. Реклама в конце концов К слову, а на твой мод посмотреть можно ? Source engine: я посмотрел "утёкшие исходники" - там скелетная система вроде старая, из 1го HL. Я как-то смотрел, какие бы ещё модельки поддержать в "своём" quake - от Half-Life отказался. Там одна моделька = один скин. Да и в сети моделек то ли нет, то ли мало ...
Так глубоко 'исходники' hl2 не изучал, ничего не могу сказать. Другое дело, что там были осколки и от hl1 и от cs (не сурс). Может быть они тебя сбили с толку. На счет первого hl по моему да, один. А вот сурс не выглядит на 'один скин' Doom3 ... 1) мне не нравится текстовый формат моделек и анимации 2) в сети мало моделек 3) в UT2004 модельки покруче Мне наоборот это нравилось Хотя душа у меня не лежала к yacc'ам-flex'ам-bison'ам (порочная практика, знаю, даже немного стыдно ), а потому простейшие анализаторы-парсеры писал сам. В Quake Wars модельки уже прекомпилированы. Чего уж греха таить, Doom 3 мне вообще нравился. Из минусов слабая система материалов. Из плюсов быстрая унифицированная система освещения (а может грамотная работа дизайнеров ? ). Стенсильные тени меня вполне устраивали Что значит покруче ? Полигонов побольше ? Как мне кажется низкая детализация Doom 3 моделей кроется в двух словах - теневые объемы и филрейт Да и с нормал меппингом ничего так смотрятся вроде Да, я смотрел open-source разработки. Что-то там мне не понравилось, уже не помню. Хотелось посмотреть как работает анимация в коммерческом продукте. Конечно, видел и разные статейка на gamedev-сайтах. Это, извиняюсь, "детский лепет" по сравнению с техниками, используемыми в современном UE3.
Хочется конкретики. Я не очень понимаю, что такого столь революционного можно придумать сейчас. По возможности статические вершинные буферы в видеопамяти без зеркалирования, скиннинг на gpu ну и, возможно, распаковка входных упакованных данных в шейдере. Оно ? Время садиться за perfhud ? Где-то на отечественном gamedev-сайте видел информацию, что вроде "Герои" содержат очень много анимации и её компрессия идёт несколько часов. Я, как человек, видевший исходники "Героев", могу сказать - анимация там никакущая (по коду), а "часы на компрессию" - это чисто проблема плохих идей и кодинга К своему стыду я даже не понимаю о каких героях речь А что значит компрессия анимации ? Как это выглядит на этапе разработке и собственно в процессе рендера ? Такого понятия, как "формат", в UE нет. От версии к версии движок дорабатывается, появляются новые возможности, иногда убираются старые. Есть определённые идеи - как хранить модель (mesh) в пямяти для быстрого рендеринга на GPU, как хранить анимацию и т.п.
В md5 формат очень неоптимальный - нет компрессии анимаций, вроде есть избыточная информация для mesh.
Пожалуй это я внес путаницу. Одно дело формат, другое дело возможности рендера исходя из данных, сохраненных в файле(ах) содержащих собственно меш и анимацию. Как нет понятия "формата" ? Должны же быть какие то спецификации и стандарты. Не /dev/random же там Опять тот же вопрос относительно оптимальности хранения модели. Что в ue3 такого особенного ? Ну для хранения возможно не оптимальный. Но ведь это никак не характеризует внутренние структуры рендера. И снова это страшное 'компрессия анимаций' В Unreal Engine это называется Root Motion. Аниматор анимирует манеру перемещения персонажа как анимацию корневой кости, а движок потом эту анимацию изымает и отправляет в физику, а моделька анимируется на месте. Альтернатива - делать анимацию бега на месте и задать определённую скорость бега в игровом мире. Спасибо ! |
|
|
|
|
12
|
Русскоязычный Форум / Unreal-кодинг / Околодевелоперские байки :)
|
on: February 08, 2010, 16:01
|
|
Доброго дня.
Преамбула. Изначально хотел выяснить несколько вопросов для себя лично. Однако после общения с уважаемым gildor'ом было принято решение вынести общение на всеобщее обозрение. Может кому-нибудь тоже покажется интересным. А может кто поправит-дополнит-объяснит.
Почитал форум. Я так понимаю Unreal Warfare в 2007 году был выбран чисто эмпирически ? Ведь были же ещё и Doom3 с его md5, Source с его богатыми традициями еще с hl1 (не смотря на то, что ножки у hl1 растут из quake, ни о какой кейфрейм анимации в hl1 речи уже не шло вроде бы). В конце концов были и open source наработки. Помню некий проект под названием cal3d если мне память не изменяет.
Сейчас, я так понимаю, у тебя уже есть опыт работы и с md5. Есть ли принципиальные плюсы и минусы того или иного формата ?
ps Детский вопрос отвлеченно от Unreal Engine. Я когда закончил ренедер моделек md5 обратил внимание, что, скажем, при анимации ходьбы модель меняла положение в пространстве. Это так задумано или это был мой недосмотр ? Они что, компенсируют это перемещение в игре ?
|
|
|
|
|