Оптимизация больших архитектурных сцен по стандартам геймдева

Большая архитектурная сцена — это не набор моделей, а сложная система из геометрии, материалов, источников света, отражений и камерных сценариев. Когда мы переносим такую сцену из CAD в интерактивный 3D-тур или VR-просмотр, недостаточно просто экспортировать файл. Нужно оценить стоимость каждого элемента: сколько полигонов уходит на плинтус, который никто не рассматривает вблизи, или сколько draw calls генерирует сотня уникальных материалов на мебели. Геймдев-подход — это про контроль бюджета кадра, и он работает в недвижимости безотказно. Красивая картинка, которая дергается при повороте головы, продаёт хуже, чем чуть более простая, но летящая на стабильных 60 FPS.

Почему архитектурные сцены тормозят

Первое, что мы делаем при аудите сцены заказчика — выясняем, куда уходит время кадра. Обычно проблема не в слабом «железе», а в одном или нескольких узких местах:

• Слишком много полигонов в зоне видимости — архитектурные модели часто приходят с избыточной детализацией: резьба на мебели, сложные скругления, которые не видны. В VR стереорендеринг умножает нагрузку, и это становится критичным.
• Перегруженные материалы и текстуры — сотни уникальных материалов порождают сотни переключений шейдеров, даже если геометрия простая. Типичный пример: каждая дверная ручка имеет свой материал, хотя все они выглядят одинаково.
• Десятки и сотни draw calls — прямой результат дробления объектов и переизбытка материалов. Процессор захлебывается, командуя GPU рисовать тысячи мелких деталей по отдельности.
• Лишние объекты, которые рендерятся, хотя их никто не видит — мебель в соседней комнате, полностью скрытая стеной, продолжает отрисовываться, потому что не настроен occlusion culling.
• Просчёт света в реальном времени там, где достаточно запекания — динамические тени от неподвижных ламп пожирают ресурсы, хотя световая картина не меняется на протяжении всего тура.
• Отсутствие логики уровней детализации и приоритета по дистанции — дальний диван рендерится с той же детализацией, что и ближний, а кусты за окном имеют 10 тысяч полигонов, хотя видны как силуэт.

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

Что значит оптимизация по стандартам геймдева

В игровой разработке оптимизация — это непрерывный процесс балансировки между визуальной насыщенностью и производительностью. Мы научились задавать три ключевых вопроса к каждой сцене еще на этапе проектирования уровней для VR-игр. Эти же вопросы отлично работают в архитектурных турах:

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

Для архитектуры эта логика особенно полезна. Если в кадре интерьер квартиры, не нужно одинаково тщательно считать плитку в соседнем санузле, панорамный вид за окном и декоративные элементы на потолке. У каждого слоя сцены должен быть свой уровень важности. Мы ранжируем объекты по сценарию просмотра: сначала — то, на чем фокусируется взгляд покупателя (кухонный гарнитур, панорамное окно), затем — второстепенное окружение, и наконец — то, что видно мельком.

Главный принцип

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

С чего начинать: аудит сцены

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

Что проверить в первую очередь

• Количество объектов в сцене — большое число мелких объектов бьет по draw calls сильнее, чем высокая полигональность одного объекта.
• Количество материалов — каждый уникальный материал требует отдельного вызова шейдера.
• Количество уникальных текстур и их разрешение — часто текстуры 4K лежат на предметах, которые никогда не рассматривают вблизи.
• Число источников света и их тип (динамический/статический) — динамические тени от недвижимых ламп — главный скрытый враг FPS.
• Наличие дублирующих элементов — скопированные группы мебели, неоптимизированные блоки.
• Долю статичных и динамических объектов — от этого зависит, как настраивать occlusion и свет.
• Самые тяжелые зоны по кадру — мы проходим камерой и смотрим в профайлере, где падает FPS.
• Сценарий показа: VR, ПК, веб, планшет — целевая платформа диктует бюджет полигонов и draw calls.

Практический чек-лист аудита

Вот наш внутренний чек-лист, который мы применяем в каждом проекте:

• Включаем отображение статистики (Stats в Unity, GPU Visualizer в Unreal) и сразу смотрим число треугольников и draw calls — это первые цифры для оценки.
• Находим объекты с большим количеством треугольников, которые слабо влияют на силуэт — например, ваза с 20K полигонов в углу.
• Проверяем, сколько материалов назначено на один объект; идеально — один, максимум два-три.
• Убеждаемся, что черновые модели, скрытые слои и старые версии удалены — чистим иерархию.
• Определяем, какие элементы должны быть статичными для корректной работы occlusion и запекания света.
• Отдельно оцениваем окна, зеркала, витрины и крупные отражающие поверхности — они часто тянут за собой дополнительные проходы рендера.
• Проверяем, не тратится ли ресурс на невидимые зоны — временно отключаем occlusion и смотрим, что рисуется за стенами.

Оптимизация геометрии: не «обрезать красоту», а убирать лишнее

Архитектурные модели из CAD-систем почти всегда перегружены геометрией, потому что там нет ограничений реального времени. Наша задача — адаптировать их под движок, не испортив визуал. Мы не режем полигоны ради цифр, а убираем то, что пользователь все равно не увидит: внутренние полости, задние стенки шкафов, скрытые грани. Опыт геймдизайна подсказывает, что часто 30–40% геометрии можно убрать без каких-либо видимых изменений — достаточно пройтись по сцене с вопросом «а видит ли это камера?».

Рабочие приёмы

• Убирать невидимые полигоны внутри стен, мебели и сложных сборок. В одном проекте мы сократили полигонаж на 40%, просто удалив задние грани у мебели, стоящей вдоль стен.
• Объединять мелкие детали в логические группы — розетки, выключатели, ручки собираем в один объект с общим материалом, что резко снижает draw calls.
• Использовать более простую геометрию для объектов второго плана. Например, в шоуруме стулья на заднем плане делаем восьмигранными, а не скругленными — разница незаметна, а экономия большая.
• Заменять высокополигональные детали на нормали и карты рельефа — плинтусы, лепнина, резьба прекрасно имитируются текстурами, сохраняя визуальную насыщенность без нагрузки.
• Делать отдельные версии модели для дальних и ближних планов — по сути это ручной LOD, который потом легко автоматизировать.

Когда упрощение особенно важно

• В сценах с большим количеством комнат — если не упростить, общая сложность растет экспоненциально.
• В жилых комплексах с повторяющимися типовыми блоками — мы создаем один оптимизированный модуль и инстансируем его; копирование тяжелой модели десятки раз быстро добивает FPS.
• В шоурумах и коммерческих интерьерах с большим числом декора — мелкие украшения в большом количестве создают лавину draw calls.
• В VR, где полная сцена должна стабильно держать высокий FPS — цена каждого лишнего треугольника в VR втрое выше из-за стереорендеринга.

LOD: основной инструмент для больших сцен

LOD (Level of Detail) — это хлеб геймдева. Мы используем его во всех крупных проектах, потому что расстояние обзора в архитектурных турах часто большое, а пользователь может быстро перемещаться от общего плана к деталям. Без LOD сцена либо перегружена на общих планах, либо теряет качество вблизи.

Как это работает на практике

LOD — это несколько версий одного объекта для разных расстояний от камеры. Вблизи — полная детализация, на среднем расстоянии — упрощенная модель с уменьшенным числом полигонов, далеко — еще более легкий вариант или импостер (плоскость с запеченной текстурой). Для архитектурных объектов импостеры хорошо подходят для городского окружения за окном: мы рендерим соседние здания как простые боксы с натянутой текстурой фасада, что на порядок легче.

Где LOD даёт максимальный эффект

• Деревья, кусты, уличная среда — растительность без LOD может съесть половину бюджета. В проекте коттеджного поселка мы сделали три уровня LOD для каждого дерева и получили прирост 30% FPS.
• Мебель в больших шоурумах — ряды стульев, столов, кресел; дальние ряды переключаются на low-poly версии.
• Декоративные элементы фасадов — лепнина, карнизы, пилястры; издалека их заменяют плоскости с normal map.
• Городское окружение за окном — небоскребы и дома на фоне.
• Повторяющиеся объекты в ландшафте — скамейки, фонари, урны.

Важный нюанс

LOD нельзя делать просто уменьшением полигонов. Все версии должны:

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

Частая ошибка

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

Occlusion culling: не рендерить то, что скрыто

Occlusion culling — это, пожалуй, самый эффективный способ вернуть FPS в архитектурных сценах. Идея проста: если объект полностью скрыт за стеной, не тратить время на его рендеринг. В играх это стандарт, но в архитектурных моделях, импортированных из CAD, occlusion часто не работает, потому что сцена не подготовлена. Мы включаем его сразу после разбивки сцены на зоны и получаем драматический прирост.

Что важно для хорошего occlusion culling

• Сцена должна быть разбита на понятные зоны — комнаты, коридоры, этажи. Мы создаем логические объемы, которые естественно перекрывают видимость.
• Большие перекрывающие объекты должны реально работать как заслоны — стена толщиной в 5 см может не блокировать лучи видимости в движке; иногда приходится добавлять невидимые occlusion-боксы.
• Геометрия не должна быть «слишком открытой» — если помещение представляет собой один большой объем без перегородок, occlusion не сработает; для открытых пространств (атриумы) используем distance culling и LOD.
• Стены, перегородки и крупные элементы должны быть корректно размечены как Static (в Unity) или иметь правильные настройки видимости (в Unreal).

Что ломает occlusion culling

• Огромные открытые пространства без естественных преград — там occlusion бессилен.
• Лишняя прозрачность — стеклянные перегородки часто не считаются преградами, движок видит сквозь них и рендерит всё, что за ними. Приходится вручную добавлять occlusion-зоны.
• Плохо собранные проёмы — дверные проемы, не закрытые объектами, оставляют «дыры», через которые видно соседние комнаты.
• Сцены, где всё сделано одной большой сеткой — если весь этаж экспортирован одним мешем, движок не может скрыть его часть за стеной, потому что объект считается видимым целиком, даже если видна лишь малая точка. Мы всегда требуем разбивку на отдельные элементы.
• Неправильная логика статичности — если объект помечен как динамический, occlusion часто его игнорирует.

Таблица: что оптимизировать в первую очередь

Свет и тени: где чаще всего теряется производительность

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

Что лучше запекать

• Статичный общий свет — ambient, фоновое освещение.
• Базовую засветку интерьера — мягкий заполняющий свет.
• Мягкие теневые переходы — тени от мебели на пол, от стен.
• Свет от крупных фиксированных источников — потолочные люстры, бра, которые не меняются.
• Освещение, которое не меняется во время показа — если тур не предполагает переключения день/ночь, весь свет можно запечь.

Запекание выполняем с помощью GPU Lightmass в Unreal или Progressive Lightmapper в Unity. Результат — сложные отражения и мягкие тени, которые в реальном времени убили бы производительность, теперь стоят почти ноль.

Что оставить динамическим

• Включаемые лампы — если пользователь может щелкнуть выключатель.
• Анимированные источники света — например, камин с мерцающим огнем.
• Световые сценарии с переключением времени суток — когда тур показывает объект утром, днем и вечером.
• Интерактивные элементы, которые меняются по действиям пользователя — подсветка при наведении.

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

Практический совет

Если объект не двигается, а свет на нём не меняется в реальном времени, почти всегда выгоднее запечь результат заранее. Это правило мы вывели еще при разработке VR-игр: статичное окружение всегда запекается, освобождая бюджет кадра для динамики и интерактива. В недвижимости роль динамики выполняет пользователь, перемещающийся по сцене, а стены и мебель должны быть максимально легкими.

Материалы и текстуры: незаметный источник перегруза

Легкая геометрически сцена может тормозить из-за сотен материалов и текстур в неадекватном разрешении. Мы называем это «смерть от тысяч порезов». В Unity и Unreal каждый уникальный материал вызывает переключение шейдера, и если таких переключений сотни на кадр, процессор не справляется.

На что смотреть

• Одинаковые материалы на похожих объектах объединять — если десять стульев имеют «дерево», материал должен быть один, а не десять копий. В сценах из 3ds Max каждый импорт тянет свой материал, приходится вручную сводить.
• Мелкие текстуры не должны храниться в чрезмерном разрешении — для ручки двери 2048×2048 — безумие, достаточно 512.
• Повторяющиеся поверхности лучше делать через тайлинг — стены, полы, потолки используют одну тайловую текстуру, а не огромный уникальный атлас.
• Сложные шейдеры использовать только там, где они действительно видны — параллакс, тесселяция, subsurface scattering — только на ключевых поверхностях, которые рассматривают вблизи.

