Год подходит к концу  и, т.к. в этом месяце у меня, скорее всего, не получится заниматься проектом, хочу подвести определенные итоги.

Что-же было сделано за 2021 год, и что стоит ожидать в 2022ом.

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

2) Доведен до стадии пред релиза рендер планет. Самое главное, исправлен очень противный баг при рендере в Dx12, который, по до сих пор не понятным для меня причинам, давал артефакты на неровностях ландшафта.

(@MrMSE, вопрос со светом все еще открыт, т.к. встроенный Атмосферный Скаттеринг пока не удалось заставить работать так, чтобы можно было сделать "правильный" терминатор)

3) Начата работа над системой шардинга и системой быстрого развертывания сервера (система будет доступна в OpenSource. Пишется на Node.JS).

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

5) Готовятся материалы для начала работ над конструктором кораблей и станции (пока в концепции)

6) Готовится материал для начала работ над интерьерами станций и АТС.

7) Готовятся материалы для более глубокой оптимизации 3Д туманностей, из-за слишком плохой производительности на видеокартах до RTX эры.

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

В прошлом посте (Вся наша жизнь спираль: Синтез субатомных частиц) мы кратенько рассмотрели сложности работы с float и рендер туманностей.

Сегодня мы рассмотрим планеты и построение сцены относительно игрока.

Начнем с простого.

Свет.

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

Их всего 3:

- Point Light - свет излучается из точки по некому радиусу с затуханием

- Spot Light - или прожектор. Источник излучается из точки по конусу, опять таки с затуханием

- Direction Light - самый простой источник света. Свет идет по направлению, без источника как такового.

Логично предположить, что для звезды лучше всего подойдет последний. Звезда не точка, это огромная сфера, каждая точка которой излучает свет.

Хорошо, с этим определились. Но, Direction Light светит только в одном направлении, а звезда во все сразу. Это проблема, но решается достаточно просто. Мы просто берем, и привязываем направление света на позицию игрока. Тогда получится, что свет всегда идет от звезды к игроку.

А как быть с планетами и прочими макро объектами? Ведь если игрок сместится, то также сместится освещенная часть планеты.

Тут нам помогут уже простейшие шейдера.

Первым делом исключим наши объекты из списка объектов, на которые влияет источник света (иными словами сделаем их Unlit). А дальше, возьмем позицию источника света, посчитаем вектор направления к планете и возьмем dot product от каждой нормали вершины планеты. Вуаля, мы получим маску, которая будет эмулировать этот самый DirectionLight

Вторая проблема, которая вытекает из первой - тени. Большие объекты, особенно если у них есть кольца - отбрасывают на них тень, которая

а) Привязана к источнику света

б) Имеет мерзкую привычку глючить на больших расстояниях

Снова обращаемся к шейдеру.

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

Делается это достаточно просто (хотя тут ноды лучше не использовать)

/*
* INPUT:
* LightLocationWS Light Position in WorldSpace
* LightSourceRadius Light Radius
* ParentBodyLocationWS Parent Body (Shadow Caster) location in WorldSpace
* ParentBodyRadius Parent Body Radius
* WorldPosition AbsoluteWorldPositionWS
* VertexNormal VertexNormalWS
*/
MaterialFloat3 LL = LightLocationWS;
MaterialFloat3 PL = ParentBodyLocationWS;
MaterialFloat LSR = LightSourceRadius;
MaterialFloat PBR = ParentBodyRadius;
MaterialFloat3 rc = WorldPosition - PL;
MaterialFloat c = dot(rc, rc) - (PBR*PBR);
MaterialFloat b = dot(normalize(LL - PL), rc);
MaterialFloat d = b*b - c;
MaterialFloat t = -b - sqrt(abs(d));
MaterialFloat st = step(0, min(t,d));
MaterialFloat shadow = lerp(-1, t, st);
return shadow;

В результате получится вот такой эффект, который не зависит от расстояния и от размера объекта

Со светом разобрались, теперь перейдем непосредственно к построению сцены.

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

Но это сработает только с планетами, звездами и прочими макрообъектами, а что делать с другими игроками? Их рисуем как есть по смещению к позиции игрока - они достаточно маленькие и смысла пересчитывать их размеры нет. Однако, что будет, если другой игрок достаточно далеко, а планета, к которой мы летим, нет, и она уже видна на экране? В этом случае другой игрок может оказаться ЗА планетой, хотя по факту он должен быть перед ней.

