Дядя Миша

Хочу извиниться за долгое отсутствие постов, всё это время активно шла подготовка к выпуску бета-версии, правки, тестирование, написание документации, внутреннее тестирование с командой разработчиков Meanwhile In Russia и вот наконец я готов показать вам, что уже имеется на текущий момент. В процессе подготовки беты меня не оставляла мысль, что Boosty абсолютно не подходит для такого формата. Здесь очень неудобное общение. А при тестировании обычно пишут большие посты, что-то спрашивают, предлагают. Всё это было бы очень неудобно осуществлять прямо тут. К тому же моя политика предполагает, что если человек купил наивысший уровень доступа хотя бы один раз на месяц, то он остаётся в рядах бета-тестеров на всё время разработки. На Boosty, понятное дело, проходит месяц и тексты снова становятся недоступными. Это идёт вразрез с моими планами. Поэтому я решил осуществлять бета-тестирование XashNT на закрытой ветке форума https://hlfx.ru/forum/ т.е. на нашем форуме. Ветка с бета-тестированием изначально никому не видна и попасть в нее можно только с моего личного одобрения. Поэтому принцип доступа к бета следующий:

1. Вы оплачиваете наивысший уровень доступа - 1000 р\мес. Можно купить подписку всего на 1 месяц и вы будете включены в число бета-тестеров.

2. регистрируетесь на https://hlfx.ru/forum/ (там на данный момент включена премодерация, поэтому не ждите мгновенного подтверждения со стороны форума, от вас достаточно самого факта регистрации). Если вы уже зарегистрированы у нас - тем лучше.

3. в комментариях к этому посту оставляете ник, под которым вы зарегистировались на https://hlfx.ru/forum/.

4. В течении нескольких часов я аппрувлю ваш аккаунт и даю доступ к закрытой ветке.

5. Вы становитесь полноправным участником бета-тестирования и получаете доступ к последующим версиям.

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

ЗЫ. Вероятнее всего в ближайшем времени я уберу уровни подписки 100 и 500 рублей и оставлю только один, т.к. по технологиям движков предложений практически не поступает, всех интересует именно разработка XashNT, а 100 рублёвый доступ дублируется телеграм-каналом, т.е. в нём попросту нет никакого смысла.

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

Итак, что было сделано за прошедший месяц:

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

2. создан формат спрайтов, активно использующий возможности Uniform mesh (что это такое, вы можете узнать, купив улучшенную подписку).

3. отдавая себе отчёт, что потенциальные пользователи движка (по крайней мере на первых порах), это люди "застрявшие во времени", т.е. в тех славных временах, когда мы делали карты под CS 1.6 и TFC в начале нулевых и вероятно с тех пор, сохранивших тёплые чувства, по безвозвратно ушедшему времени, я так же написал конверторы моделей и спрайтов из формата GoldSrc в формат Uniform Mesh. В дальнейшем я вероятно напишу подобные конверторы и для ресурсов остальных движков семейства Quake, но в каком-то смысле я писал их и для себя тоже. Ведь мне всё это предстоит на чем-то тестировать по ходу разработки.

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

5. В настоящее время идёт сортировка ресурсов для карт-примеров.

Следующим на очереди - написание документации, внутреннее бета-тестирование и наконец публичное. Надеюсь, что уже в этом месяце.

Когда с определением видимости вопрос был более или менее закрыт, встал вопрос о типе используемого дерева для отсечения видимости. Впрочем, на этот вопрос я уже много лет отвечаю однотипно - только BSP. Его объявили нежелательным примерно с 2002-го года, когда игровые движки начали постепенно уходить от брашей к полигональной геометрии, после чего мы увидели Doom3 и Half-Life 2, еще с использованием BSP-дерева, а так же все игры на UE3. В 2006-2007-м году вышли Сталкер и Кризис, в которых BSP-дерево уже не использовалось. На самом деле рекомендации по нежелательности использования BSP-дерева основаны на буквальном его способе использования, который применялся в Quake1. Когда абсолютно вся геометрия проходит сквозь дерево и каждый полигончик ложится точно на ноду. Дерево при этом получается чудовищно избыточным и его размер может запросто превышать размер геометрии, которую оно индексирует. Естественно, что такой подход вместо оптимизации, наоборот сделает только хуже. Однако уже с Quake2, Кармак ввёл понятие т.н. детальной геометрии, т.е такой, которая не участвует в разбиении дерева. На самом деле многое определялось еще и тем фактом, что для коллизии и нахождения видимости использовалось одно и тоже дерево, поэтому постоянно приходилось искать компромиссы. Очевидно, что для физики нам требуется, как раз точное дерево, позволяющее, быстро найти нужный полигон. А для рендеринга - наоборот, найти видимый лист и отправить на отрисовку его содержимое (обычное это большие VBO-мешы).

