Обновление от 26.08.05

Прокомментировать Просмотры: 0

Изменения главного меню

Обновление от 26.08.05

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

Список друзей

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

Открыть видео

Режим стримера

В платформу добавлен новый параметр — Режим стримера. При его активации все игроки (включая вас) получают случайные обезличенные никнеймы и автоматически сгенерированные аватары.

Обратите внимание, что эта функция работает «из коробки» далеко не во всех играх. Разработчикам необходимо проверять значение Preferences.StreamerMode, чтобы гарантировать, что сетевые данные игроков и их аватарки не передаются при включенном режиме у клиента.

Миниатюры для подключаемых карт

Теперь карты из поддерживаемых сторонних игр поставляются с собственными миниатюрами, что делает процесс выбора значительно приятнее. Приятной игры! 😎

Если вы создаете собственную интеграцию карт, класс SceneLoader теперь реализует интерфейс IThumbnailProvider, загружая превью по пути /thumbs/{Host.Ident}/{RelativePath.WithExtension( ".png" )}. Вы можете массово сгенерировать их с помощью консольной команды mount_generatgeneratethumbs, которая делает снимок экрана с игрового объекта с тегом map_preview либо использует точку спавна игрока в качестве резервного варианта.

Ускоренная загрузка пакетов

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

Мы увеличили лимит параллельных загрузок с 16 до 64 и перешли на протокол HTTP/2. Теперь файлы скачиваются через общее число соединений вместо открытия 64 отдельных сокетов. Небольшие файлы теперь загружаются примерно в два раза быстрее.

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

Игровые иконки ввода и улучшения

Добавлена поддержка современного контроллера Steam, и теперь в нашем распоряжении имеется уникальная библиотека графических иконок как для Steam Deck, так и для геймпада. Заодно была реализована поддержка контроллеров Switch Joy-Con.

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

Vulkan 1.3

Мы повышаем минимальную поддерживаемую версию графического API Vulkan с 1.2 до 1.3. Хотя это может показаться серьезным шагом, мы не ожидаем, что это затронет подавляющее большинство игроков или существенно изменит системные требования.

По сути, это соответствует новым минимальным спецификациям Minecraft, что мы считаем вполне разумным стандартом.

Переход на Vulkan 1.3 обеспечивает более чистую и надежную основу для рендеринга, позволяя задействовать функции, которые уже стали стандартом на современном «железе». Для почти каждого игрока ничего не изменится: не нужно настраивать новые графические параметры, производительность останется на прежнем уровне, а обновление ПК не требуется.

Модернизация Vulkan

Мы начали процесс обновления принципов использования API Vulkan.
Изменения скрыты «под капотом», однако это позволило избавиться от большого объема устаревшего кода и предоставить видеодрайверу более точные данные для работы.

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

Использование VK_KHR_dynamic_rendering стало обязательным, что позволило полностью удалить старые пути рендер-проходов и фреймбуферов.

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

Компилятор шейдеров Slang

Мы отказались от компилятора DXC в пользу Slang — аналогичного инструмента, который используется в актуальной версии Source 2.

Никаких проблем с совместимостью существующих шейдеров возникнуть не должно, поскольку Slang полностью обратно совместим с HLSL и при этом предлагает следующие преимущества:

  • Сокращение времени компиляции шейдеров до 25% при сохранении идентичного кода HLSL (показатель можно дополнительно улучшить с помощью модулей, дженериков и интерфейсов).
  • Поддержка Intellisense через расширения для Visual Studio и VSCode (которые мы уже активно используем).
  • Дженерики и интерфейсы, уменьшающие количество вариаций шейдеров и позволяющие масштабировать крупные кодовые базы с помощью модульного программирования.

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

DLSS

Мы внедрили новый алгоритм апскейлинга DLSS наряду с FSR3. Это опциональные методы масштабирования, основанные на ретроспективном анализе кадров, поэтому они могут вызывать незначительные шлейфы и артефакты изображения. Генерация кадров не поддерживается, и добавлять ее в планы не входит.

Исправления апскейлеров

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

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

Зеркальный блеск (Specular) теперь включен по умолчанию для сложных шейдеров

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

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

Повлияет ли это на мои ассеты? Скорее всего, ваши материалы НЕ изменятся, и игры будут выглядеть привычным образом. Тем не менее, возможны редкие исключения, когда внешний вид материалов *может* измениться, но только при одновременном соблюдении следующих условий:

  • В настройках материала ранее была отключена функция «Specular».
  • Не была задана текстура шероховатости (roughness), вместо нее использовалась стандартная со значением по умолчанию 0.5.

В подобных ситуациях модели могут приобрести неестественный пластиковый блеск. Проблема решается за пару секунд — достаточно установить значение шероховатости в настройках материала на 1.0 либо подключить корректную текстуру шероховатости.

Поддержка тонирования для шерстяных шейдеров

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

Кэширование статических теней

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

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

Исправления прозрачности волос

Мы используем технологию Alpha-to-Coverage для обеспечения независимой от порядка отрисовки прозрачности, но этот метод работает только при включенном сглаживании MSAA. Без MSAA движок переключался на прозрачность в стиле сетки-рабицы, что приводило к появлению некрасивых точечных паттернов.

Теперь при отключенном MSAA задействуется альфа-отсечение (alpha clipping). Это означает, что волосы больше не являются полупрозрачными, но при этом полностью исчезает эффект зернистости.

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

Bloom 3

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

Bloom 3 выглядит значительно эстетичнее и проще в конфигурации, напоминая подходы, используемые в современных видеоиграх.

Открыть видео

Раньше мелкие детали повышенной яркости не создавали свечения — теперь эта проблема решена:

Открыть видео

Наши тесты показали, что эта версия работает примерно на 25% быстрее.

Тени

Несколько обновлений назад мы добавили тени в экранном пространстве (Screen-Space Shadows) и теперь планируем постепенно расширять концепцию масок теней (Shadow Masks) — подхода, позволяющего перекладывать часть расчетов теней на вычислительные шейдеры с текстурой в экранном пространстве для их эффективного прореживания и правильного компонования.

Мы полностью переработали внутреннюю логику обработки масок теней, что также устранило задержку в 1 кадр, из-за которой тени в экранном пространстве в VR-режиме рендерились в обратном порядке. Теперь все работает стабильно, а программный интерфейс практически готов к публичному релизу.

Также мы избавились от артефактов при расхождении квадов в тенях. Мы используем метод смещения глубины опорной плоскости (Receiver Plane Depth Bias), который анализирует разницу глубин между соседними текселями карты теней внутри квада для корректировки смещения. Проблема заключалась в том, что порядок расположения карт теней в кваде мог расходиться, выдавая искаженные данные, даже несмотря на жесткие попытки фильтрации.

Мы упростили решение, внедрив подход, аналогичный Unity и Godot: смещение позиции тени рассчитывается на основе размера PCF и нормали поверхности, что раз и навсегда устраняет «зубчатость» теней и проблемы с расхождением квадов.

Объединенные меши в Hammer

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

Это приводит к снижению количества вызовов отрисовки (draw calls) и оптимизации рендеринга статической геометрии.

Эта функция частично перенесена из актуальной версии Source 2, однако в первой версии было решено отказаться от использования мешлетов и GPU-отсечения (GPU culling).

Оптимизация видимости открытых пространств в Hammer

Мы обновили алгоритм объединения кластеров видимости при компиляции карт, заимствовав проверенные настройки из Deadlock.

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

Это нововведение позволяет:

  • Сократить количество избыточных кластеров видимости.
  • Повысить точность расчетов видимости на обширных открытых локациях.
  • Сделать данные о видимости более упорядоченными при компиляции.

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

Зачем обновлять Hammer?

В скором времени в наших сценах появится этап компиляции, использующий объединенные меши и пропсы.

Перенос этих наработок из оригинальной Source 2 в Hammer предоставил нам отличную возможность протестировать их в условиях максимальной нагрузки на статическую геометрию.

Дефектные грани

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

Открыть видео

Временное скрытие граней меша

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

Открыть видео

Интерфейс инструмента примитивов

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

Импорт масштаба с пресетами единиц измерения

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

ModelDoc: автозаполнение текстур материалов по имени

Открыть видео

Мы обновили логику работы ноды DefaultMaterialGroup: теперь она способна автоматически назначать материалы при совпадении их названий. Иными словами, если имена материалов вашей модели совпадают с материалами в проекте, они подставятся автоматически.

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

Помощник будет корректно работать при соблюдении следующих условий: 1) слот материала еще не был заполнен другой функцией (например, по полному пути); 2) название материала уникально, то есть в вашем проекте s&box существует ровно 1 материал с таким именем.

Быстрое создание декалей из контекстного меню

Мы добавили в контекстное меню новую опцию, позволяющую в пару кликов создавать новые описания декалей на основе выбранных текстур. Достаточно выделить одно или несколько изображений в браузере ресурсов, кликнуть по ним правой кнопкой мыши и выбрать «Create Decal».

Движок попытается самостоятельно распределить текстуры по соответствующим слотам. Единственное требование — имена файлов декалей должны содержать стандартные суффиксы на конце: _color, _normal, _rma, _emissive, _height. Например, файл «my_custom_decal_color.png» будет автоматически назначен в цветовой слот.

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

Оптимизация обратных вызовов физических событий

События столкновений теперь обрабатываются значительно быстрее, особенно когда физические тела находятся в состоянии покоя.

Раньше каждое событие требовало отдельного управляемого вызова (managed callback) и четырех дополнительных обратных вызовов к нативному коду. Теперь все события объединяются в один пакет за каждый физический шаг.

Это привело к одному небольшому изменению поведения: события обновления столкновений больше не отправляются для неактивных объектов.

Аналогичная семантика используется для OnCollisionStay в Unity.

Если вам требуется вернуть прежнее поведение, включите параметр PhysicsBody.AutoSleep = false.

Растительность на опубликованных картах

Раньше расставленная кистью растительность некорректно отображалась на опубликованных картах, поскольку ее данные сохранялись на уровне сцены, а не внутри самой карты.

Теперь экземпляры карт могут применять временные переопределения системы игровых объектов (Game Object System). Эти изменения откатываются при выгрузке карты, что исключает риск загрязнения основной сцены специфичными для уровня данными.

Выражаем благодарность пользователю @Pol за внесенный вклад!

Источник

Поделиться:

Похожие статьи

Поиск по играм, новостям и статьям…

Введите не менее двух символов

Введите не менее двух символов