Как я сделал бесшовный переход в космос

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

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

Когда в декабре 2013 года анонсировали No Man’s Sky, бесшовный переход с поверхности планеты в открытый космос все еще казался диковинкой, несмотря на то, что уже был реализован в Kerbal Space Program, Space Engine, Star Citizen, а также в нескольких трехмерных астрономических или исследовательских программах, вроде Celestia или Proland. В наши дни игроков сложнее удивить подобным, более того наличие этой функции ожидают ото всех серьезных космических симуляторов.

Но насколько сложна реализация подобного перехода в космос? Этим вопросом я задался в 2018 году, когда начал разработку своего космического симулятора. Для тех, кому интересно чуть глубже изучить данный вопрос, я написал две статьи, об исследовании предметной области и техническую статью о том, как приступить к генерации планет. Здесь же я буду рассматривать, что конкретно требуется от игрового движка, чтобы эту функцию на нем можно было бы реализовать.

Рендеринг атмосферы и рассеяние света частицами

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

Атмосфера делает любую планету красивее

Хотя Луна красива и без нее

Но при этом размер планеты и ее масштаб почувствовать сложнее

Стоит также отметить, что для бесшовного перехода атмосфера должна быть сферической, так как вы можете подлететь к планете с любого направления и улететь в любую сторону. Тогда как большинство современных игр и движков поддерживают отрисовку физически корректных атмосфер с рассеиванием света, в большинстве своем они «плоские». То есть предполагается, что у системы координат есть фиксированное направление «вверх», а камера будет всегда находиться у поверхности планеты. Это позволяет сократить количество вычислений и сэкономить немного времени на рендеринге кадра, но абсолютно не подходит для бесшовного перехода.

В данном случае станция летит над южной частью Тихого океана, то есть внизу Земли

Генерация планеты с динамическим уровнем детализации

Отрисовать планету в виде сферы с наложенной на нее текстурой может абсолютно любая игра. Однако, если делать возможность посадки на нее без загрузок, нужно будет реализовывать генерацию поверхности на лету. Чем ближе игрок приближается к поверхности, тем более детализированной она должна быть. Чтобы компьютеры игроков не плавились от нагрузки, выдавая при этом 15 фпс и периодически вылетая на рабочий стол с ошибкой «out of memory», нужно генерировать и отрисовывать только ту часть планеты, которая в данный момент видна в камере. Соответственно в память загружается только необходимые данному участку ресурсы, в виде карт высот, текстур и объектов поверхности. Всего того, что находится вне камеры, не должно существовать. То есть игровой движок должен поддерживать стриминг ресурсов хоть в каком-то виде. Сами же алгоритмы генерации, динамического LOD и прочих вещей хорошо описаны в десятках научных работ, и после небольшого исследования поддадутся реализации большинству программистов со стажем работы в несколько лет.

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

Отсутствие фиксированной системы координат и статических объектов

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

В обычных играх загружается сцена tatuin.scene. На ней в координатах (x: 54.32, y: 0, z: 122) стоит здание академии. Когда бы вы не загрузили эту сцену, здание будет всегда там стоять, независимо от того, была ли реализована смена дня и ночи, или нет. Это статичность позволяет уже на стадии создания игрового билда рассчитать множество данных, которые можно будет использовать в игре для ускорения вычислений. Например, навигационную сетку, коллизии, глобальное освещение, occlusion culling и много еще чего.

В случае космического симулятора академия будет находиться по координатам 44°25′ с. ш. и 38°12′ в. д. Далее необходимо знать позицию планеты в звездной системе, и текущее время. Используя эти данные, мы можем рассчитать координаты здания на поверхности относительно центра планеты (с учетом текущего ее вращения). И далее преобразовать в координаты относительно игровой камеры. Только после этого здание можно отрисовать. Как можно понять из описания, координаты здания будут разными и зависеть от текущего времени. В результате количество расчетов, которые можно провести заранее сильно уменьшается. Все это придется считать в рантайме, отбирая ресурсы у геймплея или рендеринга.

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

Облака, которые неплохо работают в плоских сценах

Ломаются при попытке использовать их в космическом симуляторе

Floating origin

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

Здесь сферу начинают двигать от центра координат в начале видео до 60 000 км в последних кадрах

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

И много чего еще

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

Цена разработки

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

Так что там со Старфилдом

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

Но есть одно но.

Bethesda активно переиспользует наработанные за многие годы игровые системы. Как отмечают многие, Старфилд построен по той же формуле, что и Фаллаут, а Фаллаут по тем же лекалам, что и серия свитков. Всем этим играм достаточно плоской сцены с фиксированными координатами и кучей заранее рассчитанных данных. Со всем этим гораздо проще работать, расставлять постройки, двигать персонажей и раскидывать лут. И весь код, который был написан за многие годы, заточен именно под это. Добавление бесшовного перехода потребовало бы совершенного другого подхода к построению игрового мира, новый набор инструментов разработки, а также примерно полное переписывания всех систем, которые готовы и использовались ранее. Судя по всему, Тодд и его команда не были готовы пойти на такое.

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

Эта статья не ставит перед собой целью защищать или осуждать Старфилд. Я надеюсь у тех, кто прочитал ее до конца, прибавилась немного знаний о рассматриваемом предмете, что позволит более аргументированно отстаивать свою позицию в спорах и комментариях на просторах этого сайта.

Прощальный скриншот из страны багровых туч