Второй немаловажный момент заключается в подготовке геометрии. Раньше считалось вполне достаточным пропустить её через дерево и геометрия считалась оптимизированной. Но, как вы понимаете, это условие еще соблюдалось для программного рендеринга, где рисовать следовало как можно меньше. Для аппаратного рендеринга нам нужно стремиться к уменьшению потока данных по PCIex шине. А если при этом и нарисуется что-то лишнее, это уже не так критично. Значит нам нужны большие DIP-ы и минимальное их кол-во. Впрочем, это правило сохраняется для любого современного 3D движка и любой 3D-артист об этом знает. Меньше DIP-ов - выше фпс.

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

1. в дерево вводятся дополнительные секущие плоскости, если размер ноды по одному из измерений превышает какой-то заданный лимит, как правило это 10-15 метров. Таким образом дерево легко адаптируется как к коридорам, так и к ландшафтам, превращаясь на открытых пространствах в подобие регулярной сетки.

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

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

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

Напомню, что XashNT базируется на Xash3D. Это, повторюсь, не значит, что к окончанию разработки, там останется хоть что-то из первоначального кода,

но здорово помогает постоянно иметь под рукой рабочую версию и вести итеративную разработку. К тому же моим потенциальным пользователям в каком-то смысле тоже придётся проделать этот путь, конвертируя ресурсы в форматы, понятные новому движку. Так вот. В Xash3D, поскольку он был совместим c GoldSrc использовался формат уровней BSP30, который в свою очередь вырос из формата BSP29 от первого Quake. Отличие у этих форматов было только одно: в Half-Life использовалось цветное освещение. В принципе разработка нового движка у меня неоднократно срывалась как раз вот по этой причине - не хватало опыта и знаний для разработки нового формата уровней. Использовать старый формат не имело смысла, как потому что, тогда, получившийся

продукт уже нельзя было назвать новым движком (движок новый, а проблемы старые), так и по ряду фундаментальных причин, перечисленных ниже:

1. Слишком подробное BSP-дерево. Дерево, которое стремится уложить каждый полигон на ноду. Из-за этого размер дерева фантастически распухал даже для не слишком сложной (по современным меркам) геометрии, обход дерева стремился по времени к линейному обходу всех полигонов, то есть в нём просто исчезал смысл. Однако, поскольку, на это дерево было завязано практически всё, как в движке, так и в компиляторах, его нельзя было просто выбросить или заменить другим типом дерева.

2. Геометрия, оптимизированная, для программного рендеринга. Оптимизировать геометрию для видеокарт начали уже в 1999-м году, первым был Кармак с Quake3. Quake1 был сделан еще в то время, когда 3DFX еще находился в противозачаточном состоянии. Вполне естественно, что это сильно повлияло на выбор форматов, для хранения данных. С одной стороны это позволило их неплохо сжать в дисковом файле (экономия памяти во главе угла), с другой это был максимально недружелюбный для видеокарт формат. Полигоны с произвольным кол-вом рёбер, текстурные матрицы. Всё это приходилось налету преобразовывать в треугольники. Из-за того факта, что вертексы индексировались как позиция в пространстве без учёта текстурных координат и лайтмапы, она просто исчезала при загрузке в видеопамять - никто не хотел индексировать вертексы на лету, поскольку это могло сильно замедлить скорость загрузки уровней. Да и сам подход к построению лайтмап (один полигон = один кусочек атласа), в принципе не позволял говорить о сколь-либо эффективной индексации вертексов. Максимум, на что можно было рассчитывать - это два треугольника одного полигона, которые в исходном формате были квадратом стороны одного браша.

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

