Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Твои финансы
Темы

Серия «Relict Engine»

0 просмотренных постов скрыто
10

Relict Engine: DevLog 20260206⁠⁠

Серия Relict Engine

Краткий список изменений

  • Добавлены Log Facility в первом приближении

  • Атом Configable частично переделал на Property

  • Мелкие исправления

Комментарий

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

Для сравнения было/стало

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

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

а вот так-вот стало.

а вот так-вот стало.

Как видно, конфиг и секция теперь задаются в инит. структуре, однако непосредственно процесс загрузки переменной теперь спрятан под капот в объект Property. В коде Property ведет себя как обычная типовая переменная указанного типа. В данном случае int32_t. Значение 42, указанное в конструкторе является значением по умолчанию. Т.е. если в конфиге переменная не указана, то TestProperty инициализируется со значением 42, если указано, то оно инициализируется уже со значением из конфига. Текстовое представление Property может быть каким-угодно, т.к. рефлексии в c++ нету (ну вернее уже есть в стандарте C++26, но лучше его пока не трогать).

Смысл его пока только в загрузке данных из конфига (и сохранение в user конфиг), но в дальнейшем потихоньку расширю этот функционал.

Показать полностью 3
[моё] Разработка Gamedev Инди Игровой движок C++
1
7

Relict Engine: DevLog 20260203⁠⁠

Серия Relict Engine

Краткий список изменений

  • Добавлен логгер из "Proof of Concept" версии движка

  • Исправлена ошибка связывания сущности RenderObject с UnitObject

  • Исправлена ошибка линковки мета классов в модулях

Комментарий

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

Сам лог довольно подробный в DEBUG режиме; ротирует файлы лога по дате/времени ротации и пишет данные не только в непосредственно файл, но и в консоль. Выглядит это так:

Log started at 2026-02-03 13:39:02.968 GMT+3

[Debug] 2026-02-03 13:39:02.991 GMT+3 - Core: Class Relict::AssetManager Registred

[Debug] 2026-02-03 13:39:02.992 GMT+3 - Core: Class Relict::IFileSystem Registred

[Debug] 2026-02-03 13:39:02.992 GMT+3 - Core: Class Relict::FSManager Registred

[Debug] 2026-02-03 13:39:02.992 GMT+3 - Core: Class Relict::IAsset Registred

[Debug] 2026-02-03 13:39:02.993 GMT+3 - Core: Class Relict::ThreadManager Registred

[Debug] 2026-02-03 13:39:02.993 GMT+3 - Core: Class Relict::IRenderWindow Registred

[Debug] 2026-02-03 13:39:02.993 GMT+3 - Core: Class Relict::SubsystemManager Registred

[Debug] 2026-02-03 13:39:02.994 GMT+3 - Core: Class Relict::ISubsystem Registred

[Debug] 2026-02-03 13:39:02.994 GMT+3 - Core: Class Relict::StaticMesh Registred

[Debug] 2026-02-03 13:39:02.994 GMT+3 - Core: Class Relict::TestAsset Registred

[Debug] 2026-02-03 13:39:02.995 GMT+3 - Core: Class Relict::RenderWindow Registred

[Debug] 2026-02-03 13:39:02.995 GMT+3 - Core: Class Relict::GameEntity Registred

[Debug] 2026-02-03 13:39:02.995 GMT+3 - Core: Class Relict::GameWorld Registred

[Debug] 2026-02-03 13:39:02.996 GMT+3 - Core: Class Relict::Units::SceneUnit Registred

[Debug] 2026-02-03 13:39:02.996 GMT+3 - Core: Class Relict::IScene Registred

[Debug] 2026-02-03 13:39:02.996 GMT+3 - Core: Class Relict::FS::RelictFS Registred

[Debug] 2026-02-03 13:39:02.997 GMT+3 - Core: Class Relict::FS::SystemFS Registred

[Debug] 2026-02-03 13:39:02.997 GMT+3 - Core: Class Relict::Render::IRenderObject Registred

[Debug] 2026-02-03 13:39:02.997 GMT+3 - Core: Class Relict::Units::RenderUnit Registred

[Debug] 2026-02-03 13:39:02.998 GMT+3 - Core: Class Relict::Render::IRender Registred

