Всем привет! Сегодня команда Black VR подготовила статью-кейс о создании виртуальной прогулки по территории нового кампуса для Московского физико-технического института.

Прежде, чем мы перейдем к самому кейсу, вкратце упомянем о самом клиенте. МФТИ, известный так же, как и Физтех – является ведущим российским вузом в сфере теоретической, прикладной и экспериментальной физики, математики, информатики и химии, биологии и других смежных дисциплин. Ежегодно вуз выпускает высококвалифицированных специалистов по заявленным направлениям, которые востребованы как на российском, так и на зарубежных рынках.

Команда МФТИ обратилась к нам для создания VR-визуализации проекта нового корпуса студенческого кампуса с прилегающей территорией.

Минусы готовой модели от заказчика

Изначальная задумка состояла в том, чтобы макет, предложенный заказчиком, можно было посмотреть в VR – провести оцифровку и воплотить в 3D для более качественной демонстрации. 

Когда клиент говорит, что у него уже есть готовая модель, нужно только вставить и загрузить в VR, это сразу вызывает тревогу. 90% таких клиентов имеют у себя готовые под визуализацию модели, либо модели из AutoCad, SketchUp и других подобных программ, которые предназначены для проектирования, прототипирования, но не для реалтайм работы приложения.

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

И вот, получая такую модель от заказчика, мы имеем в итоге очень сильно перегруженную в плане полигонов модель, которая в VR-симуляции будет отображаться с сильными тормозами. О чем говорить, если данные модели даже в 3D-редакторах открываются и редактируются с трудом.

Мы же имели в исходниках уже готовые здания, к примеру такое.
Само собой без каких-либо нарезок на куски.
Мы же имели в исходниках уже готовые здания, к примеру такое. Само собой без каких-либо нарезок на куски.

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

Очень плотная сетка, плюс внутренние части и толстые окна.
Очень плотная сетка, плюс внутренние части и толстые окна.

Нейминг объектов

Ещё один пункт, который не сильно может быть важен в визуализации, но может облегчить работу по оптимизации – это правильный нейминг объектов.

Если архитекторы более-менее добавляют имена, то визуализаторы часто забывают об этом, и в итоге мы имеем набор непонятных объектов в иерархии, и таких же неопределённых материалов для них. В итоге, разработчики теряют время, играя в “угадайку” с материалами, присланными клиентом, или сбрасывают все до базовых настроек, чтобы заново, вручную назначить наименования материалов. 

Отдельно стоит сказать про то, что нейминг на кириллице часто превращается в набор символов и знаков.

Отличие готовых моделей от реалтайм моделей

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

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

Что получили от клиента

Что получили разработчики от МФТИ в качестве “готовой” модели:

  • Тяжелую модель с кучей лишней геометрии;

  • С непонятным неймингом;

  • Потерянными текстурами; 

  • Без UV-развертки;

  • Большие цельные не то, что здания, а отдельные куски карты;

  • Несколько разных рендеров и несколько разных вариаций моделей одной и той же территории;

  • Все здания, хотя бы минимально, но отличались от своих реальных референсов.

В начале все отдельные варианты сооружений были собраны в одну сцену в 3D-редакторе, путем согласований и уточнений с клиентом вывели окончательный вид и расположение всех зданий и дорог, тротуаров. 

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

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

  • Уменьшить полигонаж объектов хотя бы в половину от того, что было в исходных файлах;

  • Нарезать здания отдельными блоками, чтобы хоть как-то оптимизировать большие объекты; 

  • Провести нейминг объектов и материалов, для более удобного назначения в Unity;

  • Сделать UV-развертку;

  • Подобрать необходимые текстуры.

Для оптимизации использовался Blender, но тут по сути не так важно, потому как это можно делать в любом редакторе.

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

Разработка под реалтайм означает, что, чем меньше, тем лучше. Это касается всего: полигонов, разрешения текстур, количества материалов, количества объектов. 

Так как каждый лишний объект или текстура - это лишний Draw Call (запрос к процессору на обработку данных), ресурсы которого само собой ограничены.

Чтобы разобраться, какие технологии применить наилучшим образом, и оптимизировать картинку без потери качества, поначалу наши разработчики пошли по стандартному пути – разделили все модели и оптимизировали их по полигонажу, чтобы модели грузились только в те моменты, когда они попадают в камеру. Но этого было недостаточно. В итоге пришли к DLLS – это ПО помогает оптимизировать модели, что позволило очень хорошо облегчить объекты и, самое главное, сделать это незаметно для зрителя. Таким образом нам удалось добиться стабильного FPS.

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

  1. Анализ каждого здания; 

  2. Составление списка блоков, из которых они должны быть сделаны;

  3. Составление списка блоков, которые могут быть использованы на различных зданиях;

  4. Моделинг, текстуринг;

  5. Собрать из блоков здания в движке / не в движке, но блоками, что немного хуже.

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

Комментарии (3)


  1. nerudo
    06.05.2022 12:41
    +1

    Куполов с крестами не хватает.


    1. Biga
      06.05.2022 12:51
      +1

      Это вы с МИФИ путаете.


  1. SolarPunch
    06.05.2022 14:20

    @BlackVR, у вас есть возможность скинуть модель кампуса? Я студент физтеха, активист местного профкома – было бы очень интересно узнать, что собирается построить наша администрация.