Дело в том, что движок писался на основе Xash3D, просто для того, чтобы на каждом этапе разработки иметь валидный набор данных для экспериментов. Потихоньку старый код заменялся новым, но на данный момент в движке присутствует зоопарк форматов моделей:

BSP32 - формат на базе BSP30 от Half-Life с увеличенными лимитами

BSP46 - Ванильный формат от Quake3

BSP48 - промежуточный экспериментальный формат, полученный в процессе разработки и более неактуальный

MESH - финальный формат статической геометрии для уровней

STUDIO - формат скелетных моделей из Half-Life

Все эти форматы, будучи загруженными используют общие структуры для хранения данных в памяти, причём очень многое плотно завязано именно на древний BSP32, порядка 70%. Когда я выкину эти, уже ставшие ненужными форматами, движок подвергнется масштабной реорганизации, с целью упрощения, оптимизации хранения данных и уменьшению потребления памяти, так же будут пересмотрены многие интерфейсы. Очевидно надо просто убрать поддержку BSP32. Это дело пяти минут, загрузчики изолированы друг от друга, но. Всё дело в том, что в моём новом формате до сих пор не реализован radiosity в лайтмаппере. А для успешной имплементации неплохо бы иметь референс в виде старого формата где освещение с индиректом, чтобы была возможность сравнивать (в идеале освещение должно полностью совпасть). Так что, пока radiosity не имплементирован, было бы желательно сохранить поддержку старого формата. Внедрять новый формат скелетных моделей на старые структуры, попросту означает проделать двойной объем работы, неизвестно какие еще ошибки при этом вылезут, когда код пишется под одни условия, а потом приходится всё переделывать. Но с непрямым освещением у меня был затык, его не так-то просто рассчитать для больших уровней. Приходящие в голову мысли я заведомо отбрасывал, у меня попросту не было идеи. И вот буквально сегодня утром я понял как это реализовать, сохранив оптимальный баланс по производительности и потреблению памяти. Таким образом список задач на текущий момент следующий:

- внедрение непрямого освещения в лайтмаппер

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

Низкоуровневая часть системы материалов

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

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

Таким образом механизм выглядит так: материал->шейдер->материал. Это означает что механизм задаёт первичные условия, необходимые для компиляции шейдера, определённые пользователем. Далее, по результату компиляции, уже сам шейдер требует для своей работы определённый набор юниформов, текстурных юнитов и аттрибутов геометрии. Что именно ему требуется мы можем узнать, сделав запрос к драйверу. Это хороший путь к оптимизации, потому что мы не передаём юниформы, которые не требуются шейдеру, мы не загружаем в видеопамять текстуры, которые остались невостребованными, наконец мы имеем возможность гибко перестроить VBO-буффер, исключив из него те атрибуты, которые не требуются (да в XashNT такая возможность тоже присутствует). В конечном итоге это очень сильно экономит видеопамять и полностью контролируется

пользователем. Как всё это выглядит на практике:

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

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

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

По крайней мере на этапе ввода-вывода. То что внутри всё фундаментально отличается, вполне естественно, т.к. на дворе 2021-й год.

Но вот какой вопрос интересный встал - надо ли сохранять оригинальные расширения форматов файлов, напомню, что сейчас они .bsp для уровней и .mdl - для анимированных моделей. Теоретически это может ввести пользователя в заблуждение и он сделает вывод, что в движке так ничего и не поменялось, вон даже расширения файлов прежние. Другой негативный момент связан с тем, что эти файлы могут быть ошибочно восприняты как ресурсы для тех старых движков. Но если делать другие расширения, то какие выбрать? Напрашивающиеся "модные" .level и .model уже наверняка заняты в каких-то других движках, это тоже может создать путаницу определённого рода. Делать явную отсылку к имени движка в расширении мне тоже не очень хочется, просто не люблю такое.

Так что я решил обратиться к помощи моих подписчиков. Нам надо придумать два расширения форматов файлов - для анимированных моделей и для моделей уровня. Что посоветуете?

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

