Обзор версии Godot 4.7: Архитектурные инновации, экосистема разработчиков и стандарты производства

Будучи одним из самых важных и инновационных представителей экосистемы движков с открытым исходным кодом, Godot вместе со стабильным релизом (stable release) 4.7, выпущенным 18 июня 2026 года, достиг критического уровня зрелости в плане архитектурной гибкости, графической точности и эргономики разработчика 1. В то время как предыдущие версии были сосредоточены на стабилизации базовых систем движка и устранении критических ошибок, версия 4.7 демонстрирует структуру, "ориентированную на производство и рабочий процесс", которая напрямую нацелена на решение узких мест, с которыми профессиональные студии и инди-разработчики сталкиваются в своей повседневной работе на этапе производства 3. Вместе с патчем обслуживания 4.7.2, вышедшим 18 августа 2026 года, были устранены координаты теней PCSS, производительность мышей с высокой частотой опроса (polling rate) в Windows и мелкие шероховатости в сценариях многопоточной (multiplayer) репликации, что закрепило стабильность движка в производственной среде (production-ready) 5.

Godot 4.7 — это не столько принципиально новый физический движок или полностью переписанный конвейер рендеринга, сколько глубокий пакет улучшений, который расширяет существующие инфраструктуры рендеринга Forward+ и Mobile, решает хронические проблемы с анимацией пользовательского интерфейса (UI), стандартизирует процессы мобильной разработки и отвечает современным аппаратным требованиям, таким как расширенный динамический диапазон (HDR) 2. Оценки сообщества и профессионалов индустрии показывают, что разработчики, много лет использовавшие различные проприетарные движки (например, Unity), особенно впечатлены возможностями рендеринга и возможностями быстрого прототипирования Godot 4.7 2. В этом отчете в чрезвычайно всеобъемлющих аналитических рамках рассматриваются технические новинки, предлагаемые Godot 4.7, их влияние на архитектуру программного обеспечения, отзывы сообщества и стратегические соображения проектов при переходе на эту новую версию.

Инновации в движке рендеринга и инфраструктуре 3D-графики

Конвейер обработки графики — одна из областей, где Godot 4.7 добился наиболее заметных успехов. Тонкий баланс между фотореализмом и оптимизацией производительности в современной разработке игр зависит от разнообразия инструментов, предлагаемых движком рендеринга, и возможностей аппаратного ускорения. Новая версия предлагает аналитические функции, соответствующие отраслевым стандартам на многих уровнях: от расчетов освещения до управления материалами.

Ареальные источники света (AreaLight3D) и физика освещения

Модели освещения — это самый фундаментальный элемент, определяющий визуальную достоверность 3D-движков рендеринга. До появления Godot 4.7 разработчики были вынуждены группировать точечные источники света (point lights) или использовать материалы с эмиссией (emissive), подкрепленные глобальным освещением (Global Illumination), для симуляции прямоугольных или широкоформатных источников света (например: неоновых вывесок, огромных промышленных окон, телевизионных экранов, люминесцентных ламп или мягкого студийного освещения) 1. Эти временные и косвенные решения создавали ненужную нагрузку на GPU с точки зрения производительности, а также были неудовлетворительными с точки зрения мягкости краев получаемых теней (полутени/penumbra) и их физической точности.

Добавленный в архитектуру базовых узлов вместе с Godot 4.7 узел AreaLight3D предлагает аналитическое решение для рендеринга в реальном времени, которое гарантирует, что свет исходит не из бесконечно малой единичной точки, а из ограниченной двухмерной прямоугольной площади поверхности 1. Эта структурная архитектура создает естественные и постепенно смягчающиеся переходы теней в зависимости от физического размера источника света, а также гарантирует правильное отражение прямоугольной формы источника света на гладких и отражающих поверхностях (specular reflections) в сцене 1. Этот подход, не требующий трассировки лучей (ray tracing), драматически повышает качество освещения сцен без превышения бюджета производительности. С точки зрения архитектурной визуализации, игр ужасов в закрытых помещениях (indoor horror) и создания кинематографической атмосферы эта разработка предоставляет дизайнерам сцен гораздо более чистый рабочий процесс и превосходное визуальное качество.

Поддержка вывода изображения с высоким динамическим диапазоном (HDR)

С развитием технологий отображения оборудования, выходящего за рамки стандартного цветового пространства sRGB, стало стандартом на рынке конечных пользователей. Godot 4.7 получил возможность передавать данные освещения с высоким динамическим диапазоном, которые движок внутренне рассчитывает в формате с плавающей запятой (floating point), напрямую на поддерживаемые дисплеи через API HDR на уровне операционной системы 2. Эта функция, которая теоретически поддерживает значения яркости до 10 000 нит, позволяет демонстрировать такие элементы, как взрывы, неоновый свет, эффекты магии или прямой солнечный свет, с ослепительной яркостью на экране, глубоким черным цветом и гораздо более широкой цветовой гаммой (color gamut) 3.

Поскольку поддержка вывода HDR требует интеграции очень низкого уровня с аппаратными драйверами и оконными менеджерами операционной системы (window manager), зависимости от платформы и движка рендеринга специфичны. Матрица конфигурации интеграции этой функции подробно описана в следующей таблице:

Операционная система / ПлатформаСостояние поддержки HDRТребуемый движок рендерингаПримечания по архитектуре и интеграцииWindowsПолная поддержкаForward+ или MobileНастройки Windows HD Color на уровне операционной системы должны быть включены, и должен использоваться совместимый монитор.macOSПолная поддержкаForward+ или MobileИнтегрировано напрямую с собственными API управления HDR от Apple и интерфейсом Metal.iOS & visionOSПолная поддержкаForward+ или MobileСовместимо с возможностями высокой яркости мобильных устройств Apple и структурой экранов XDR.Linux (Wayland)Полная поддержкаForward+ или MobileРаботает только под управлением современных композиторов Wayland. Требует комплексного протокола управления окнами.Linux (X11)Не поддерживаетсяНеприменимоОтключено из-за ограничений глубины цвета в старой архитектуре X11. Разработчики должны перейти на Wayland.AndroidНе поддерживаетсяНеприменимоВ настоящее время недоступно из-за широкой фрагментации оборудования Android (fragmentation).Web (HTML5)Не поддерживаетсяНеприменимоОграничения графических API браузеров WebGL и WebGPU пока еще не стандартизировали вывод HDR.

Как видно из таблицы, использование HDR следует рассматривать не как целостное требование (requirement), а как опциональный слой визуального обогащения, который включается на поддерживаемых платформах 4. Разработчикам следует рассматривать HDR не как основу всего художественного руководства (art direction), а как полировку, которая еще больше обогатит проекты, хорошо выглядящие и в стандартном динамическом диапазоне (SDR) 4.

Инфраструктура аппаратной трассировки лучей (Ray Tracing) в Vulkan

Технология аппаратной трассировки лучей, являющаяся одним из крупнейших технологических переломных моментов в игровой индустрии, была интегрирована в Godot 4.7 в качестве низкоуровневой (low-level) сантехнической инфраструктуры (plumbing) в архитектуру Vulkan движка 2. Эта версия не содержит функций прямой работы для конечного пользователя, таких как «Отражения на основе трассировки лучей» (Ray-traced reflections) или «Трассировка путей» (Path tracing), которые игроки или разработчики могут активировать одним кликом 10. Вместо этого в движок были добавлены возможности построения структур ускорения (acceleration structures), являющихся фундаментальными требованиями трассировки лучей, и прямого запуска лучей (ray dispatch) из конвейера рендеринга Vulkan 2.

Этот стратегический инженерный шаг предоставляет стандартизированную основу для крупных студий, позволяющую им писать собственные специфические решения для трассировки лучей (например, пользовательские шейдеры освещения или зеркальные системы). В прошлые годы команды, желавшие использовать аппаратную трассировку лучей, зависели от специализированных форков Godot (fork), поддерживаемых NVIDIA или независимыми разработчиками 2. Эта интеграция ядра, поставляемая с версией 4.7, является четким доказательством того, что встроенные функции трассировки лучей в будущих версиях, таких как Godot 4.8 и 4.9, будут работать непосредственно на основном движке (mainline) 2.

DrawableTexture2D и обработка текстур во время выполнения

Операция «рисования поверх текстуры во время выполнения» (runtime texture drawing), которая часто требуется в игровой механике, в предыдущих версиях выполнялась с помощью косвенных и высокозатратных операций, таких как создание отдельного Viewport и рендеринг сцены внутри этого viewport или отправка низкоуровневых команд GPU через сложные API RenderingDevice. Godot 4.7 абстрагировал эти сложности и представил класс DrawableTexture2D, который представляет собой чрезвычайно доступный и производительный API 2.

DrawableTexture2D позволяет разработчикам записывать данные пикселей или мазки кисти прямо поверх текстуры (texture) с помощью стандартных вызовов blit 2. Эта функция позволяет даже разработчикам, не обладающим глубоким пониманием API рендеринга, легко создавать сложные эффекты. Например, с помощью этого API можно разрабатывать маски тумана войны (fog of war), которые можно исследовать в стратегических играх, динамические следы от колес в гоночных играх, механику разбрызгивания краски персонажами по поверхностям (paint tools), инструменты для свободного рисования игроками, игры с масками стирания/проявления (reveal mask) или текстуры брони, деформирующиеся при получении урона (scratch effects), без создания дополнительной нагрузки на основную систему 1.

Пиксель-арт и 3D-визуал: Масштабирование Nearest-Neighbor