Типовые ошибки

• Отдельный материал для каждой дверной ручки, хотя все ручки одинаковы.
• Сверхвысокие текстуры для элементов, которые видны только издалека — например, текстура 4K на статуэтке в углу.
• Использование дорогих эффектов на всей сцене без разбора — отражения в реальном времени на каждой поверхности.
• Слишком много вариантов одного и того же материала — «золото матовое», «золото глянцевое», «золото старое» — всё это можно сделать одним материалом с параметрами.

В одном проекте мы насчитали 30 материалов для металла. После сведения в один универсальный с настройкой цвета и шероховатости количество материалов сократилось, а FPS вырос на 15% — просто потому, что процессор перестал захлебываться.

VR и интерактивные туры: особые требования

VR-просмотр — это высший пилотаж в презентации недвижимости, но и самый строгий экзамен для оптимизации. Если на мониторе просадка до 45 FPS еще терпима, то в шлеме это вызывает дискомфорт и тошноту. Стандарт — стабильные 90 FPS (в идеале 120) без единого скачка. Достичь этого можно только применяя весь арсенал геймдев-оптимизации, причем с большим запасом.

Что особенно важно в VR

• Стабильный FPS без скачков — даже кратковременное падение разрушает ощущение присутствия.
• Минимальная задержка — мы используем single-pass stereo rendering (в Unity) или instanced stereo (в Unreal), чтобы рендерить для двух глаз за один проход.
• Аккуратная работа с камерой — никаких резких ускорений, плавные повороты.
• Отсутствие резких всплывающих деталей — LOD-переключения должны быть абсолютно незаметны; иногда мы делаем кросс-фейд между уровнями или отодвигаем пороги переключения.
• Мягкие переходы между зонами — телепортация или плавное перемещение без рывков.
• Отсутствие лишней визуальной шумихи — мелкий декор в VR может мерцать из-за высокой плотности пикселей; мы балансируем между детализацией и читаемостью.

Практический подход

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

Пошаговый план оптимизации большой архитектурной сцены

Шаг 1. Разделить сцену на зоны

Первым делом мы мысленно проходим будущий тур и определяем логические сегменты: комнаты, этажи, уличные пространства. Это нужно не только для occlusion, но и для организации работы — каждая зона может иметь свой набор настроек. В Unity мы используем пустые GameObject-ы как контейнеры для зон, в Unreal — уровни стриминга. Правильная разбивка — фундамент всей дальнейшей оптимизации.

Шаг 2. Убрать мусор и дубли

Удаляем всё, что не попадет в финальный билд: тестовые примитивы, скрытые слои из CAD, старые версии мебели, дублирующиеся объекты. Удивительно, сколько «мертвых душ» можно найти в сцене, полученной от архитектора. Мы используем инструменты поиска неиспользуемых ассетов и обязательно чистим иерархию.

Шаг 3. Упростить геометрию

Проходимся по всем объектам с вопросами: видит ли пользователь эту грань? Можно ли заменить эту деталь на normal map? Нет ли скрытой геометрии внутри? В результате часто сокращаем общее число треугольников на 30–50% без видимых потерь.

Шаг 4. Настроить LOD

Создаем и настраиваем уровни детализации для ключевых объектов. Для архитектуры характерно много повторяющихся элементов (стулья, двери, окна), поэтому LOD делается один раз и применяется ко всем экземплярам. Расстояния переключения подбираем под типичные сценарии просмотра: в VR пороги ближе, на ПК — дальше.

Шаг 5. Включить occlusion culling

Проверяем, корректно ли разбита сцена для occlusion. Часто приходится добавлять невидимые коллайдеры-заслоны или корректировать границы комнат. После включения occlusion сразу тестируем: смотрим из одной комнаты, рендерится ли другая. В идеале — нет.

Шаг 6. Пересобрать свет

Анализируем каждый источник света: может ли он быть статическим? Если да, помечаем его как Static и перестраиваем lightmaps. Для динамических источников проверяем радиус и интенсивность, чтобы не освещать лишнее пространство. Часто выигрыш от запекания света больше, чем от всей остальной оптимизации.