[Debug] 2026-02-03 13:39:02.998 GMT+3 - Core: Class Relict::Renderer Registred

[Debug] 2026-02-03 13:39:02.998 GMT+3 - Core: Class Relict::Units::StaticMeshUnit Registred

[Debug] 2026-02-03 13:39:02.999 GMT+3 - Core: Class Relict::Render::StaticMesh_RenderObject Registred

[Debug] 2026-02-03 13:39:02.999 GMT+3 - Core: Class Relict::Render::VertexArrayObject Registred

[Debug] 2026-02-03 13:39:02.999 GMT+3 - Core: Class Relict::Render::OpenGL Registred

[Debug] 2026-02-03 13:39:03.000 GMT+3 - Core: Created Object Renderer_S class Relict::Renderer owned by none

[Debug] 2026-02-03 13:39:03.001 GMT+3 - Core: Created Object OpenGL_S class Relict::Render::OpenGL owned by none

[Debug] 2026-02-03 13:39:03.001 GMT+3 - Core: Class Relict::Render::StaticMesh_GLRenderObject Registred

[Debug] 2026-02-03 13:39:03.002 GMT+3 - Core: Class Relict::Game::Actor Registred

[Debug] 2026-02-03 13:39:03.002 GMT+3 - Core: Class TestNv Registred

[Debug] 2026-02-03 13:39:03.002 GMT+3 - Core: Class TestInhNv Registred

[Debug] 2026-02-03 13:39:03.003 GMT+3 - Core: Class TestActor Registred

[Debug] 2026-02-03 13:39:03.267 GMT+3 - Core: Created Object FSManager_S class Relict::FSManager owned by none

[Debug] 2026-02-03 13:39:03.267 GMT+3 - Core: Created Object SystemFS_S class Relict::FS::SystemFS owned by none

[Debug] 2026-02-03 13:39:03.268 GMT+3 - Core: Created Object AssetManager_S class Relict::AssetManager owned by none

[Debug] 2026-02-03 13:39:03.268 GMT+3 - Core: Created Object StaticMesh_1 class Relict::StaticMesh owned by AssetManager_S

[Debug] 2026-02-03 13:39:03.269 GMT+3 - Core: Object /Cube previously known as StaticMesh_1

[Debug] 2026-02-03 13:39:03.269 GMT+3 - Core: Created Object StaticMesh_2 class Relict::StaticMesh owned by AssetManager_S

[Debug] 2026-02-03 13:39:03.270 GMT+3 - Core: Object /Mesh previously known as StaticMesh_2

[Debug] 2026-02-03 13:39:03.270 GMT+3 - Core: Created Object StaticMesh_3 class Relict::StaticMesh owned by AssetManager_S

[Debug] 2026-02-03 13:39:03.271 GMT+3 - Core: Object /Torus previously known as StaticMesh_3

[Debug] 2026-02-03 13:39:03.271 GMT+3 - Core: Created Object ThreadManager_S class Relict::ThreadManager owned by none

[Debug] 2026-02-03 13:39:03.272 GMT+3 - Core: Created Object SubsystemManager_S class Relict::SubsystemManager owned by none

[Debug] 2026-02-03 13:39:03.272 GMT+3 - Core: Created Object RenderWindow_1 class Relict::RenderWindow owned by none

[Info] 2026-02-03 13:39:03.778 GMT+3 - Empty Application run

[Debug] 2026-02-03 13:39:03.779 GMT+3 - Core: Created Object TestNv_1 class TestNv owned by none

[Debug] 2026-02-03 13:39:03.779 GMT+3 - Core: Created Object GameWorld_1 class Relict::GameWorld owned by none

[Debug] 2026-02-03 13:39:03.780 GMT+3 - Core: Created Object TestActor_1 class TestActor owned by GameWorld_1

[Debug] 2026-02-03 13:39:03.780 GMT+3 - Core: Created Object SceneUnit_1 class Relict::Units::SceneUnit owned by TestActor_1

[Debug] 2026-02-03 13:39:03.780 GMT+3 - Core: Created Object StaticMeshUnit_1 class Relict::Units::StaticMeshUnit owned by SceneUnit_1

