Выпустил первое крупное обновление Dagon после стабильного релиза — 1.1.0. В этой версии исправлены некоторые баги, добавлен модуль проверки столкновений в 2D и в целом несколько упрощена работа с 2D-играми. Во всех встроенных шейдерах сабрутины GLSL заменены на ветвления для лучшей совместимости со старыми видеокартами. Стартовала работа над редактором сцен для движка.
К этому релизу я приурочил выпуск переиздания моей старой игры 2048×2 — версии популярной головоломки 2048 для двух игроков. Игра портирована на Dagon, что обеспечило поддержку x86_64 и улучшило качество рендеринга шрифтов. Также я добавил переводы игры на немецкий, французский, испанский, португальский и другие языки. Графический стиль и механика не изменились.
Сборку для Windows можно скачать тут, исходники и linux-версия будут на днях.
В предыдущем посте я уже писал о том, почему glTF нельзя использовать в качестве полноценного формата игровых ассетов, и вот альтернатива, которую я специально проектирую для Dagon 2.0 — Dagon Asset Format, сокращенно DAF.
DAF хранит, в первую очередь, вершинные буферы для прямой передачи в VRAM. Формат бинарный, архитектурно соответствующий API Dagon 2.0 и расширяемый: в нем могут быть объявлены любые дополнительные структуры данных и даже динамические свойства, не ломая обратную совместимость.
Основные задачи формата:
Хранение данных в форме, подходящей для прямой загрузки в видеопамять без накладных расходов на обработку (zero overhead). В отличие от glTF, в DAF вершинные буферы имеют фиксированный формат, согласованный с пайплайном движка, не требуя конверсии;
Максимальная эффективность десериализации. glTF требует парсинга JSON и динамического построения довольно сложных объектов в памяти (списков, словарей), а загрузка DAF – это просто реинтерпретация слайсов байтового буфера в массивы POD-структур. DAF экономит память и сокращает риск утечек, поскольку не требует множества аллокаций;
Частичная десериализация. Декодер может читать из DAF только те данные, которые ему нужны, не разбирая остальные.
Формат «все в одном». Файл DAF может хранить как отдельный меш, так и целую сцену. Все структуры формата поддерживают пользовательские свойства, что позволяет хранить в DAF метаданные редактора. Фактически, DAF может быть использован как простая NoSQL база данных для различных целей.
Поддержка семантики данных. Все объекты имеют список классов, что позволяет движку группировать их для задач игровой логики. Все текстуры помечаются как baseColor, normal, height, roughness-metallic, emission, для того, чтобы движок мог выбрать оптимальный BCn формат сжатия.
Поддержка данных для физики и проверки столкновений (в разработке).
В Dagon 1.0 я очень много времени потратил на поддержку этого монструозного формата моделей, и спустя пять лет работы с ним у меня не осталось ничего, кроме разочарования. Главный вывод: glTF — не для игровых ассетов (т.е. карт и отдельных переиспользуемых моделей). Это формат, предназначенный исключительно для просмотра, причем в основном в браузере, на WebGL, при помощи вьюверов типа Sketchfab. В этом он свою задачу выполняет, хотя и тоже неидеально. Но то, что его все начали использовать как формат обмена данными между программами моделирования и игровыми движками — это фундаментальная ошибка, которую я и сам по наивности допустил. Ниже мой личный список недостатков glTF, актуальных, прежде всего, в контексте игрового рендеринга.
Трансформация нод в glTF хранится либо в виде комбинации позиции, поворота и масштаба (TRS), либо в виде матрицы 4×4. Такая вариативность сильно усложняет игровую логику, так как без декомпозиции матрицы обратно в TRS вы не можете ничего анимировать. Декомпозиция — задача нетривиальная, у нее нет стопроцентно надежных решений, и это делает glTF-сцены в общем случае неподходящими для интерактивных приложений. Намного оптимальнее всегда хранить трансформацию в виде TRS и конвертировать в матрицу в движке, что является простейшей задачей.
Нефиксированный лейаут вершин — то есть, физическое расположение атрибутов в общем массиве данных может варьироваться от одного меша к другому, равно как и формат чисел в буферах. Это совместимо с OpenGL/WebGL, но очень плохо для низкоуровневых API, где формат вершин фиксирован на уровне PSO и не может меняться в проходе. Движок вынужден конвертировать буфер в свое внутреннее представление, что убивает саму идею формата — прямую загрузку данных в видеопамять без препроцессинга.
Поддержка моделей без некоторых атрибутов — например, без текстурных координат или нормалей. В игровом движке не может быть такого, что нормали отсутствуют, для PBR-пайплайна их все равно нужно предоставить шейдеру. Поэтому отсутствующие атрибуты приходится генерировать — а как это делать, glTF не регламентирует, приходится изобретать свою логику. Это, опять-таки, противоречит идее «эффективного GPU-формата».
Кости для скелетной анимации определены как обычные ноды сцены, хотя они логически принадлежат не сцене, а отдельному виду объектов — собственно скелету. Скелет не вставляется в граф сцены, а используется как источник данных для построения pose-матриц для каждой индивидуально анимированной модели в сцене. То есть, с точки зрения архитектуры движка, glTF-подход к скелетке очень далек от эффективного решения несложной в принципе задачи.
Поддержка отрицательного масштаба. Для рендеринга это зло, потому что меняет winding и влияет на отбор видимости. Иногда при рендеринге это используется целенаправленно, но в форматах 3D-моделей практически всегда приводит к проблемам совместимости.
Использование web-first форматов текстур — PNG и JPEG. В AAA-движках эти форматы практически не используются из-за того, что они требуют декодирования на стороне CPU. Кроме того, для игр с большими мирами жизненно важно блочное сжатие текстур, это индустриальный стандарт. А с glTF получается, что нужен отдельный этап декодирования и сжатия изображений в GPU-френдли форматы. Это может и не быть большой проблемой, если движок поддерживает такой процесс, но все равно возникает много сложностей. Основной вопрос — в какой формат сжимать? Если это base color, то, конечно, достаточно BC1/BC3 (в зависимости от наличия альфа-канала), но для карт нормалей уже желателен BC7, а для черно-белых изображений эффективнее BC4. glTF никак не регламентирует семантику текстур, она определяется на уровне материалов, что в общем случае не позволяет реализовать полностью автоматический алгоритм выбора формата.
В общем, для Dagon 2.0 я обязательно буду пилить собственный формат ассетов, учитывая весь этот опыт. Поддержка glTF сохранится благодаря библиотеке Assimp, но формат больше не будет позиционироваться как основной.
За последние недели значительно продвинулся с портом: реализовал в Dagon 2 загрузку glTF (через библиотеку Assimp), обновил шейдер антиалиасинга, добавил цветокоррекцию и поддержку 3D-текстур, проделал множество мелких улучшений в рендере.
Модель — Datsun 280Z от Martin Trafas (бесплатная).
Как и планировал, сумел победить зашумленность отражений при помощи накопления данных с предыдущих кадров (с репроекцией по motion-векторам для компенсации медленного движения камеры):
Это решение также неплохо сглаживает шум, вызванный неоднородностью нормалей:
При резких движениях, конечно, репроекция не спасает, приходится сбрасывать историю, и шум возвращается. И, конечно, экранная трассировка — это аппроксимация, у нее всегда будут видимые артефакты в виде пустот там, где сэмплинг невозможен ввиду недостатка информации в буферах. Но результат вполне, как говорится, shippable — мне кажется, у меня получилось даже лучше, чем во многих коммерческих играх. Во многом, это благодаря использованию GGX importance sampling: распределение лучей очень близко к тому, что делается для префильтрации кубических карт под PBR.
Реализацию этого эффекта я в свое время отложил до выхода первой версии движка, и вот, наконец, пришло время за нее взяться. SSLR (screen-space local reflections) — это расчет отражений в пространстве экрана, упрощенная разновидность трассировки лучей. Берется HDR-буфер, буферы глубины и нормалей и в каждой точке выстреливается луч в направлении зеркального отражения поверхности. Луч делится на сегменты, и каждый сегмент последовательно проверяется на попадание в геометрию (путем сравнения Z со значением из буфера глубины). Если попали, то читаем цвет, соответствующий по экранным UV-координатам точке попадания.
На низких уровнях шероховатости результаты получились неожиданно качественные. На высоких, конечно, присутствует шум, который я планирую смягчить темпоральной аккумуляцией.
Разработка Dagon 2.0 началась в весьма бодром темпе. Deferred-рендер уже почти готов — остались только тени PSM и DPSM, поддержка локальных зондов освещения и forward-проход. Я добавил систему кэширования ресурсов, сжатие в BC7 (на основе компрессора bc7enc Рича Гелдриха) и проделал еще множество мелких улучшений на разных стадиях формирования кадра. Особое внимание я уделил тому, чтобы картинка соответствовала Eevee в Blender 5.
Что еще нового? Часть функциональности, которая в Dagon 1.0 реализована в качестве расширений, теперь входит в ядро — это физика на базе Jolt и загрузчик текстур в формате KTX/KTX2. Такое решение я принял исходя из полезности этих фич, простоты сборки Jolt и libktx из исходников и их автономности: они не имеют собственных зависимостей и отлично работают на всех платформах (в противовес тому же Newton, который имеет проблемы с работой некоторых функций под Linux). Наличие libktx «из коробки» дает серьезные преимущества и ставит Dagon 2 в авангард движкостроения; в будущем не исключен перевод текстурного кэша с DDS на KTX2.
Еще одним нововведением будет встроенная VM GScript3, которую я разработал в прошлом году. Движок при старте загружает скомпилированный байт-код скрипта и выполняет его, а скрипт, в свою очередь, навешивает обработчики событий, позволяя, таким образом, выполнять внешнюю логику без пересборки игры. Игра может экспонировать скриптовой системе свои данные и методы, что полезно для создания модов. Некоторые встроенные классы Dagon уже реализуют интерфейс GsObject и напрямую совместимы с GScript: это Entity, Scene, World, BaseGame.
Зарегистрирован пакет dagon2 в реестре DUB, так что начать пользоваться можно уже сейчас, несмотря на то, что разработка находится на ранней стадии.
Рад сообщить, что наконец-то выпустил Dagon 1.0.0, первый стабильный релиз моего игрового движка! Это в основном исправляющий релиз, который подытоживает огромную работу над Dagon, которую я проделал за последние два года.
Исправлен баг с неправильным сэмплингом BRDF LUT, что ранее приводило к излишней яркости шероховатых поверхностей. Исправлен эффект тумана для точечных источников света. Улучшена система частиц. Добавлено свойтсво Emitter.fadeInDuration для плавного появления частиц из прозрачности, а также Emitter.gravity для управления гравитацией частиц. Свойство Emitter.initialPositionRandomRadius теперь является вектором и называется Emitter.initialPositionRandomRadii — это радиус-вектор, позволяющий задать разброс случайного появления частиц отдельно по всем трем осям. Добавлен новый тип событий CustomResize, который используется в тех случаях, когда пользовательский код должен обрабатывать кастомный ресайз вьюпорта (обычно это необходимо, если размер вьюпорта не привязан жестко к размеру окна и вычисляется другим способом). Также менеджер событий теперь обрабатывает SDL_WINDOWEVENT_CLOSE для грациозного закрытия игры при нажатии Alt+F4. Добавлен новый метод Application.isWindowMinimized. Добавлен новый режим воспроизведения анимации для GLTFBlendedPose — PlayMode.OnceAndStop. Он позволяет проиграть анимацию один раз и остановиться на последнем ключевом кадре. Добавлено новое свойство GLTFBlendedPose.timeScale для управления скоростью анимации. Добавлено свойство Light.angularRadius, которое симулирует солнечный диск угловым радиусом распределения света. Улучшен шейдер ночного неба StarfieldSkyShader: добавлены свойства sunEnergy (энергия светила), spaceColorZenith (цвет пространства в зените), spaceColorHorizon (цвет пространства на горизонте). Добавлено новое свойство FirstPersonViewComponent.roll — поворот камеры от первого лица по оси Z для эффекта наклона головы вбок. В расширении dagon:jolt добавлена поддержка convex cast (JoltPhysicsWorld.shapeCast). Контроллер персонажа JoltCharacterController теперь использует shapeCast в логике приседания (для проверки высоты потолка над головой). Как следствие, персонаж теперь автоматически приседает, чтобы избежать врезания головой в низкие потолки. Добавлен метод onGround, который возвращает true, если персонаж стоит на земле. Исправлена компиляция расширения dagon:nuklear.
Реализовал в Dagon 2.0 улучшенный SSAO с темпоральной аккумуляцией: сэмплы накапливаются во времени, смешиваясь с данными с предыдущего кадра, что позволяет значительно снизить количество сэмплов на кадр. Эта фича лучше всего себя показывает в статичных сценах, где камера не движется. Вес смешивания между текущими данными и предыдущими пропорционален скорости пикселя в экранном пространстве, поэтому при быстром движении аккумуляция сбрасывается и возрастает зашумленность, а при медленном происходит репроекция, и качество картинки не страдает. Дополнительным преимуществом является то, что можно не использовать билатеральную фильтрацию, что еще сильнее снижает покадровую нагрузку и избавляет от неприятных светлых ореолов по краям объектов.
На скриншоте ниже используется всего 5 сэмплов на кадр: