Жду новый пост

Серия «Вся наша жизнь спираль»

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

Во первых. Система Universal Entity Framework (он же Universal Asset) полностью себя оправдала.

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

Уже переписан редактор Вселенной (Tier2 в дорожной карте [кто не в курсе ознакомиться можно в тут: https://trello.com/b/Hdqa2t0k/cold-fusion ]), и начата проработка редактора Звездных систем:

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

Ну и вот как-то так. Буду надеется, что к концу второго квартала так-же будет чем поделиться.

И снова здравствуйте. С Вами ТехноМаг, и сегодня поговорим о том, что было нами сделано за этот год.

Большую часть времени конечно сожрал откат с Unreal Engine 5 на Unreal Engine 4. Подробнее я об этом писал в своем прошлом посте, поэтому останавливаться на этом не будем.

Вторая часть года была посвящена целиком и полностью редакторному коду. И вот тут появились проблемы, о которых я и хочу поговорить сегодня.

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

Как вы знаете, в Unreal Engine вся игровая логика строится вокруг Актера. Актера можно назвать минимальной игровой логической сущностью. Он-же выступает в качестве носителя сетевой логической сущности и это не изменить без существенного переписывания движка, чего я всеми силами пытаюсь избежать. Поэтому, последние несколько месяцев я работаю над дополнительным носителем игровой логики. Эта сущность (Entity - не путать с Entity в ECS) является по большей части клоном актера с порезанным функционалом. И именно в них мы сейчас упаковываем игровую логику. Актеры же в свою очередь переехали в разряд визуализации (на столько, на сколько это возможно). Такой метод поможет нам условно разделить игровой код на две составляющие (backend и frontend), что хорошо скажется на сетевом взаимодействии, а так-же на на общем производительности системы (будет меньшее кол-во операций на обсчете объекта c полной трансформой, т.к. эти расчеты будут выполнены на бэкенде и закэшированы по возможности).

Таким образом родился новый Фреймворк, который был назван "Universal Asset"). И сейчас я работаю над тем, чтобы внедрить его в уже написанный код, и подружить уже созданный инструментарий для работы с ним.

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

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

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

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

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

Отдельно, я хочу поблагодарить Александра. Саша, спасибо тебе огромное, что тратишь свое личное время и помогаешь нам с косяками в моделях. Без тебя это все затянулось бы на гораздо большее количество времени.

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

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

Что-же было сделано за 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 подойдет лучше всего.

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

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

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

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