[Debug] 2026-02-03 13:39:03.781 GMT+3 - Core: Created Object StaticMeshUnit_2 class Relict::Units::StaticMeshUnit owned by StaticMeshUnit_1

[Debug] 2026-02-03 13:39:09.308 GMT+3 - Core: Created Object StaticMesh_GLRenderObject_1 class Relict::Render::StaticMesh_GLRenderObject owned by StaticMeshUnit_2

[Debug] 2026-02-03 13:39:09.309 GMT+3 - Core: Created Object VertexArrayObject_1 class Relict::Render::VertexArrayObject owned by /Cube

[Debug] 2026-02-03 13:39:12.098 GMT+3 - Core: Created Object StaticMesh_GLRenderObject_2 class Relict::Render::StaticMesh_GLRenderObject owned by StaticMeshUnit_1

[Debug] 2026-02-03 13:39:16.659 GMT+3 - Core: Object RenderWindow_1 Marked for destruction

[Debug] 2026-02-03 13:39:16.689 GMT+3 - Core: Deleting Object RenderWindow_1

[Info] 2026-02-03 13:39:16.689 GMT+3 - Empty Application end

[Debug] 2026-02-03 13:39:16.690 GMT+3 - Core: Deleting Object StaticMeshUnit_2

[Debug] 2026-02-03 13:39:16.690 GMT+3 - Core: Deleting Object StaticMeshUnit_1

[Debug] 2026-02-03 13:39:16.691 GMT+3 - Core: Deleting Object SceneUnit_1

[Debug] 2026-02-03 13:39:16.691 GMT+3 - Core: Deleting Object GameWorld_1

[Debug] 2026-02-03 13:39:16.692 GMT+3 - Core: Deleting Object TestActor_1

[Debug] 2026-02-03 13:39:16.692 GMT+3 - Core: Deleting Object StaticMesh_GLRenderObject_1

[Debug] 2026-02-03 13:39:16.692 GMT+3 - Core: Deleting Object StaticMesh_GLRenderObject_2

[Debug] 2026-02-03 13:39:16.693 GMT+3 - Core: Deleting Object TestNv_1

[Debug] 2026-02-03 13:39:16.693 GMT+3 - Core: Deleting Object VertexArrayObject_1

[Debug] 2026-02-03 13:39:16.693 GMT+3 - Core: Deleting Object ThreadManager_S

[Debug] 2026-02-03 13:39:16.693 GMT+3 - Core: Deleting Object SystemFS_S

[Debug] 2026-02-03 13:39:16.694 GMT+3 - Core: Deleting Object /Mesh

[Debug] 2026-02-03 13:39:16.697 GMT+3 - Core: Deleting Object /Cube

[Debug] 2026-02-03 13:39:16.697 GMT+3 - Core: Deleting Object /Torus

[Debug] 2026-02-03 13:39:16.698 GMT+3 - Core: Deleting Object FSManager_S

[Debug] 2026-02-03 13:39:16.698 GMT+3 - Core: Deleting Object OpenGL_S

[Debug] 2026-02-03 13:39:16.698 GMT+3 - Core: Deleting Object SubsystemManager_S

[Debug] 2026-02-03 13:39:16.699 GMT+3 - Core: Deleting Object Renderer_S

[Debug] 2026-02-03 13:39:16.699 GMT+3 - Core: Deleting Object AssetManager_S

Log closed at 2026-02-03 13:39:16.699 GMT+3

И дебажить код стало сильно легче )
PS: Если присмотреться, то видно, что есть еще один не исправленный баг (TestNV_1 не самоудаляется, хотя должен, т.к. не указан владелец) - [UPD: исправлено. Забыл проверку на овнера сделать в регистраторе Сборщика мусора, когда переделывал на событийную модель

[Debug] 2026-02-03 14:48:42.331 GMT+3 - Core: Created Object TestNv_1 class TestNv owned by NaN

[Debug] 2026-02-03 14:48:42.331 GMT+3 - Core: Object TestNv_1 Marked for destruction

...

[Debug] 2026-02-03 14:48:42.335 GMT+3 - Core: Deleting Object TestNv_1

]

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

Показать полностью
[моё] Разработка Gamedev Инди Игровой движок C++ Текст Длиннопост
0
7

Relict Engine: DevLog 20260119⁠⁠