Традиционные 3D-движки рендеринга при проецировании низкоразрешенных текстур, покрытий или вывода экрана по умолчанию используют билинейную (bilinear) фильтрацию. Хотя этот алгоритм сглаживания дает отличные результаты в фотореалистичной графике, он приводит к нежелательному размытию (blurring), особенно в играх, имитирующих ретро-стиль 90-х годов (эстетика PS1), или в 3D-играх с низким разрешением в стиле пиксель-арт 2. Многие разработчики в сообществе были вынуждены писать специальные шейдеры только для того, чтобы избавиться от этих шероховатостей. Godot 4.7 интегрирует опцию масштабирования Nearest-Neighbor (ближайший сосед) для 3D-областей просмотра (viewport) в качестве стандартной функции движка, предлагая отличный инструмент эстетического контроля, который сохраняет четкость пикселей и резкие линии даже при снижении разрешения 1. Эта функция создала незаменимую инфраструктуру для инди-проектов, сочетающих современные 3D-возможности с ностальгическим подходом пиксель-арта.

Шейдеры (Shaders), эффекты и улучшения материалов

Постпроцессинговые эффекты (post-processing), определяющие визуальный язык игры, и системы частиц также прошли детальную оптимизацию. Самым большим нововведением для разработчиков, работающих с текстовыми шейдерами на основе кода (text shaders), являются встроенные (inline) превью шейдеров прямо внутри редактора. Теперь, когда в коде шейдера делается математическое изменение (например, изменяется частота волновой функции), изменения можно просматривать в реальном времени прямо в фоновом режиме редактора кода без необходимости перекомпиляции движка или перехода в другую рабочую область 2. Это разработка, которая чрезвычайно увеличивает скорость итераций.

Что касается материалов физически корректного рендеринга (PBR), то алгоритмы рендеринга лака (clearcoat), используемые для симуляции таких поверхностей, как автомобильная краска или мокрый пол, были улучшены; преломление света через эти прозрачные слои стало более точным 1. Проходы рендеринга (render passes) теперь могут содержать собственные отдельные буферы униформ (uniform buffers) окружения (environment), что обеспечивает гибкость в сложных цепочках постпроцессинга 1. В системах 3D-частиц разработчикам были предоставлены расширенные элементы управления масштабом (scale) и вращением (rotation) частиц, а также применены математические исправления угловой скорости (angular velocity) частиц, чтобы симуляции выглядели более органично 1.

Интерфейс пользователя (UI) и анимационные

Системы

В процессах разработки игр дизайн пользовательского интерфейса — это область, которая обычно отнимает гораздо больше времени, чем кодирование базовой механики игры, отличается высокой степенью итеративности и чрезвычайно хрупкой структурой 9 . Чтобы элементы интерфейса могли адаптироваться к изменяющимся разрешениям на игровом экране, Godot изначально предлагает надежную систему компоновки на основе узлов (node-based). Однако версия 4.7 разрешает фундаментальную структурную проблему взаимодействия элементов интерфейса с анимациями, представляя один из самых способных наборов инструментов UI в индустрии 9 .

Преобразования смещения узла Control (Offset Transforms)

Система компоновки (layout) UI в Godot построена на иерархических узлах Container (Контейнер). Узлы Control (кнопки, панели, полосы прокрутки и т. д.), помещенные внутрь HBoxContainer (горизонтальный контейнер) или VBoxContainer (вертикальный контейнер), жестко управляются алгоритмами автоматической сортировки и размещения контейнера 1 . В прошлых версиях, когда дизайнер увеличивал масштаб (scale), угол поворота (rotation) или положение (position) кнопки с помощью анимации Tween для создания визуального отклика при наведении курсора (hover state), это изменение воспринималось родительским контейнером как «нарушение компоновки». Контейнер мгновенно выполнял перерасчет, пытаясь вернуть элементы интерфейса на место в соответствии со своей алгоритмической логикой, что приводило к нежелательному подпрыгиванию (snap back) кнопок, дрожанию меню и вынуждало разработчиков буквально вести войну с системой контейнеров (fighting layout) 1 .

Самым критическим решением, которое Godot 4.7 привносит в инженерную часть UI, является система смещения узла Control (offset transforms), которая отделяет визуальные преобразования от логической блочной модели (box model). Недавно добавленные свойства offset_transform_* (позиция, вращение, масштаб) определяют, как элемент интерфейса будет отрисовываться визуально, оставляя его логические координаты и занимаемую площадь в исходном виде 1 . То есть, когда кнопка визуально увеличивается на 20% или смещается на экране с помощью преобразований смещения, родительский контейнер не воспринимает это изменение как обновление компоновки и сохраняет расчеты размещения 4 . Эта изоляция предоставляет разработчикам UI и техническим художникам полную возможность проектировать плавные, динамичные и гибкие анимации интерфейса без нарушения структуры контейнера или логики привязки (anchoring) 4 . Отзывы сообщества подтверждают, что эта функция устраняет сотни строк обходного кода (workaround) при разработке меню и является «спасением» 9 .

Метки богатого текста (RichTextLabel) и конические градиенты

Возможности отображения данных в пользовательских интерфейсах были улучшены в соответствии с требованиями современного игрового процесса к динамическому изменению размера шрифта. Изображения, встроенные в RichTextLabel с помощью тега [img] (например, кнопка «A» на контроллере Xbox или специальный значок эмодзи, отображаемый внутри текста), теперь могут позиционироваться с учетом размера встроенного текста 1 . Используя относительные определения в стиле CSS, такие как [img height=1em], разработчики могут обеспечить автоматическое пропорциональное масштабирование изображения вместе с текстовым шрифтом при изменении разрешения игры, локализации или настроек доступности 3 .

