В данной статье мы рассмотрим все возможные способы передачи представления поверхности земли (проектной поверхности) в топо-поверхность Revit из Civil 3D. Существующая парадигма комплексного проектирования в мультивендорной среде порождает проблемы точной передачи геометрии из одного ПО в другое - и один из таких частых кейсов -- это именно передача проектной поверхности генплана в модель Revit.
В качестве исходных данных будем использовать проектную поверхность линейного объекта следующего вида:
1. Немного о проектных поверхностях
Сперва давайте сделаем небольшое отступление, где приведем основные черты проектных поверхностей:
- наличие "линейной триангуляции" (структурные линии в составе поверхности, задающие триангуляцию);
- наличие явной внешней/внутренней границы;
- наличие вертикальных/почти вертикальных откосов (бордюрный камень/подпорные стенки);
Проблема точной передачи поверхности в Revit связана с восприятием любой сторонней геометрии как чуждой и применение к ним своих алгоритмов преобразования геометрии, отчего проектные решения искажаются и конечный специалист получает неверные проектные решения.
Перед тем как перейти к вариантам импорта проектной поверхности обязательно настроим общие координаты модели Revit из DWG-файла (чтобы спокойно обрабатывать "большие" числа).
Методика, как это сделать, изложена в другой своей статье в блоге Вадима Муратова.
2. О базовых способах генерации топо-поверхности Revit
2.1 По точкам
К числу базовых способов передачи поверхности можно отнести построение поверхности по точкам - совершенно бесполезный способ в отношении проектной поверхности, но, чтобы начать (и оправдать тему статьи - все способы) - мы начнем с него.
Естественно - нас такое категорически не устраивает, поэтому сразу перейдем к следующему варианту
2.2 По импортированным данным
Здесь мы вместо точек готовим вспомогательный DWG-файл, где у поверхности получаем горизонтали или 3D-грани, и на их базе строим поверхность в Revit. Вариант с 3D-гранями оправдан при желании получить сравнительно-точную топо-поверхность (но её насыщенность гранями будет столь велика, что Revit будет тормозить (при, опять же, сложных проектных решениях; в базовом варианте это легче горизонталей)). Горизонтали - настраиваемый вариант (от концепта (большой шаг) до довольно-точных вариантов (с мелким шагом). Мы рассмотрим оба варианта
Ну и прогрузка таких данных заставили Revit зависнуть секунд на 30.
3. Публикация поверхности через BIM 360
При наличии BIM 360 (не столько финансовой, сколько политической - использовать внутри компании) дело упрощается до двух кликов - выгрузить из Civil 3D и вставить в Revit. У нас в компании BIM 360 под запретом - поэтому я на этом не останавливаюсь, а иду дальше. Демонстрирую с личной версии.
4. При использовании Revit API (через Dynamo)
Подходим к экзотике - вручную создаем топоповерхность Revit используя представление поверхности как набора точек и 3D-граней через следующий метод, доступный в Revit API:
Create Method (Document, IList(XYZ), IList(PolymeshFacet))
Здесь у нас 3 аргумента - текущий документ, набор трехмерных координат точек и набор самих 3D-граней (элементами PolymeshFacet). Оптимальный путь - вытаскивать эту информацию из Civil 3D и перетягивать в Revit. Но я ненавижу работать с API и мы рассмотрим вариант работы через представление поверхности как landxml-файла, а для самой генерации поверхности я так и быть себя пересbлю и сделаю через Revit API.
Не погружаясь в тонкости разработки, выкатываю ссылку на репозиторий с библиотекой (собиралась под Revit 2021 на .NET Framework 4.8), которая реализует это действие - читает LandXML-файл, преобразовывает его в 2 списка с точками и гранями и подает на вход методу генерации поверхности.
P.S. Я там правда напутал с уровнем привязки у DWG-положки - так давно не работал в Revit, что всё забыл :-).
Для проверки корректности я использовал DWG-подложку с 3D-гранями.
В целом - хорошо, но сильно не хватает некоторых внешних границ и особенно, внутренних границ (я в API не лез и не хочу, потом как-нибудь - ибо это не цель статьи).
5. Как можно ещё?
Слышал вариант через IFC, но тут у меня не получилось даже открыть представление поверхности Revit, выгруженную в IFC в BIM Vision (вообще пустота, и по структуре файла никаким topography не пахло).
В общем случае, через IFC представление поверхности залетает в Renga (где нет никаких API по созданию объектов геометрии). Об этом я писал в этой статье и дополнительно про поверхности и IFC вот здесь.
Здесь же не премину упомянуть другую структуру в Revit, которая пользуется популярностью при работе с генпланом - это перекрытия. И вот они (вроде бы, для этого надо лезть в Revit API смотреть)позволяют задавать себе внутренние границы.
Наглядный пример применения перекрытий в генплане сделали коллеги из TBS (см. их небольшой ролик). Там тоже к слову используется landxml и читается (наверное) также, только применяется к иному элементу.
6. Подводим итоги?
Итак, в данной статье я рассмотрел доступные методы передачи в Revit проектной поверхности (из Civil 3D). Следует отметить, что вариант создания поверхности по импортированным данным - 3D-граням является самым "оптимальным" по трудозатратам и конечной производительности.
Самый "точный" вариант - когда в Revit поверхность воспроизводиться в точности, как в Civil 3D - это связь топографии через BIM 360 (явно используются внутренние "закрытые" методы API по добавлению в состав топоповерхности границ. Этот способ имеет один огромный недостаток - он возможен только через BIM 360, использование которого в большинстве гос. компаниях невозможно в силу расположения серверов хранения данных за рубежом. К слову, я работаю в такой компании :D
Второй по приемлемости способ и первый после BIM 360 - это генерация поверхности через метод API, позволяющий инициализировать элемент поверхности по набору точек и 3D-граней, но без возможности задать границы поверхности. Зато 3D-грани передаются в точности и нет искажений поверхности. Для его реализации мне пришлось в кои-то веки забросить свои ГИСы и сесть погрустить над кодом (грусть оттого, что такой час отдыха выпадает нечасто) - результат я опубликовал в своем git-репозитории.
К слову, с помощью этого метода можно передавать в landxml представление поверхности не только из Civil 3D, но и из других инфраструктурных программ типа Robur, Credo и пр. (не пробовал, но теоретически, должно работать).
Совсем грубый способ - построение поверхности по точкам и иные варианты (скрипты) которые строят по точкам COGO поверхность. Это полнейшая ересь и её нельзя применять в работе!
#autodesk #revit #civil 3d #dynamo #surface #landxml #dynamo development #TopographySurface