Итак, система материалов. Для любого современного движка её концепция является чуть ли не главным компонентом системы, поскольку от нее напрямую зависят возможности, которые движок предоставляет пользователю. Разверну свою мысль. Независимо от наличия исходников, гибкость движка в первую очередь определяется тем, что может с ним сделать пользователь, обладающий минимальной квалификацией в области программирования. Художникам и дизайнерам в любом случае приходится расширять свои навыки, например писать плагины на скриптовых языках для редакторов, возможно что и составлять шейдеры. Но на этом их пределы компетенции и оканчиваются, что разумно. Если человек начнёт углубляться в технические дебри, у него просто не останется времени для, собственно, творчества. Какие-то игровые объекты на уровнях (если это конечно не NPC со сложным поведением), обычно удовлетворяют достаточно примитивному логическому набору условий и могут быть созданы дизайнерами логики игры на каком-либо скриптовом языке, используя визуальные редакторы.

Этот подход в сфере игровых движков давно отлажен и вопросов не вызывает. С системой материалов всё сложнее, этот механизм в первую очередь затрагивает принципы аппаратной растеризации и хранения данных в видеокарте, на 100% абстрагироваться не получится, даже спрятавшись за драйвером видеокарты и прослойкой в виде системы материалов. К тому же, поскольку таковая система обычно затрагивает всю архитектуру, в ней может таиться принципиальная невозможность реализации каких-либо вещей, неочевидная разработчику на первый взгляд. Со всем этим приходится сталкиваться уже пользователям. К тому же концепция может поменяться вместе с версией движка, а ведь совокупность материала с текстурами и шейдером представляет собою ассет, который вполне может продаваться в виртуальном магазине за вполне реальные деньги. И вот с обновлением работа дизайнера превращается в тыкву. Есть еще один немаловажный момент - язык описания материала. Если он слишком прост, то у такой системы скорее всего будут большие ограничения. Если он сложен - повышается порог вхождения. Язык может изобиловать избыточным синтаксисом, что автоматически делает пригодным для редактирования только через визуальный редактор.

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

Планируемые технические характеристики и особенности движка:

- Движок для 3D игр, основной упор делается на FPS, однако при некоторой доработке так же годится для TPS, 2D игр, теоретически может быть пригоден и для стратегий, однако объем работ по изменению пользовательской части вырастет пропорционально. Ядро остаётся прежним.

- Освещение: только лайтмапы, лайтмапы в сочетании с динамикой, чистая динамика. На усмотрение пользователя.

- Нагрузочная способность: до 10 миллионов полигонов в кадре. В основном зависит от видеокарты и сложности шейдеров. На данный момент имеется система авто-лодов, планируется введение системы импосторов.

- Сетевая поддержка: UDP-соединение, возможность создания кастомного протокола средствами пользовательской части.

- Физическая симуляция: физика твёрдых тел, физика тряпичной куклы, плавучесть объектов. На стороне видеокарты также возможна симуляция тканей и жидкости.

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

- Собственный редактор уровней с возможностью работы с примитивами (брашы, меши, кривые Безье)

- Система материалов без языка описания. Язык описания материалов формируется пользователем.

- Двухуровневая пользовательская часть. Бакэнд на С++ и игровые объекты на скриптовом языке.

- Полный набор утилит окружения для компиляции, миграции и просмотра ресурсов.

- Меню, базирующееся на собственном оконном менеджере, без использования сторонних библиотек

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

Технически локация может быть оформлена как единая геометрическая модель с естественными преградами - ограничителями игровой зоны.

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

Что в свою очередь делает наличие механизма бесшовной смены уровней второстепенной задачей. Это особенно актуально для одиночных игр, где каждый уровень представляет собой отдельную главу в повествовании. Пример такого подхода - Metro Exodus. Возврата на предидущие уровни

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

Условно-бесшовная смена уровня, насколько мне известно, впервые появилась в игре в Half-Life, где игрок мог возвращаться в те места, где он уже побывал и видеть, что там действительно ничего не поменялось - убитые NPC по прежнему лежат на своих местах, даже лужи крови на месте. Такой механизм безусловно сложнее в реализации, но как вы понимаете, раз уж его смогли сделать еще в далёком 98-м году, ничего принципиально невозможного там не было. Основной вопрос, обычно, заключается в том, какие объекты нам непременно следует сохранить, а какими можно пренебречь. Стоимость сохранения объектов не в последнюю очередь зависит от размера данных, которые должны быть сохранены, как и важности самих объектов. Так, например, часть трупов может просто исчезать после смерти, а часть останется лежать навсегда.

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

слишком расточительно и не имеет смысла даже в настоящее время.