Серия Relict Engine

Краткий список изменений:

  • Ядро переключено на новую кодобазу с метаклассами

  • Удалены сущности DefaultObject

  • Изменен принцип регистрации сущностей со статичных вызовов на делегаты

  • Заменен старый глобальный тикер на новый через метакласс

  • Добавлен функционал Subticks с заданным интервалом

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

  • Куча мелких исправлений (и еще столько же предстоит исправить)

Комментарий:

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

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

UPD: inline Class _Class должен быть inline Class& _Class (заметил после публикации поста)

UPD: inline Class _Class должен быть inline Class& _Class (заметил после публикации поста)

После фикса все встало на свои места

После фикса все встало на свои места

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

Показать полностью 3
[моё] Разработка Gamedev Инди Игровой движок C++
0
8

Relict Engine: DevLog 20260108⁠⁠

Серия Relict Engine

Краткий список изменений

  • Добавлены структуры инциализаторы шаблонного класса RelictClass

    На данный момент просто как сущность. Функционал для них пока не готов.

  • Добавлен класс Relict::Class как хранилище инициализационных структур

  • Перенесена часть функционала, касающаяся регистрации/удаления объектов из ObjectStorage в Relict::Class

  • Упрощена работа Сборщика мусора путем перевода его на событийную модель

  • Добавлены заготовки на контейнеры сетевых/скриптовых полей Property

    Добавлены в качестве залипухи на будущее. В логике работы движка они ни коем образом не участвуют.

Комментарий

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

Касательно структур, решил сделать чуть иначе, чем в концепт-коде, приведенном в пред. посте: Relict Engine: Начало сезона 2026
Вместо некрасивого нагромождения различных скобок в шаблоне (который еще и очень не нравится IDE, несмотря на то, что стандарт допускает такое использование) вынес их отдельно. Теперь это выглядит вот так:

Не обращайте внимание на префикс Nv. Это нужно для совместимости со старым кодом. Во время переключения вернется старый добрый TRelictClass

Не обращайте внимание на префикс Nv. Это нужно для совместимости со старым кодом. Во время переключения вернется старый добрый TRelictClass

Показать полностью 1
[моё] Разработка Gamedev Инди Игровой движок C++
2
13

Relict Engine: Начало сезона 2026⁠⁠

Серия Relict Engine

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

Отказ от Атомов.

Как показала практика использования, система атомов не состоятельна. Нет, ее можно использовать на уровне проектов для внедрения дополнительного функционала, но не на уровне ядра. Поэтому она идет под нож. Заместо нее появятся конфигурационные структуры для шаблонов классов. Выглядеть они будут примерно так:

концепт код: <a href="https://pikabu.ru/story/relict_engine_nachalo_sezona_2026_13570983?u=https%3A%2F%2Fgodbolt.org%2Fz%2FEjnMYr153&t=https%3A%2F%2Fgodbolt.org%2Fz%2Fq1zPeMeE3&h=4c6de45e1a4af5a22e8239524a02c7adae7804da" title="https://godbolt.org/z/EjnMYr153" target="_blank" rel="nofollow noopener">https://godbolt.org/z/q1zPeMeE3</a>

концепт код: https://godbolt.org/z/q1zPeMeE3

Так-же, подобные структуры позволят нам реализовать ряд интересных вещей. Например, после реализации мета классов, они позволят нам связать создание одного объекта с другим объектом (Например класс RenderObject с SceneUnit) для более прозрачной работы конвейера.

Остальные улучшения

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

Третьим улучшением, которое частично будет реализовано сейчас, а частично очень потом - это внедрение мета классов аналогов UClass в Unreal Engine, для хранения константных проинициализированных структур инициализаторов и мета методов для работы с Lua. Что позволит нам сильно упростить работу с скрипт подсистемой. Которая, возможно, перейдет из состояния подсистемы в ядро (но это не точно, поэтому и откладываю на потом). А так-же избавит от необходимости таскать в дефолтном конструкторе Initializer. И в дополнение, они позволят нам избавится от такого рудимента, как DefaultObject (он используется для проверки Флагов в хранилище объектов).

Показать полностью 1
[моё] Разработка Gamedev Инди Игровой движок C++
0
14