Кроме того, в класс GradientTexture2D, используемый для создания цветовых спектров в области 2D-эффектов и дизайна UI, добавлен режим FILL_CONIC (коническое заполнение). В отличие от стандартных линейных или круговых градиентов, эта функция конического градиента распределяет цвета путем их смещения (sweep) вокруг центра, аналогично стилям CSS. Это математическое дополнение создает чрезвычайно практичную основу для написания 2D-шейдеров, создания круговых индикаторов выполнения, датчиков боеприпасов, эффектов сканирования радара или иллюзий имитации 3D-шейдеров (fake 3D shading) 3 .

Экосистема редактора и улучшение рабочего процесса разработчика

Игровые движки — это не просто компиляторы, создающие исполняемые файлы; это еще и программное обеспечение для повышения производительности и разработки (IDE), в котором дизайнеры, художники и программисты проводят тысячи часов. В этом контексте плавность интерфейса редактора напрямую влияет на время разработки. Godot 4.7 включает в себя множество обновлений, повышающих качество жизни (Quality of Life - QoL), которые оптимизируют работу в редакторе, сокращают количество кликов и снижают когнитивную нагрузку в крупных проектах.

Рождение Asset Store (Бывший Asset Library)

Библиотека ресурсов Asset Library, которая в течение многих лет предоставляла разработчикам Godot возможность скачивать созданные сообществом инструменты, уступила место концепции Asset Store (Магазин ресурсов), написанной с нуля в соответствии с современными стандартами API 2 . Это не просто косметическое изменение названия, а инфраструктурная архитектурная ревизия. В старой системе главный поток редактора (main thread) блокировался при загрузке массивных пакетов ресурсов с сервера или обработке поисковых запросов, что приводило к зависаниям. Новый API магазина активно использует фоновые потоки (background threading) 1 . Благодаря этому во время скачивания контента интерфейс редактора остается полностью отзывчивым (responsive) 3 . Кроме того, интегрированы возможность приближения (zoom) изображений предварительного просмотра для более детального изучения ресурсов, отображение актуальных рейтингов от сообщества и гораздо более чистое дерево категорий (витрина) 3 .

Усовершенствования инспектора (Inspector) и свертывание дорожек анимации

Одной из точек наибольшей потери времени для разработчиков в крупномасштабных 3D-проектах является передача сложных структур данных между узлами. Благодаря новому инструменту панели, добавленному на панель Inspector в Godot 4.7, вместо того чтобы поодиночке копировать и переносить переменные (например, повороты по X, Y, Z или кодовые обозначения материалов) между похожими узлами, стало возможным массово копировать всю группу свойств (property section) и вставлять ее в соответствующее поле другого узла в один клик 1 . Эта механика сводит к нулю вероятность человеческой ошибки при пакетном переносе параметров материалов или иерархических конфигураций физики и обеспечивает колоссальную экономию времени 2 .

Панель AnimationPlayer и анимационных дорожек (Animation Tracks), используемая для управления анимацией сложных сцен, также была эргономически переработана. Чтобы предотвратить заполнение экрана дорожками и хаос прокрутки при анимировании сложного скелета персонажа с 40–50 различными дорожками, была внедрена функция «сворачивания неиспользуемых дорожек узлов» (track collapsing) 1 . Ключевые кадры (keyframes) на свернутых дорожках представлены в виде «совокупного представления» (aggregate representation) на одной строке; таким образом, аниматоры продолжают получать визуальный ориентир относительно общего тайминга (timing) анимации даже без просмотра конкретных деталей внутри свернутых дорожек 3 .

Привязка в 3D-сцене (Snapping) и улучшения линейки

Инструменты манипуляции сценой были значительно усилены для 3D-художников и левел-дизайнеров, занимающихся дизайном уровней и построением миров (world building). До Godot 4.7 объединение агро-ресурсов и размещение их на поверхностях выполнялось в основном на глаз или путем ввода числовых значений. Новая версия предлагает три основных набора инструментов, отвечающих отраслевым стандартам:

