Сам текст требований расположен по ссылке. Требований стало гораздо больше по сравнению с версией 2019 года (см. мою заметку "Низкая детализация BIM-проектов для АГР или моделирование заново?").
Не могу оценить в полной мере все детали, так как не готовил
архитектурно-градостроительных решений (АГР) уже давно. Но количество
требований ошеломляет - и они ориентированы на профессиональных
визуализаторов.
Моделировать с нуля в 3dsmax, с моей точки зрения, - маргинальный вариант, поэтому я старался бы все получить из BIM-программы с последующей доработкой в 3dsmax/Blender
Для чего все это?
Игровые движки стали стандартом для интерактивной визуализации больших городских пространств. Это удобно и наглядно. Как я понял по косвенным признакам, модели готовятся под Unreal Engine 5.1, а ведь раньше был Mapvis на Unigine. Кто хорошо управляется с подобными зверями, легко справится и с этими требованиями. Все заморочки с IFC уходят в экспертизу, а архитектурный образ передаётся посредством формата *.fbx. В плане материалов модели он точно надежнее.
Да, за достижениями Москвы в области 3D-моделей города продолжаю внимательно следить.
Что требуют?
- Низкополигональная модель - не более 50 000 полигонов, текстуры "запечены" в атлас. Кстати, я так и не научился нормально "запекать" текстуры.
- Меш (или сеточная модель) коллизии низкополигональной модели - 0.05 * макс.число полигонов основной модели. Эта модель необходима для того, чтобы в игровом движке камера не пролетала сквозь здание.
-
Высокополигональная модель - не более 2 000 000 полигонов, текстуры в
формате UDIM. С таким методом я пока вообще не работал.
- Меш коллизии высокополигональной модели - 0.05 * макс.число полигонов основной модели.
- Файл в формате *.geojson (о нём чуть позже)
Аналогия с InfraWorks и Revit
Мой опыт
подготовки моделей из Revit и Archicad для InfraWorks и ArcGIS пока не
позволяет мне сходу разобрать по полочкам все эти новые требования. Но пару
советов я бы дал (если будет интерес, то и раскрыл бы в видео).
Я не пользуюсь штатной связкой Revit-3dsmax (Import > Link Revit), хотя в
ней есть супер-функция по установке сегментации криволинейных поверхностей.
Довольствуюсь обычным экспортом в *.fbx.
- Internal Origin - включайте её и ориентируйте модель относительно этой точки. По логике требований МКА удобнее всего сделать модель окружения либо с реальными координатами МСК Москвы (но Revit может не сдюжить 11 км от нуля, не проверял), либо со сдвинутыми координатами (поставить в реальное место уже в 3dsmax или Blender). В файл модели окружения подгружаем наше проектное здание, привязываем и выравниваем, затем из этого файла делаем экспорт в *.fbx.
- Функции элементов Exterior и Interior (это могут быть просто свойства в любой программе). Например, ArcGIS при импорте Revit-модели автоматом пытается создать оболочку модели именно по значению Exterior. А мы могли бы таким образом во время экспорта быстро скрывать ненужные внутренние элементы
- Level of Detail (LOD). В Revit у вида есть три уровня детализации. Эти же уровни детализации можно задать и семействам: для высокополигональных моделей ручки дверей можно оставить, а вот для низкополигональных совершенно точно должны быть скрыты на уровне Coarse. Много семейств явно страдают от излишней детализации, и дать пользователю несколько вариантов явно не помешало бы.
- Профили. Перила с круглым профилем или фаски на дверях могут просто похоронить модель, сделав ее неприлично тяжелой. В случае связки Revit-3dsmax проблема решается проще, но я бы советовал этот вопрос держать на контроле.
- Повторяющиеся объекты (это могут быть и архитектурные детали здания). Сюда можно отнести мебель, оборудование и озеленение, но в контексте рассматриваемых требований они не требуются. Мой основной принцип здесь - создать в Revit упрощенные заместители, например, деревьев, экспортировать их в табличный файл с координатами и свойствами по каждому дереву и потом воспроизвести их при помощи скрипта с нужной геометрией или в 3dsmax, или в InfraWorks. Многие архитекторы привыкли делать картинки в программах типа Lumion, откуда не выскрести расположение деревьев.
А что у Archicad и Renga?
В случае Archicad встроенные возможности экспорта в 3D-форматы намного
скромнее, чем у Revit. Большого исследования я не проводил, оптимальным для
меня был формат *.obj (в названиях материалов надо избегать кириллицы).
Формат *.dae не сохраняет никаких наименований объектов или материалов.
Невероятным по удобству плагином оказался экспорт в *.fbx, который
появляется после установки Twinmotion. Конечно, в идеальной ситуации надо
иметь Cinema4D, для прямой связки с Archicad.
Renga на этом фоне выглядит еще скромнее, если отложить в сторону достойный
экспорт в твердотельные форматы и IFC. Очевидно, что ресурсов у
разработчиков на все не хватает, а IFC и так занимает много сил. Форматы
*.obj и *.dae дают похожую картину, везде элементы объединены по материалам.
Имена объектов и материалов распознать трудно.
Неприятной проблемой оказывается экспорт всех объектов модели в
независимости от того, что мы видим на экране (привет, скрытые балки, кровли
и пр.). Плагины Егора Гребенюка призваны решить этот вопрос (сохранение видовых точек с видимостью объектов
и
экспорт в *.nwc и *.fbx с учетом заданной видимости), но пока не стабильны.
Я даже немного поучаствовал в обратной связи по экспорту в 3D, так как видел в
этом перспективу.
Файл .*geojson
У многих вызывает вопросы и файл *.geojson
(хотя пользователи Renga привыкли работать с json-подобными данными). Это файл
геоданных (в нашем случае там содержится одна точка) с определенными
свойствами проекта здания, описанных в
json. Сама структура файла в
примере неканоническая (сервис geojson.io его не отобразит), но, видимо, это необходимо конечному пользователю.
Как
его создать? Можно руками - обычном Notepad, Notepad++ или даже в Visual
Studio Code. Если в Notepad, то создаём содержание, а потом перебиваем
расширение .*txt на *.json.
А можно сделать это более наглядным способом - идём на сайт вроде
https://jsoneditoronline.org/ и
там пишем все вручную. Важно отслеживать, что все скобочки закрыты, а запятые
в конце строк проставлены. Последняя строка перед закрытой фигурной скобкой
идёт без запятой.
Для вашего удобства я набрал текст в онлайн-сервисе и даю на него
ссылку на сервисе и на onedrive. Если воспользуетесь сервисом, останется заполнить ваши данные, скачать файл и проверить расширение. Или скачать файл с onedrive и загрузить уже локальный файл на https://jsoneditoronline.org/ В крайнем случае редактируем всё в обычном Notepad или Notepad++.
Есть еще одна деталь в этом файле - картинка-превью проекта, закодированная в
текст. Такую кодировку можно выполнить при помощи бесплатных сервисов. Я
использовал https://base64.guru/converter/encode/image . Полученный код надо вставить вместо "xxxx" между кавычками на
выделенном фрагменте рисунка ниже.
Количество символов будет очень большим, следите, чтобы файл не потерял
кавычки или запятую в конце.
Кстати, с таким способом передать картинку я столкнулся в InfraWorks, там это
реализовано для закладок (Bookmarks).
3D-форматы для компьютерной графики получают второе дыхание
BIM-специалисты привыкли посмеиваться над визуализаторами, дескать, они только
картинки лепят. Однако игровые движки и серьезные задачи заставили нас
по-новому взглянуть на компьютерную графику и её форматы. На сцену выходят
адаптированные под веб *.gltf/glb, форматы обмена *.usd, развивается отдельное
направление тайловых данных. Все это теснит не только BIM-форматы, но и структуры типа CityGML, который оказался довольно муторным в плане обмена данными.
В общем, скучать нам не дадут!
Комментариев нет:
Отправить комментарий