В решении этой проблемы нам поможет инструмент, под названием Custom Depth Pass и CustomDepth Stencil Buffer (CustomDepth Stencil Write Mask и CustomDepth Stencil Value)

Это бит поле поможет нам отсортировать объекты таким образом, чтобы объекты правильно накладывались друг на друга.

Самый простой вариант (но не самый корректный) отсортировать объекты через дополнительную фазу Translucent (через приоритеты + через стенсил)

где CheckDepth это CustomNode, которая имеет следующее внутри себя

uint SceneDepth = Depth;
return SceneDepth > 1 ? 0 : 1;

SceneDepth тут это как раз таки то самое CustomDepth Stencil Value, которое можно задать свое для каждого объекта в отдельности. Если объекты пересекаются, то значения буфера складываются. Например, если у нас пересеклись объекты со значением 1 и 2, то на выходе будет 3. Тогда, в материале объекта, со значением 1, если полученное число будет больше 1, то нам нужно скрыть этот объект.

Почему именно такие цифры.

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

Следовательно цифры, которые мы можем использовать принадлежат степени двойки, т.е.

1 2 4 8 16 ну итд

1, или 0b00000001 - это самый дальний объект (skycube), который должен быть скрыт, если его пересекает любой другой объект, следовательно если на него приходит любое другое значение, кроме как 1, то мы его скрываем.

Следующий объект 2 (0b00000010). Он не должен быть скрыт, когда к нему приходит значение 3 (собственное значение 2 + 1 от старкуба), но должен быть скрыт, когда приходит значение 4, ну итд.

При этом, если пересекаются два одинаковых объекта, то сокрытие одного или другого объекта будет разруливать не стенсил, но Translucency Sort Priority, который должен зависеть от дальности этих объектов.

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

Ну а теперь самое вкусное на сегодня - планеты

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

Нужно было учесть несколько моментов - у нас нет сцен на поверхности планет, поэтому нет смысла выделывать полноценный генератор, аля Elite. При этом все это должно смотреться интересно и +- реалистично.

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

В результате, получилось следующее:

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

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

Из полученного результата мы генерируем нормаль и все это применяем на модель света, описанную выше. В результате получаем нечто, похожее на это:

и в довершение всего, применим к этому SkyAtmosphere - стандартный компонент визуализации UE4 (который наконец доделали в 4.26)

Здесь осталась одна нерешенная проблема. Изначально, для наложения деталей я выбрал не верный подход через 6planar mapping. Для слоя можно выбрать одну из 6ти сторон планеты, но не более того. В ближайшее время это будет заменено на проекцию по произвольному вектору, что позволит добавить более мелкие детали, и сделать более незаметным то, что поверхность планеты на самом деле двухмерна.

И на этом пока что все. До связи до следующего раза.

Прошел год с моего последнего поста, пора пилить следующий.

Сегодня снова поговорим о сети и об организации мира Синтеза.

Главное изменение сетевой модели, который получил Синтез - это полный авторити сервер.

Тем не менее, проблемы, которые я описывал ранее в L.I.M.A., никуда не делись, поэтому появился другой модуль, позволяющий обсчитывать сразу несколько "карт" и сливать их в одну карту, с репликой, по необходимости, на клиенты. Модуль имеет открытый исходный код и может быть найден тут: https://github.com/Delta-Proxima-Team/UE4-Module-RelatedWorl...

Если описать простым языком, то он работает по принципу инстанцев в небезызвестной Elite: Dangerous, с той лишь разницей, что можно передавать информацию сразу с нескольких инстанцев в единое мировое пространство клиента.

Карта, в отличии от L.I.M.A. в Синтезе полностью статична. Каждая звездная система заботливо расположена руками, а т.к. место действия происходит в отдельном шаровом звездном скоплении, то их не много. Но конкретно о карте и ее топологии поговорим в другой раз, т.к. при разговоре о ней, нужно будет коснуться и фракций, которые в ней обитают, а об этом, на данный момент я говорить не готов. Вместо этого поговорим об общем ее строении и проблемах, связанных с ней.

Мир Синтеза, как и в L.I.M.A. бесшовный. При полетах игрок не видит никаких загрузок. Перелет между системами выглядит плавным, между звездными системами можно встретить всякие интересности, или приключения на свою задницу. Это частично достигается новым сетевым модулем, а частично системой представления удаленных объектов. Она основана на методе пересчета размера небесных тел через их угловой размер. Об этом немного поподробнее.