Привязка к вершинам (Vertex Snapping): При удерживании назначенной комбинации клавиш на клавиатуре в редакторе (по умолчанию 'B') разработчик может напрямую выбрать конкретную точку вершины 3D-меша (mesh) и зафиксировать (snap) ее к точкам вершин других объектов с миллиметровой точностью 1 . Это предотвращает появление зазоров при создании модульных конструкций подземелий или строительных блоков.
Привязка Path3D и коллайдеров (Collider Snapping): Точки узла Path3D, используемые для рисования траекторий в сценах, теперь могут выравниваться не только по плоскости камеры видоискателя (camera plane), но и непосредственно по поверхностям физических коллайдеров (colliders) в сцене 1 . Эта функция обеспечивает жизненно важное удобство при рисовании маршрутов патрулирования искусственного интеллекта (patrol paths) или траекторий гоночных треков, перемещающихся по гористым или наклонным ландшафтам 3 .
Усовершенствованная линейка (Ruler): Инструмент 3D-измерения, используемый с клавишей-модификатором Shift, теперь отображает не только абсолютное расстояние между двумя точками (например, 15 метров), но и относительные векторы длины вдоль каждой оси координат (X, Y, Z) в трехмерном пространстве (например, 10 м по оси X, 5 м по Y и 10 м по Z) по отдельности 1 . Эта геометрическая обратная связь крайне важна при проектировании уровней на начальном этапе, известном как Blockout. Кроме того, элементы управления 3D-камерой были объединены (unified) со встроенным игровым окном (embedded game view) внутри движка, что гарантирует сохранение одинаковых сочетаний клавиш или схемы навигации разработчика с обеих сторон 3 . Для облегчения поиска нужных объектов в длинных списках в окна PopupMenu была добавлена поисковая строка; а в экраны создания нового узла (Node) или ресурса (Resource) (Create Dialog) интегрированы механизмы фильтрации, такие как «Показывать только пользовательские» (Show Custom) 1 . Разработчик, работающий в редакторе кода, дважды щелкнув по имени файла над окном скрипта, может автоматически подсветить (highlighted) местоположение этого файла в файловой системе слева, что предотвращает потерю в больших деревьях данных 3 . На экране Remote Scene Inspector (Инспектор удаленной сцены) значения Enum теперь отображаются не просто как бессмысленные целые числа (0, 1, 2), а с именами строк (string names), представляемыми в коде 3 .

Мобильная разработка, виртуальная реальность (XR) и оптимизация производительности

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

Встроенная интеграция VirtualJoystick (Виртуального джойстика)

Команды, разрабатывающие экшены или ролевые игры для мобильных платформ, долгое время зависели от сторонних плагинов для экранных виртуальных сенсорных элементов управления или написанного с нуля кода ввода (input), который сложно поддерживать. Сообщество плагинов несет риск поломки при каждом обновлении движка4. Godot 4.7 коренным образом решает эту проблему фрагментации, предлагая узел VirtualJoystick, интегрированный непосредственно в ядро движка1.

Эта интеграция поддерживает три различных модели взаимодействия, полностью совместимые с классическими схемами управления в мобильном геймдизайне:

Режим джойстикаМеханика и поведение пользователяИдеальный сценарий использованияФиксированный (Fixed)Позиция джойстика на экране фиксирована. Игрок должен перетаскивать большой палец в эту конкретную область экрана. В центре предусмотрена классическая настройка «мертвой зоны» (dead zone).Ретро-аркадные порты, консольные стационарные контроллеры1.Динамический (Dynamic)Джойстик появляется в точке экрана, к которой прикасается игрок. Когда палец убирается, он мгновенно исчезает, сбрасывая свою позицию.Шутеры, требующие быстрой реакции1.Случайный / Следующий (Following)Начинается по тому же принципу, что и динамический режим, но когда большой палец игрока выходит за пределы границ движения, центральная ось джойстика также смещается вслед за пальцем, обеспечивая постоянный контакт игрока.RPG или бесконечные раннеры, в которых персонаж движется безостановочно1.

Кроме того, была обеспечена возможность чтения данных акселерометра и гироскопа с контроллеров через API, а интеграция элементов управления наклоном и движением (motion), предоставляемых мобильными или консольными игровыми геймпадами, стала стабильной3.

GABE (Godot Android Build Environment) и разработка прямо на устройстве

Видение Godot, заключающееся не только в разработке игр для Android, но и в концептуальном подходе «разработки игр непосредственно на планшетах и мобильных устройствах под управлением ОС Android (on-device)» (Godot Editor for Android), сделало большой скачок в версии 4.7. Благодаря специальному сопутствующему (companion) приложению под названием GABE (Godot Android Build Environment), редактор Godot, работающий на устройствах Android (например, на Samsung Galaxy Tab), получил поддержку экспорта Gradle прямо внутри устройства, необходимую для создания APK или AAB3. Это означает, что разработчик может компилировать код, написанный на устройстве, прямо на самом устройстве и создавать полноценные пакеты сборки (APK) без необходимости использования компьютера4.

Эргономические ограничения редактора, работающего на Android, также были преодолены. Встроенное игровое окно во время выполнения (embedded game window) теперь стало не фиксированным, а изменяемым по размеру и перетаскиваемым; таким образом, различные соотношения сторон экрана (aspect ratios), такие как альбомный, портретный или формат планшета, получили возможность тестирования с одного устройства1. Экран написания скриптов (script) стал поворачиваемым (landscape coding), реагируя на датчики ориентации устройства по горизонтали/вертикали, что повысило эргономику при подключении клавиатуры4. Кроме того, благодаря функции «Картинка в картинке» (Picture-in-Picture) процессы тестирования стали гораздо более модульными, а игра стала доступна для просмотра даже при работе в фоновом режиме1. Возможности экспорта были расширены, и экраны заставки (splash) проектов для Android теперь получили настраиваемую структуру1.

Однако в этот момент стоит обратить внимание на предупреждения о производительности, поступающие от экосистемы разработчиков. Хотя 3D-движок Godot обладает продвинутыми возможностями, при использовании движка Compatibility (GLES3/OpenGL), особенно на мобильных устройствах, на устройствах со средними GPU, такими как Mali G68, могут возникать ограничения рендеринга. Аналитика индустрии (например, отчеты о тестировании на Reddit) показывает, что в простой сцене с очень небольшим количеством фоновых объектов и всего 3000 полигонов частота кадров может падать до 38 FPS, если не уменьшить масштаб разрешения16. По этой причине при разработке 3D-продуктов для платформы Android разработчики должны уделять максимальное внимание масштабированию разрешения видового экрана (viewport resolution scale), простоте материалов и разнообразию тестовых устройств16.

Расширенная реальность (XR): Слои композиции и foveated rendering

Архитектура OpenXR, ставшая отраслевым стандартом на рынке виртуальной (VR) и дополненной реальности (AR), в Godot 4.7 стала еще более ориентированной на продакшн2. Наряду с обеспечением поддержки промышленного уровня (production-ready) для платформ Steam Frame и Android XR, карты действий OpenXR (action maps) были сведены к четырем основным профилям, что снизило сложность интеграции контроллеров1.

В процессах разработки VR читаемость интерфейса (UI) является наиболее критической эргономической задачей. Размещение индикаторов на лобовом стекле (HUD) или текста в сцене как стандартной 3D-геометрии (рендеринг буфера глаза) приводит к дрожанию, размытости и нечитаемости текста из-за фокусного расстояния и плотности пикселей линз. Система слоев композиции (composition layer) OpenXR переносит интерфейсы за пределы стандартного буфера игрового мира и выводит их непосредственно на слой проекции визора (на проектор)3.

Godot 4.7 углубил контроль над этими слоями композиции. Разработчики теперь могут:

Привязывать (lock) и фиксировать слои композиции непосредственно к узлу XRCamera3D в сцене, проектируя сверхчеткие (crisp) экраны HUD, которые остаются неподвижными в поле зрения без единой миллисекунды задержки, как бы быстро игрок ни поворачивал голову3.
Связывать объекты слоев композиции с мировой геометрией (world geometry), оставляя текстовые слои зафиксированными в пространстве в определенных координатах (world-locked)3.

В контексте графической производительности гарнитуры VR (например, Meta Quest) представляют собой устройства с огромным разрешением, и экономия каждой миллисекунды имеет жизненно важное значение для комфорта (comfort)4. В мобильный рендерер (Mobile Render) в Godot 4.7 интегрирована технология подвыборочных изображений (Subsampled images) Vulkan1. Эта технология существенно снижает пропускную способность памяти GPU (memory bandwidth), сохраняя пиксели, обрабатываемые в процессах foveated rendering (рендеринг с фиксированной фовеацией: резкий рендеринг в центре внимания глаза и с низким разрешением в периферийном поле зрения), с меньшей плотностью3. Благодаря этому достигается огромный прирост производительности и экономии заряда

батареи мобильных устройств 1 . Для проектов XR рекомендуется использовать мобильный рендерер по умолчанию 1 .

Философия физики и продвинутый набор 2D-инструментов

Системы физики и алгоритмы столкновений составляют поведенческое сердце игровых движков. Начиная с версии 4.6, Godot включил высокопроизводительный плагин Jolt Physics в качестве физического 3D-движка по умолчанию в базовую экосистему. Вопреки некоторым слухам в индустрии, версия 4.7 не заменяла и не отменяла Jolt Physics; движок Jolt продолжает сохранять свою стабильность в рабочей среде в качестве физического движка по умолчанию (default) для новых 3D-проектов и архитектуры 4.7 1 . Однако настоящую физическую революцию версия 4.7 совершила, преодолев давнее ограничение в архитектурах 2D-столкновений.

Свобода направления односторонних столкновений (One-way Collision)

В 2D-платформерах (например, платформы в виде облаков или подвесных мостов, сквозь которые персонаж может подпрыгнуть снизу и встать на них сверху, как в Mario или Hollow Knight) односторонние столкновения являются часто используемой механиком. До Godot 4.7 физический движок жестко и неизменно предполагал, что вектор одностороннего столкновения направлен строго по собственному локальному «вверх» (Up) направлению соответствующего узла CollisionShape2D (вектор (0, -1)) 3 . Когда геймдизайнеры хотели изменить направление столкновения (например, стену, сквозь которую персонаж может пройти справа, но с которой сталкивается слева), им приходилось прибегать к болезненным (painful) хитростям, таким как физический поворот или вращение коллайдера (collider) полностью независимо от визуальных графических узлов и синхронизация этих двух структур 3 .

В обновление 4.7 в класс CollisionShape2D была добавлена новая переменная под названием one_way_collision_direction (направление одностороннего столкновения) 3 . Благодаря этой особенности вектор направления односторонних взаимодействий может свободно назначаться в 360-градусном локальном пространстве, при этом общая геометрия формы столкновения (структура коробки или капсулы) никогда не нарушается 3 . Это сделало кодирование потоков сильного ветра, конвейерных лент, толкающих персонажа, зон с наклонной гравитацией или механики парения с платформ гораздо более изящным и математически точным, избавив от излишних расчетов вращения.

### Динамическое сглаживание CSG (Autosmooth)

Конструктивная твердотельная геометрия (Constructive Solid Geometry — CSG) — это инструмент, позволяющий геймдизайнерам выполнять прототипирование 3D-уровней (level) прямо внутри движка (с помощью операций сложения, вычитания, пересечения), используя простые пересекающиеся геометрические формы (куб, сфера, цилиндр) без необходимости использования внешних программ 3D-моделирования, таких как Blender или Maya 3 . Тем не менее, создаваемые полы CSG всегда выглядели резкими, низкополигональными и шероховатыми.

Новая функция Autosmooth (Автоматическое сглаживание), добавленная к корневым узлам CSG в Godot 4.7, процедурно сглаживает эти резкие многоугольные структуры на аппаратном уровне 3 . Параметр Smoothing Angle (Угол сглаживания) по умолчанию установлен на 50 градусов; стыки поверхностей ниже этого порога автоматически обрабатываются как гладкие поверхности (smooth faces), в то время как более крутые пересечения с большим углом продолжают сохранять линии углов (sharp faces) 3 . По мере увеличения значения применяется более агрессивный профиль сглаживания; эта функция позволяет не только командам, занимающимся прототипированием, но и студиям, создающим low-poly (низкополигональный) контент, переносить структуры CSG в свои игры непосредственно в качестве финального ассета (final asset) 3 .

Изменения API, написание сценариев (Scripting) и

стратегии миграции (Migration). Каждое крупное обновление минорной версии (.x) добавляет новые функции, одновременно изменяя некоторые сигнатуры API (интерфейса программирования приложений) для повышения производительности движка на фоне и содержащие критические изменения (breaking changes) на уровне кода 3 . Хотя базовой философией Godot 4.7 является сохранение обратной совместимости, существует строгая иерархия миграции, которую разработчики должны учитывать при обновлении существующих проектов 4.6 (или более старых).

Самая жизненно важная методология в процессе миграции заключается в том, чтобы ни в коем случае не открывать текущий каталог активно разрабатываемого проекта непосредственно в новой версии движка 4.7, а вместо этого создать новую тестовую ветку (branch) в системе контроля версий (VCS — например, Git) проекта или сделать полную копию всей папки 1 . Когда редактор впервые открывает проект в формате 4.7, он полностью перезаписывает все процессы импорта текстур, текста и моделей (import pipeline); поскольку этот процесс необратим, изоляция предотвращает критическую потерю данных и повреждение обратной совместимости 13 .

Нововведения в программировании и написании сценариев

GDScript, собственный динамический язык сценариев Godot, стал сильнее в версии 4.7 со стороны управления потоком и системной интеграции:

Реализация интерфейсов Java (Interfaces): Раньше для доступа к специальному железу устройств Android (API камеры, специальные датчики или платежные системы) требовалось писать промежуточные плагины на C++ или Java. В 4.7 GDScript получил возможность интегрировать интерфейсы Java напрямую внутри движка, что в значительной степени избавило от необходимости использования внешних плагинов 1 .
Приостановка твинов (tween_await): Система Tween, используемая для создания анимаций на основе кода, теперь может приостанавливать (pause) свое выполнение путем вызова функции tween_await() до тех пор, пока не будет вызван сигнал (signal) от другого объекта в системе. Эта функция представляет собой колоссальное удобство для создания асинхронных (asynchronous) цепочек анимаций 1 .

Для пользователей C# (.NET) структурная система сохраняется. Godot 4.7 продолжает предлагать два отдельных исполняемых двоичных (binary) дистрибутива: «Standard» (поддерживает C++ через GDScript и GDExtension) и «.NET» (поддерживает C# и требует .NET SDK) 1 . Если прошлый проект на базе C# открыть с помощью нового движка Standard, скрипты не будут компилироваться, что приведет к сбоям; поэтому крайне важно скачивать правильную версию 1 .

Таблица ключевых критических изменений (Breaking Changes)

В следующей таблице обобщены основные изменения при переходе с Godot 4.6 на Godot 4.7, затрагивающие существующие структуры кода, типы данных и вызовы API, что требует проведения рефакторинга:

Затронутый класс / Особенность системыИзмененный метод / Суть изменений и подробное описаниеСтатус совместимости архитектуры (GDScript / C#)Object (Ядро - Core)is_class() Тип параметра class был изменен с общего типа String на тип StringName, который работает значительно быстрее на уровне C++ и использует статическую память18. Повышает производительность при запросах объектов.GDScript: Совместимо.
C#: Двоичная и исходная совместимость.ZIPPacker (Ядро)start_file() В API добавлены два новых параметра для безопасности — permissions (права доступа к файлам) и modified_time (время изменения) для метки времени18.GDScript: Совместимо.
C#: Двоичная и исходная совместимость.OptimizedTranslationgenerate() Возвращаемое значение функции локализации языка (localization) было изменено с пустого (void) типа на логический (bool) тип для возможности отчета о статусе успешности выполнения18.GDScript: Совместимо.
C#: Двоичная несовместимость, исходная совместимость.GPU/CPUParticles2D ve 3Drequest_particles_process() В симуляции частиц был добавлен параметр process_time_residual для тонкой настройки с целью повышения физической точности18.Совместимо для всех языков.Control (Интерфейс - GUI)accessibility_live Функции доступности (accessibility), такие как программы чтения с экрана, были отделены от сервера графического экрана (DisplayServer) и перенесены в собственный тип AccessibilityServer.AccessibilityLiveMode18.GDScript: Совместимо.
C#: Полностью несовместимо (требуется ручной рефакторинг).RichTextLabel (Интерфейс)Constant (Константа) Enum Имя переменной ImageUpdateMask.UPDATE_WIDTH_IN_PERCENT, являющейся параметром определения ширины, было обновлено на ImageUpdateMask.UPDATE_WIDTH_UNIT, что больше соответствует логической структуре18.GDScript: Несовместимо.
C#: Двоичная несовместимость, исходная несовместимость.RichTextLabel (Интерфейс)add_image() / update_image() Параметры width и height были изменены с целого (int) типа на тип с плавающей точкой (float) для обеспечения гибкости в изменении размеров и поддержки относительных дробных масштабов, таких как 1em18.Совместимо для всех языков.

Процедуры проверки и тестирования после обновления

После успешного открытия проекта в среде 4.7 через систему контроля версий, даже в случае успешной компиляции, необходимо провести тесты на предмет регрессий в период выполнения (runtime) для специфических модулей:

Иерархия интерфейса (UI): Поскольку новая динамика offset_transform может повлиять на алгоритмы расчета некоторых укоренившихся вложенных родительско-дочерних (parent-child) размещений узлов, полок прокрутки (scroll views) или выпадающих меню (popup menus), экраны главного меню, инвентаря и настроек (HUD) должны быть полностью протестированы 1 .
Выражение материалов и канал рендеринга: Из-за перехода со стандартного динамического диапазона (SDR) на поддерживающие HDR каналы рендеринга в окружении, а также из-за алгоритма лакового покрытия (clearcoat), могут наблюдаться сдвиги цветов (color shifting), утечки света или различия в тенях во внешнем виде материалов PBR; все структуры освещения должны быть проверены 1 .
Настройки Android и профили XR: Требуется проверка с нуля экранов заставки (splash) Android в настройках экспорта (export presets), изменений упаковки данных OBB и карт действий OpenXR (action maps), сведенных к четырем базовым упрощенным профилям 1 .
Модули C++ GDExtension: Если использующиеся в проекте и привязанные (bind) к исходному коду движка библиотеки (GDExtensions) не были обновлены для поддержки новой сигнатуры API Godot 4.7, движок может аварийно завершить работу. Перед обновлением ненужные плагины должны быть отключены, а успешная загрузка каждого плагина подтверждена в настройках проекта 1 .

Заключение

Версия Godot 4.7 представляет собой зрелое инженерное обновление, которое отходит от маркетинговой философии «добавления медийных функций» в игровой движок и систематически нацелено на решение хронических проблем в циклах профессионального производства игр 4 . Как наглядно показывают аналитические данные из индустрии и независимых центров сообщества, таких как Reddit, была достигнута стабильность и практичность производства, способные оправдать ожидания разработчиков, переходящих с устоявшихся движков вроде Unity 8 .

Интеграция AreaLight3D и HDR-изображений доказывает компетентность движка в задачах архитектурной визуализации и высококачественных 3D-фотореалистичных проектов, в то время как включение аппаратной инфраструктуры трассировки лучей (Ray Tracing) в ядро символизирует стратегическую готовность движка к будущим визуальным стандартам 2 . С другой стороны, преобразования смещений в узлах Control устранили одну из главных проблем разработчиков UI — проблему «нарушения компоновки»; а интеграции VirtualJoystick и GABE положили конец внешней зависимости (плагинам) для мобильного рынка 1 . Благодаря системам субдискретизированных изображений (subsampled images) Vulkan, поддерживающим foveated rendering (фовеальный рендеринг), также были максимизированы пределы производительности на оборудовании XR 1 .

Движок Godot Engine, формируемый на основе философии открытого исходного кода и труда сотен контрибьюторов (contributors), в версии 4.7 продемонстрировал самый стабильный, дружелюбный к разработчикам (developer-friendly) и максимально использующий современные возможности оборудования вариант поколения 4.x.

Стратегия изолированной миграции версий, осуществляемая с учетом детально описанных изменений API, границ совместимости и процедур тестирования существующих проектов, несомненно выведет на высший уровень скорость производства (iteration time) в проектах студий-разработчиков, расходы на поддержку продуктов и графическое качество игр в глазах конечных пользователей.

*Примечание: Изображения сгенерированы с помощью Google Gemini.

Обзор нововведений Godot 4.7