Relict Engine: Очень Большие Сцены (VBS/HS)⁠⁠

Как я указал в прошлом посте, осталось реализовать последний источник света - а именно источник звездного (Солнечного, если хотите) света. Почему я упоминаю это, ну на самом деле, потому что эти две сущности довольно плотно связаны. Этот источник не может работать без VBS/HS и наоборот VBS/HS может работать ТОЛЬКО с таким или подобным ему источниками.

Почему так? Этот источник оперирует реальными параметрами звезды. Температура, радиус, расстояние до освещаемого объекта, кол-во энергии которое этому объекту передается. Большая часть этих параметров далеко выходят за точность float. А с double видеокарты до сих пор(!) работать на этапе отрисовки кадра нормально не могут и производительность проседает +- в 8 раз (и вряд ли это изменится в обозримом будущем). Поэтому, мы не можем просто сказать видеодрайверу, что, "эй, вот тут звезда с радиусом 6 9600 000 000 сантиметров, а объект на расстоянии 149 597 870 700 000 сантиметров от него. Иди рисуй свет" (утрированно), потому что это не сработает и в лучшем случае мы получим очень неопределенный результат. Поэтому, при создании больших пространств хитрят, и этот пост как раз о таких хитростях.

Когда-то уже давно, еще когда я работал с 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 шейдера для правильного наложения света в новых реалиях

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