Во первых: UBO требует в шейдере макетной структуры, и поля в ней не могут иметь инициализаторов, поэтому пришлось написать довольно массивный парсер параметров с утилизацией variant и type_identity

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

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

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

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

• При отрисовке, если на юнит выставлен инстанс, а не сам материал, проверяет в таблице инстанса по текстовой (!) метке наличие установленного параметра.

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

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

Но зато даже в таком виде оно работает.

Простенький примерчик:

Готовлю движок для внедрения инстансов материалов, чтобы максимально сократить кол-во переключений контекста шейдера (материал == шейдер). Возможно еще проведу оптимизацию по vao - собирая определенные меши в один длинный буфер (сейчас один буфер - один меш + лоды). Однако там есть нюанс с динамической выгрузкой сеток и пересчетом индексов и вообще там не все так очевидно, да и прирост по кадрам не то чтобы прямо большой. Я бы даже сказал не заметный. Т.ч. возможно это того и не стоит, т.к. функция glBindVertexArray всего-лишь перещёлкивает указатель на уже загруженный в GPU буфер. Подумаю, в общем, ибо сейчас это не горит.

Инстанс Материала

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

Комментарий

Ну вот мультипоточность и заработала. Есть еще косяки в Сборщике мусора, и возможно еще по ходу дела вылезут, но тем-не-менее я доволен как слон.

Ну и результат на большом fps:

Проблема 1

Ее предполагается решить, с помощью добавления дополнительной структуры в ClassInitializator
вида:

enum ThreadType : uint8_t
{ THREAD_MAIN = 0,

THREAD_RENDER = 1 << 0,

THREAD_CUSTOM = 0xff

};

struct ThreadInitializer

{

ThreadType Thread = THREAD_MAIN;

uint64_t CustomThreadId = 0;

};

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

Как пример:

[Fatal] 2026-05-16 13:34:38.277 GMT+3 - Trying to create new object Relict::Renderer with name Renderer_S in incorrect thread context

Проблема 2

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

Проблема 3

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

Мысли

Т.к. Relict Engine пишется на 20м стандарте C++, то нам доступны замечательные вещи: jthread и queue из std библиотеки. Таким образом, мы, в принципе, сможем отделаться лишь одной дополнительной сущностью - классом потока, в котором, через queue будет определена очередь команд на исполнение, контекст сборщика мусора и, собственно, цикличная функция обработки этого всего дела. Конечно нужно будет доделать ThreadManager, чуть поменять очередность инициализации движка, и Сборщик мусора (для определения контекста потока из которого его дернули). Мета объект Class оставляем в основном потоке - нам в принципе все равно из какого контекста его дергают, если это не создание или не удаление объекта. Так-же стоит организовать ограничитель частоты цикла потока с выводом параметра ограничения в конфиг.