Relict Engine: Итоги 2025⁠⁠

Серия Relict Engine

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

Что было сделано за этот год:

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

  • Создана скрипт подсистема на основе языка Lua и внедрена в виде подключаемой подсистемы.

    Подробнее: Relict Engine: Скриптовая подсистема + DevLog 20250405

  • Разработана утилита для импорта внешних форматов в формат движка

    Подробнее: Relict Engine: RatTools. Меши. Статичные Меши

  • Разработан формат хранения статичной геометрической сетки (статичный меш)

    Подробнее: Relict Engine: Формат Статичного меша

  • Разработана система работы с асинхронными задачами

    Подробнее: Relict Engine: ThreadManager и DevLog 20250822

  • Разработана структура сцен
    Подробнее: Relict Engine: Мир и DevLog 20250928

  • Разработана система вывода графики и работа с ней

    Подробнее: Relict Engine: DevLog 20251120

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

Что планируется на 2026

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

Так-же будет нужно сделать шейдерный pbr и доделать для них внятную систему материалов; добавить ассет текстур; добавить различные юниты для работы со светом, системами частиц, итд. Поэтому, остальной 2026 год будет посвящен работе "в ширь". Успею ли сделать что-то еще зависит от множества неподконтрольных мне факторов, поэтому загадывать по максимуму не буду.

Еще хочу напомнить, что у движка есть дорожная карта, ознакомится с которой можно вот тут: https://yougile.com/board/8o3quozyj1in , и где видно сколько было сделано. И сколько еще предстоит сделать.

И на этом год 2025 считаю закрытым.

И в заключении, от себя и от лица команды Delta-Proxima Team хотим заранее поздравить пользователей Пикабу, и отдельно Лигу разработчиков Видеоигр с новым, 2026м годом. Желаем, чтобы ваши проекты покоряли вершины чартов, а каждый новый релиз становился событием в мире игровой индустрии.
Пусть код пишется легко, баги находятся быстро, а вдохновение никогда не покидает вас!
А на кухне никогда не заканчиваются кофе и печеньки ;)

С уважением и наилучшими пожеланиями,
Delta-Proxima Team

Показать полностью
[моё] Разработка Gamedev Инди Игровой движок Новый Год
3
8

Relict Engine: Шейдеры. Часть 2. Материалы. Синтаксис⁠⁠

Серия Relict Engine

Как я писал в пред. посте (Relict Engine: Шейдеры. Часть 1. Теория и вопросы), нам потребуется комбайн для перегона материала (или, если угодно, настроек шейдера) в spir-v формат. Для этого необходимо создать изначальный формат, желательно в текстовом виде, который и будет входной точкой в этот процесс.

Этот формат должен отвечать следующим требованиям:

  • В нем должно быть указано, с какими "сырыми" шейдерами компоновать этот материал

  • Иметь возможность обращаться к дополнительным файлам, содержащим кастомные функции

  • Иметь возможность самому определять дополнительные функции

  • Задавать входные опции

  • Определять параметры уже самого шейдера

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

первый вариант синтаксиса материала

первый вариант синтаксиса материала

Что мы тут видим:
Директива using
Она определяет компоновку с сырыми шейдерами. Определяет домен, модель смешивания альфы и модель освещения (не путать с моделью затенения из пред. поста).
Нейминг был взят из Unreal Engine, потом, возможно, поменяю на немного более логичные.

Директива in
Она определяет входные переменные для материала, используя типы GLSL

Директива include
Эта директива говорит комбайну, что следует обратится к функции, определенной в файле MaterialFunctions/getColor (Content/MaterialFunctions/getColor.minc проекта). Что важно, сам файл как самостоятельный ассет не будет использоваться, но его контент будет вставлен заместо директивы include при первичной компоновке.

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

Директива set
Эта директива передает конкретные значения в параметры "сырых" шейдеров. Иными словами, это и есть сам материал.

Показать полностью 1
[моё] Разработка Gamedev Инди Игровой движок Шейдеры
0
12

Relict Engine: Шейдеры. Часть 1. Теория и вопросы⁠⁠

Серия Relict Engine

Начнем, пожалуй, с теории.

Шейдеры и модель затенения

