триада WVP (World, View, Projection) так-же перенесены на DSA
Добавлена поддержка нескольких активных сцен (миров)
Добавлен класс камеры
исправлено неопределенное поведение при обновлении трансформации юнита сцены (синхронизация состояний трансформов в начале кадра)
Комментарий
В очередной раз отваливался по рабочим вопросам =/ Но, вроде, вернулся. Чендж лог сегодня очень небольшой по этой-же причине.
Итак, миры и камеры.
Мир определяется рут объектом GameWorld, который хранит все объекты сцены, камеры итд. Камер у сцен может быть сколь угодно много, но активной одномоментно (во всем движке) может быть только одна (дальше будет сделано исключение для RenderTarget камер, но это отдельно). При этом, сцена без активной камеры продолжит свою работу в фоне. Она продолжит тикать, обновляется, пересчитывается. Просто не будет выводится на экран.
Переключение камер происходит функцией Activate соответствующего Юнита.
как пример, каждые 10 секунд мы переключаем активную камеру между первым и вторым акторами
При этом, если камера принадлежит другой сцене, то сцена так-же переключится.
🎯 В игровой индустрии случилось важное событие — компания Epic Games провела ежегодную презентацию State of Unreal.
На этом мероприятии разработчики рассказали о будущем своего главного продукта и показали, над чем они работали последние годы. Главной новостью стал анонс Unreal Engine 6, но и без других интересных заявлений не обошлось.
Напоминаем, что пополнить баланс Steam быстро и без лишних сложностей можно через Dessly.com
👉 Dessly делает процесс пополнения Steam кошелька максимально удобным, быстрым и безопасным!
Unreal Engine 6 — что это и когда ждать
🎯Самой громкой новостью с презентации стал полноценный анонс шестой версии знаменитого движка. Разработчики из Epic Games решили пойти по необычному пути — они объединят UE6 с редактором из Fortnite, который называется UEFN. Это значит, что создатели игр смогут работать в единой среде и выпускать свои проекты сразу на все платформы, включая саму Fortnite.
Главным языком программирования в новом движке станет Verse. Также Epic Games активно интегрирует в UE6 искусственный интеллект. Разработчики смогут пользоваться такими моделями, как Claude и Gemini, которые возьмут на себя скучную рутинную работу. Например, ИИ поможет с настройкой освещения, проработкой уровней, созданием систем частиц и риггингом персонажей. Это позволит командам сосредоточиться на действительно важных задачах — творческих и технических.
Правда, пока непонятно, какие именно новые функции получат разработчики. Epic Games не стала раскрывать детали, поэтому неизвестно, например, изменится ли система глобального освещения Lumen. Представители компании лишь отметили, что UE6 «кардинально изменит процесс создания игр».
Доступ к ранней версии движка откроют в конце 2027 года, а полноценный релиз стоит ждать примерно через год-полтора после этого.
Unreal Engine 5.8 — последнее обновление перед большим шагом
🎯Перед презентацией Epic Games выпустила обновление для текущего поколения движка — версию 5.8. Это важный релиз, который стал доступен всем желающим.
Главное нововведение — упрощённая версия системы глобального освещения Lumen, которую назвали Lite. Она значительно меньше нагружает видеокарту, но при этом качество картинки почти не страдает. Разработчики заявляют, что Lumen Lite работает в два раза быстрее предыдущей версии. Это открывает новые возможности — например, игры с глобальным освещением теоретически смогут работать на Nintendo Switch 2 с частотой 60 кадров в секунду.
Кроме того, в UE 5.8 улучшили компиляцию шейдеров и оптимизировали дедупликацию. По словам Epic Games, это позволило сократить количество шейдеров в Fortnite на 68 процентов. Также появился экспериментальный плагин Model Context Protocol, который даёт возможность подключать ИИ-модели напрямую к проектам.
Эта версия станет последним крупным релизом в линейке, хотя разработчики оставляют за собой право выпустить версию 5.9, если возникнет необходимость.
👉 Dessly стремится сделать ваш игровой опыт, а также пополнение Steam кошелька ещё более комфортным и увлекательным.
Технодемо No Law
🎯На презентации также выступила студия Neon Giant, известная по игре The Ascent. Разработчики показали технодемо своего нового проекта — кибернуарного шутера от первого лица под названием No Law. Игра работает на Unreal Engine 5, и создатели делают упор на сюжетную составляющую.
Главная цель команды — найти баланс между высокой детализацией, стабильностью и производительностью. Они хотят наполнить мир игры большим количеством контента, а не просто сделать его огромным по размеру.
Для создания тысяч уникальных моделей персонажей использовалась технология Metahuman. Особое внимание уделили физике — частицы разлетаются естественно, дым тянется за ветром, а битое стекло остаётся там, куда упало.
Релиз No Law запланирован на ПК, PlayStation 5 и Xbox Series, но точной даты пока нет.
Удален юнион UniformValue, как ненужный и не используемый
Заменена функция Set на шаблон с предопределёнными типами для удобства
UniformType удален из движка и используется только для разбора входных динамических параметров материала в RatTools
Замены легаси OpenGL буферы на DSA в коде создания динамических экземпляров (Instancing) материалов
Создание инстанций, кроме инстанции по умолчанию, теперь используют прямое копирование данных на стороне GPU, заместо заполнения буфера через шину
Добавлена заготовка под шейдерный домен Surface на основе физически корректного рендеринга (PBR)
Комментарий
Думается мне, тему инстансов на этом можно закрыть. Оно работает как нужно, параметры определяются, обновляются, читаются и рисуются ровно так, как требуется.
Для закрытии самой темы материалов осталось реализовать только вставки пользовательского кода в скрипт материала. Думаю, завтра/послезавтра уже сделаю. SPIR-V контейнеры отложим в долгий ящик. Сейчас это явно не приоритет.
Следующий этап - класс камеры и юниты источников света (чтобы можно было начать полноценную работу над PBR)
Ассет материала теперь содержит отдельный блок с возможными вводными параметрами шейдера по умолчанию отдельно от юниформов шейдера меатерила
В шейдер введен макет std140 для юниформов
Добавлен отдельный класс в модуле рендера для работы с инстанциями материалов через Uniform Buffer Object (UBO)
Для материалов, имеющих хотя бы один input параметр создается инстанция по умолчанию со значениями юниформов по умолчанию, с запретом на изменение
Добавлено "ленивое" создание инстанций на стороне модуля отрисовки по мере необходимости
Исправлена синхронизация потоков при передаче параметров инстанции материала. Теперь утилизируется uniq_cmd потока отрисовки вместо прямой установки
Комментарий
Переделал инстанции материалов на UBO. Все еще считаю их несколько сырыми и буду их еще какое-то время тестировать и дописывать их код. Кратенько опишу как это работает.
Во первых: UBO требует в шейдере макетной структуры, и поля в ней не могут иметь инициализаторов, поэтому пришлось написать довольно массивный парсер параметров с утилизацией variant и type_identity
glsl именной uniform макет
сущности парсера инпутов при импорте материала в движок через RatTools
Во вторых: эта структура требует выравнивая данных, поэтому, уже на стороне движка пришлось делать особую уличную магию перегоняя сырой буфер в выровненный cогласно стандарту
msvc считает что она дофига умная и настойчиво требует cSize обернуть в sizeof()
В третьих: чтобы не пересоздавать UBO буфер каждый раз, пришлось высчитывать офсеты юниформов и хранить их отдельно в виде пары офсет-размер. Таким образом при изменении одного параметра, в GPU отправится только он.
а вот от текстовой метки до конца так и не удалось избавится, благо у unordered_map итерация идет как 0(1)
ну и в четвертых, т.к. действие происходит сразу в двух потоках (игровом и отрисовки), то на выходе получается довольно много операций копирования (ссылки не доживают до исполнения очереди)
В общем снова на очереди вычитка, удаление старого кода, правка нового. Что-то упростить можно, структуры собрать в одном месте, чтобы не были раскиданы по юнитам. Возможно, выбросить нафиг union, ибо от него сейчас пользы никакой уже, но зато сильно меньше удобства при обновлении переменной юниформа, или обертку над ним хотя бы сделать удобства для.
было/стало. SetVector3 выглядит как-то более удобоваримо
Добавлена смена рабочий директории на необходимую (давно надо было сделать, но все забивал)
Добавлена первая итерация материал инстансов (в очень сыром виде, но работает)
Комментарий
Касательно инстанций, значит. Передал несколько класс шейдера. Пока по тупому, в лоб. На выходных надо будет все это просмотреть, вычитать еще раз, и переписать по человечески. А работает это так:
При инициализации контекста дергаются ассеты материалов на загрузку. и передаются в GLShaderProgram
GLShaderProgram это дело компилирует, проверяет и линкует (когда-нибудь потом будет добавлен кэш, но пока рассчитываем на кэш драйвера)
После этого проходится по инпутам, собирая их в 100500 мапов
индуский код во всей красе, так еще и не все типы реализованы.
При отрисовке, если на юнит выставлен инстанс, а не сам материал, проверяет в таблице инстанса по текстовой (!) метке наличие установленного параметра.
Выставляем инстансы, но не задаем параметры. При инициализации рассчитываем на дефолт юниформа в шейдере (но можно и выставить при желании)
Если текстовая метка присутствует в мапах класса инстанса (там столько-же мапов, по одному на тип), то передает в шейдер значение из него, если нет, то из таблицы дефолта.
длинный и грустный switch. Я не буду показывать эту портянку
И, разумеется, текстовые метки опрашиваются в каждом кадре (что очень не есть хорошо). Нужно будет сделать какой-нить кэш для быстродоступа к нужным параметрам. Да подумать, как избавится от этих мапов, которые мне прям очень сильно не нравятся.
Добавлена обработка ключевого слова input в парсере скрипта материала
Добавлена дополнительная проверка и автоматический выбор параметра max_concurent_taks в случае, если в конфиге параметр равен нулю
Добавлено исключение, в случае, если процессор поддерживает менее 4х потоков
Добавлен программный ограничитель кадров в графическом потоке
Изменена сортировка рендера с сортировки по геометрии на сортировку по шейдерам для уменьшения кол-ва переключения контекста шейдеров OpenGL
Исправлена ошибка при запуске RatTools приводящая к полному запуску движка
Исправлено редкое исключение при обработке очереди AsyncTask разными потоками из-за неучтенного состояния гонки при проверке на пустую очередь
Комментарий
Готовлю движок для внедрения инстансов материалов, чтобы максимально сократить кол-во переключений контекста шейдера (материал == шейдер). Возможно еще проведу оптимизацию по vao - собирая определенные меши в один длинный буфер (сейчас один буфер - один меш + лоды). Однако там есть нюанс с динамической выгрузкой сеток и пересчетом индексов и вообще там не все так очевидно, да и прирост по кадрам не то чтобы прямо большой. Я бы даже сказал не заметный. Т.ч. возможно это того и не стоит, т.к. функция glBindVertexArray всего-лишь перещёлкивает указатель на уже загруженный в GPU буфер. Подумаю, в общем, ибо сейчас это не горит.
Инстанс Материала
Особый класс, который можно создать как вручную, так и загрузив через заранее подготовленный ассет. Содержит перечень переменных со значениями для передачи через uniform шейдера. Привязывается к Материалу(шейдеру) и используется как надстройка над материалом для ускорения процедуры отрисовки.
Короткая версия вопроса: если я хочу нанять человека, который бы прописал в игре про машинки физику бездорожья, то сколько это могло бы стоить?
Кого уже на этом этапе взбесило, дальше не читайте. Этот пост не станет кардинально лучше, только хуже.
Длинная версия вопроса: я задумал некоммерческий проект, к решению ряда вопросов которого сам подступиться не готов. Поэтому я хочу узнать, сколько это может стоить - диапазон, порядок цен. Очевидно, что никто точный ценник не назовёт. Точный и не надо. Задача такая: прописать на UE5 бездорожье, чтобы машинка в зависимости от массы/скорости/типа колеса по-разному вязла. Не вокселями, поскольку нагревать 5090 до температуры плавления задача не стоит.
Да, я понимаю, что сейчас мне расскажут, кто я и куда пойти - это ж пикабу, тут иначе не получится. Давайте, я готов.
RenderThread перенесен из реликта RenderCore в Core
Все семейство классов Thread вынесена из фреймворка RelictClass в обычные классы
Исправлена работа сборщика мусора при удалении объектов с владельцем в другом потоке
Исправлена работа сборщика мусора при закрытие движка
Исправлено завершение потоков семейства Thread в Linux
Комментарий
Мультипоточность отлажена на столько, на сколько это на данном этапе возможно. Движок работает стабильно в обоих целевых ОС. Правда кое-что пришлось таки переделать. В частности Потоки теперь не являются частью фреймворка RelictClass, теперь это самые обычные Сишные классы. Появился дополнительный класс потока GameThread, который по факту не является потоком, но абстракцией над основным потоком приложения. Соответственно изменены и метапараметры RelictClass. Теперь заместо класса потока передается указатель на объект потока. Это добавит в будущем немного сложности, если нам понадобятся пул воркеры, но на данном этапе это сильно упростило жизнь при синхронизации объектов.