Подсчет углового размера любого небесного тела можно представить вот таким-вот образом:

, где D - расстояния от наблюдателя до границы объекта, а d - диаметр этого объекта.

Если расстояние D известно, то можно через обратное преобразование получить его радиус.

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

В ходе нехитрых преобразований, мы получим вот такую вот формулу:

В коде, конечно-же, формула будет выглядеть как VisibleDistance * (RealRadius/RealDistance), т.к. отношение RealRadius к RealDistance безразмерный коэффициент. Это была первая проблема.

Вторая проблема это float и разница в единицах измерений (от сантиметра до светового года).

Как известно, если говорить, о целой части float, то она дает достаточную точность для целых чисел, значение которых можно уложить в 3 байта. Если дать больше конкретики, то это число 16 777 215 (16,7 км в единицах анрила). Дальше начинаются проблемы с точностью. Для обхода этой проблемы, и помня, как была решена проблема с размерами объектов, было принято решение делать "Continuous calculation". В такой системе, при подаче некоторого числа на вход, необходимо так-же указать его единицы, и, если оно выше или ниже некоего предела оно будет последовательно переведено в более подходящее для этого числа единицы (пример: если мы дадим на вход 100 000 см. то сначала будет выполнен перевод в 1 000 м, а потом в 1 км ). Таким образом, какое бы расстояние мы бы не передали, то на выходе, оно всегда будет занимать меньше трех байт. Погрешности, конечно-же, никуда не делись, но они нивелируются по мере уменьшения масштаба вычислений. Условно, чем ближе наблюдатель к объекту, тем меньше погрешность. Ну и соответственно, чем дальше, тем погрешность больше, но из-за большого расстояния - глазу не заметно и она не имеет тенденции к накоплению.

Третья проблема - туманности. Т.к. космос бесшовный, то они должны быть 3д. Как нарисовать 3д туманность? Эксперименты показали, что метод Density RayMarcher подойдет лучше всего.

(полученную из фрактала текстуру следует подчистить от артефактов)

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

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

Как бонус: один из ранних рендеров безатмосферных планет.

Это будет весьма небольшой пост. За последние 9 месяцев много всякого произошло, и проектом практически не было времени заниматься. Однако много думали. И пришло понимание того, что времени и ресурсов все это сделать как мы хотим и отладить, на данный момент нам не хватит ни при каких условиях.

В результате было принято решение отправить проект в стазис, взять часть модулей, переработать и использовать в другом, более простом проекте, который позволит их довести их до ума, а также покажет: будет ли это все работать так, как мы изначально задумывали в L.I.M.A.

Так на свет появился проект под названием "Холодный синтез" (Cold Fusion).

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

В общем выкинули, или упростили практически все (но не все). Летная и сетевая модели перекочевали практически без изменений. Core геймплей, боевая, экономическая и политическая модели также остались практически без изменений (я о них еще не рассказывал, но обязательно расскажу), как и много других уже готовых и не очень вещей.

Подробности о проекте, сложностях и принятых решениях (и костылях) будут также выходить под заголовком "спирали", т.к. тематика очень близкая, но с дополнительным тегом #ColdFusion, а так-же в отдельном чате нашего дискорд канала: https://discord.gg/aNfW5FQ в том-же формате, что и самый первый пост.

Ближайший пост будет посвящен созданию планет, их поверхностям, и как это работает в сетевом окружении, а так-же более подробно расскажу о Вселенной Синтеза.

В общем хотел еще вчера залепить пост о том, как я перешел на каскадные модули, но вместо этого придется просить помощи, ибо я себе уже мозг сломал =/

В общем суть. Это кусок дебага в конфигурации DevEditor x64; юнит Runtime/Engine/Private/Particles/ParticleGPUSimulation.cpp

Из моего кастомного каскадного модуля приходят локация и размер частицы. Дальше это передается уже штатным кодом на указанный выше юнит. Локация выставляется; а вот с размером происходит следующая фигня:

Она попадает в переменную BaseSize (1.5 по X и Y это норм);

Дальше высчитывается UVFlipSizeOffset. Оно 0.5 по условию

потом идет пересчет сайза по X и Y. Тут уже странность, ибо он становится 7.49 по осям

А вот после суммирования с UVFlipSizeOffset происходит какая-то магия, ибо на выходе у меня всегда 0.5 по осям (независимо от BaseSize).

За любую помощь буду признателен.