Серия «Relict Engine»

Так-же абсолютно ясно, что хранить координаты таких объектов в "чистом" виде не выйдет из-за ограничений float и double (а long double с размерностью 128бит, пока еще не все компиляторы умеют). Тут можно подумать о комплексном представлении. Система Continius Calculation, упомянутая в прошлом посте (далее просто CC) сработает, однако, т.к. она держит числа в единицах с наименьшем битовым заполнением, для работы она будет постоянно эти хранимые числа перегонять в разные, удобные для расчета единицы. Иными словами - система надежная, но относительно медленная. Вчера довольно долго и обстоятельно общался с Gemeni на эту тему - по итогу (правда, я его сломал в конце) вектор для размышлений он дал довольно интересный. Он предложил разделить мир на кубы размером в 1Мм (мегаметр), а их в свою очередь на более мелкие кубы по 20километров каждый + локальное смещение. И объединить их в такую виртуальную сетку, где каждая координата будет состоять из 3х компонент вида [ Macro, Index, Offset ]. Система более внушительная и сложная для реализации, но для CPU с ней проще работать, а значит она будет быстрее.

Иными словами, если систему CC можно использовать, например в каких-то небольших проектах, то для движка это будет уже как стоп кран. Поэтому за основу мы возьмем систему с разбиением. CC, правда тоже не выбросим. Она пригодится для расчета линейных расстояний в более простом виде, т.к. система кубов эту проблему решить не может. И, по прикидкам, комбинация из этих двух систем даст нам на выходе сцену с ребром примерно равным 2000000000 (2 миллиарда) световых лет и с точностью позиционирования объектов на любом участке этой сцены вплоть до 1 миллиметра (неплохо, да?). Конечно такие размеры нам нафиг не сдались, а если говорить конкретно о Cold Fusion, то там будет задействован ничтожный кусочек этого диапазона меньше чем в 1 000 световых лет, но тут важен сам факт.

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

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

Для начала немного теории.
Чтобы все это работало, сцену условно нужно разделить на две сущности.
Первая сущность, сцена мира, или угловая сцена, работает так, как я описывал в посте по Unreal Engine. Т.е. объекты гвоздями прибиты к некой орбите вокруг камеры, а их размер и позиция на этой орбите отвечают за относительное направление к этим объектам и видимый угловой размер. При этом их истинные позиции и размеры сохранены на стороне движка и все операции производятся именно с ними.
Вторая сущность, это уже классическая сцена xyz где и происходят основные действия, физика столкновений, итд. Геймплей в общем.
При этом разделение именно что условное. Сцена не будет прорисовываться дважды - в этом нет никакого практического смысла, т.к. и первой и второй сущностью по сути управляют одни и те-же правила. Меняется только перспектива.

В итоге у нас получается следующая структура:

Камера является центром мироздания (если так можно выразится), затем вокруг нее располагаются классическим образом актеры, источники света, эффекты и тдп. Затем на конкретном удалении звезды, планеты луны и другие крупные тела. И еще за ними скайбокс. Рисуется, впрочем, все в противоположном порядке, дабы избежать ошибок в z буфере, да и видеоадаптеру так проще считать. Можно заметить, что объекты на орбите в определенных позициях могут занимать одну точку, и можно подумать, что при определенных условиях, более мелкий или дальний объект может "проглядывать" через более ближний, но это не является проблемой. Все "проглядывания" одного объекта через другой скроет их движение (и выключенный Deph test) по этой орбите вокруг камеры и в готовом кадре будет выглядеть так, как будто объекты находятся на своих местах.

Теперь обратно к нашему источнику "Звездного света". По понятным причинам при таком построении сцены такой источник не может полагаться на честный закон обратных квадратов, т.к. значение, полученное в шейдере будет объективно неверным, а значит не верным будет и затухание. Считать параметр затухания, как и видимый угловой размер, и кол-во световой энергии, придется на стороне ++ движка и в шейдер передавать уже готовые параметры. И делать это нужно будет для каждого небесного тела (в прочем это можно сделать только один раз, или раз в N кадров, где N довольно большое число, если эти объекты должны двигаться), когда как для локальной сцены можно ограничится параметрами, рассчитанными для камеры, т.к. такая сцена в общем случае не должна будет превышать 5 км по полуоси, что относительно всей остальной сцены не существенно и может быть принято за точку.

Размерность в 5км берется из-за ограничений float. Т.е. итоговая сцена будет 10x10x10 км (от -5 до +5 по осям) из-за того, что точность дробной части после 5км (начиная с числа 524288, т.е. с 5км 242 метров, если принять 1 юнит за 1 сантиметр) начнет заметно искажаться из-за не хватки памяти в 4байтовом блоке (размер float 4 байта), а ошибка в вычислениях будет в районе ~0.06

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

Итак план на ближайшие дни:

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

• Дополнительные расчеты для хранения больших чисел (Continuous calculation)

• Доработка парсера материалов

• Правка Surface шейдера для правильного наложения света в новых реалиях

Вроде бы ничего не забыл.

Прожекторов так-же в кадре может быть 16, как и точечных. Итого, на данный момент в кадре может быть 33 источника света.

Статичные слоты ушли в небытье, теперь при движении камеры источники света формируют массив, отсортированный по дистанции к камере, а так-же по весу (чем больше вес, тем более приоритетным считается источник)

Теперь самое интересное - свет, излучаемый звездой.

На сцене может быть до 16и точечных источников света + направленный свет. Пока реализовано в виде статичных слотов. В дальнейшем переделаю на очередь. Кривая затухания пока так-же захардкожена на 3км и менять ее нельзя, т.к. пока не придумал в каком виде реализовать ее настройку (используется тройная презентация: const linear quadratic).

UPD: пардоньте, я дурак. Переделал на обратный квадрат дистанции. Стало лучше

2 ушло, 2 осталось. На очереди прожекторы.

Бинд привязывается к текстовой метке UserSettings конфига

А дальше, где-нибудь в коде на один (или сразу на все) делегаты вешается нужный метод

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

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

Рано обрадовался, работы (не по движку) пока еще довольно много + духота по мозгам долбит. Ползу медленней, чем обычно, поэтому решил пока бросить приоритет на отладку и производительность того, что уже сделано, чем на добавление нового функционала.
Как всегда больше всего проблем вылезает в Linux сборке - ведро как-то более либерально ко всему относится (причем настолько, что я ему уже не доверяю). Есть проблемы с крэшами сборки из-за Сборщика мусора при удалении объектов из разных потоков (происходит из-за состояния гонки [Родитель приходит к состоянию очистки памяти раньше, чем дочерние, что не есть правильно]), и кроме того, как полностью разделить деревья и вынести триггеры сборщика в отдельные не связанные сущности решения похоже нет (При этом такое поведение наблюдатся исключительно в Linux; Windows как-то пофиг на это, что добавляет отдельно батхерта). Хотя, возможно надо было так изначально делать, т.к. из-за кросс потоковых деревьев приходится паузить треды на тике Сборщика. Если деревья будут разделены, то этого делать будет уже не нужно, а следовательно и производительность несколько увеличится (в прочем там могут другие проблемы вылезти).

Так-же наконец-то добрался до света и pbr. Базовый (очень базовый) шейдер уже написал, теперь нужно прописать логику для юниформов (std140, естно) и работой со светом через ++. Думаю, сначала поэкспериментирую на DirectionalLight (как самом простом варианте), потом добавлю уже остальные по готовому шаблону. Финальным аккордом по теме глобального света должна стать реализация объемного источника света (нужен для реализации физически корректного света от звезд)