Шаг 7. Свести материалы

Ищем идентичные или похожие материалы, объединяем их. Проверяем разрешение текстур: для объектов второго плана уменьшаем до 1024 или 512. Сложные шейдеры с параллаксом или тесселяцией оставляем только на ключевых поверхностях.

Шаг 8. Протестировать сцену на целевом устройстве

Финальный тест обязателен на том оборудовании, на котором будут показывать: если тур веб-версия на планшете — тестируем на iPad среднего поколения; если VR — на целевом шлеме. Оптимизация считается завершенной только когда сцена держит стабильный FPS в сценарии реального просмотра, а не просто в редакторе.

Чек-лист перед сдачей проекта

• Сцена разбита на зоны, occlusion работает корректно.
• Удалены черновые и скрытые элементы, иерархия чистая.
• Настроены LOD для всех ключевых объектов, переходы плавные.
• Настроен occlusion culling, проверен на целевом устройстве.
• Статичный свет запечен, динамических источников минимум, их параметры оптимизированы.
• Количество материалов сокращено до разумного минимума, текстуры атласированы где возможно.
• Текстуры не завышены по разрешению, используется стриминг при необходимости.
• Прозрачные поверхности использованы дозированно, их количество не превышает критический порог.
• Проверен FPS на целевом устройстве в сценарии реального просмотра (не в редакторе).
• Тест пройден с типичными действиями пользователя: перемещение, открытие дверей, смена ракурсов.

Типовые ошибки при оптимизации

• Оптимизировать только полигоны и забывать про свет — мы не раз видели сцены с идеальной геометрией, но динамические тени всё убивали.
• Делать сцены одной сплошной меш-сеткой без логики — это наследие CAD; мы всегда требуем разбивку перед началом работ.
• Использовать LOD без проверки переходов — скачок силуэта или цвета при переключении сводит на нет всё впечатление.
• Считать, что «красивый рендер в редакторе» означает хорошую производительность — редактор часто показывает не то, что будет в билде; тестируем только собранную версию.
• Переносить игровую сцену в архитектуру без адаптации под реальные сценарии просмотра — что работает для шутера, может не работать для тура по квартире.
• Игнорировать требования VR — если сцена делается и для веба, и для VR, VR-версия требует отдельного цикла оптимизации.
• Оставлять в финале тестовые материалы и временные источники света — мусор, который бьет по производительности и выглядит непрофессионально.

Вывод

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

Мы, как студия, перенесшая опыт из VR-игр в PropTech, видим, что именно оптимизация часто становится тем фактором, который превращает «просто 3D-модель» в эффективный инструмент продаж. Клиент, который спокойно и с удовольствием прошел тур, гораздо ближе к покупке, чем тот, кто раздраженно закрыл «тормозную» презентацию.

FAQ

Что важнее в архитектурной сцене: качество или производительность?

Это две стороны одной медали. Визуальная достоверность продает объект, но если презентация дергается, клиент закроет тур раньше, чем рассмотрит детали. Мы всегда стремимся к балансу: качество должно быть достаточным, чтобы передать пространство и материалы, а производительность — такой, чтобы не отвлекать от просмотра. В нашей практике мы не раз убеждались: стабильные 60 FPS с чуть упрощенным декором продают лучше, чем 25 FPS с фотореалистичной резьбой.

Можно ли обойтись без LOD?

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

Что даёт больше всего прироста FPS?

По нашему опыту, наибольший эффект дают три вещи: сокращение лишней геометрии (особенно скрытых граней), грамотная настройка occlusion culling и запекание статичного света. Часто эти три шага удваивают FPS. Затем уже материалы и LOD. Но каждая сцена индивидуальна, поэтому мы всегда начинаем с аудита.

Нужна ли отдельная оптимизация для VR?

Абсолютно. VR требует как минимум вдвое большей производительности, чем обычный просмотр на ПК: рендеринг для двух глаз с частотой 90 Гц. Все бутылки с узким горлом в VR становятся критичными. Мы всегда закладываем запас по FPS в 20–30% сверх целевого, чтобы компенсировать возможные нагрузки.

Когда лучше начинать оптимизацию?

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