пример работы отложенного затенения (иллюстрация <!--noindex--><a href="https://pikabu.ru/story/relict_engine_sheyderyi_chast_1_teoriya_i_voprosyi_13424189?u=https%3A%2F%2Flearnopengl.com%2F&t=https%3A%2F%2Flearnopengl.com%2F&h=9d0d5ab19c1209e085c1ddb0125053715c6b9c32" title="https://learnopengl.com/" target="_blank" rel="nofollow noopener">https://learnopengl.com/</a><!--/noindex-->)

пример работы отложенного затенения (иллюстрация https://learnopengl.com/)

Шейдер это программа, написанная на одном из специализированных языков программирования, например GLSL, и выполняемая на GPU.
Шейдеры бывают разных видов: вершинные, фрагментные, геометрические и компьют. Каждый создан для своей задачи и работают чуть по разному.
Например, вершинный шейдер работает исключительно с вершинами (или набором точек) 3д модели, а фрагментный (или, как его еще называют, пиксельный), только с пикселями экрана или текстуры.

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

А так-же есть две модели шейдинга (шейдинг ("затенение") - процесс в компьютерной графике, который придает объектам реалистичный вид, определяя их цвет и внешний вид в зависимости от освещения, текстур и материалов):
Forward (или прямое затенение) - при этой модели каждый отдельный объект обрабатывается самостоятельно. Свет и тени будут считаться отдельно для каждого объекта.
Deffered (или отложенное затенение) - отрисовка сцены происходит в несколько проходов с сохранением промежуточных данных в специальные текстуры, которые имеют общее название G-Buffer. А потом, отдельным проходом, единоразово будет просчитан свет и тень.

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

Шейдеры в Relict Engine

Таким образом, в первую очередь нам нужно выбрать, какую модель затенения использовать в движке. Т.к. проект, для которого Relict Engine создается, связан с космосом, то логично предположить, что прямое затенение даст больше производительности, нежели отложенное. И это будет верно, пока мы говорим о "сферическом космосе в вакууме". Как только появляются туманности, низкие орбиты и нагруженные космопорты на этих орбитах, все становится менее очевидно. Поэтому, несмотря на кажущуюся простоту этого вопроса , ответить на него не так уж и просто.

Следующие вопросы, который надо решить, и которые не связаны с моделью затенения напрямую, а больше относятся к архитектуре движка, является: А как хранить шейдеры? Как передавать в них параметры?

В спецификации OpenGL 4.5 появилась возможность использовать бинарные шейдеры Spir-V, которые являются основным форматом шейдеров для Vulkan. И это удобно, мы сможем использовать один и тот-же шейдер как для OpenGL, так и для Vulkan без модификации. Но это касается "статичных" шейдеров. Их нельзя изменять, можно добавить только заранее известные переменные, которые можно будет передать в шейдер через функции движка или скрипта, а если мы хотим чего-то более сложного? Например передать не текстуру, а некую математическую функцию, которая будет определять цвет пикселя по своим собственным законам?

Таким образом, нам понадобится система, которая будет компоновать наши кастомные навороты, а так-же вводные данные, в виде переданных параметров с набором функций базовых шейдеров в некую отдельную сущность, которая будет представлять из-себя скомпонованный шейдер из множества отдельно взятых функций и точки входа. И желательно, все это все равно сохранить в Spir-V формат для удобства дальнейшего перехода на Vulkan.
Более того, в зависимости от выбранной модели затенения, выходной результат так-же должен отличаться. Так например, если мы для Основного цвета (Diffuse Color) не будем использовать текстуру, а некую мат. функцию, то нам нужно будет скомпоновать эту функцию с шейдером G-Buffer, в случае использования отложенного затенения, когда как в случае прямого затенения, с итоговым фрагментным шейдером.

Иными словами только для подготовки шейдера к компиляции в кэш нам потребуется целый промежуточный комбайн. Этот комбайн будет работать с текстом, компонуя и генерируя исходный glsl код из пред написанных сниппетов и нашего материала. А на выходе должен быть Asset, уже в формате Spir-V, который и будет использоваться для компиляции уже в машинный код и исполнения на GPU.

Показать полностью
[моё] Разработка Gamedev Инди Игровой движок Шейдеры
0
Отличная работа, все прочитано!

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества