Параметрическая геометрия: как в IFC4 уже сейчас работает то, что официально обещают только в IFC5

buildingSMART готовит новую версию открытого BIM-стандарта IFC5. Здесь, в отличие от монолитной ООП-иерархии (IFC2x3, IFC4), применяется компонентный ECS-подход (Entity Component System). То есть в IFC5 объект собирается из независимых частей (геометрия, материалы, свойства), которые можно комбинировать и пересобирать отдельно друг от друга. Разработка ведётся публично в репозитории buildingSMART/IFC5-development на GitHub, финальная спецификация пока не выпущена.

Однако ниже будет не про IFC5, а о том, что параметрическая, неразрушающая правка геометрии уже сегодня реализована поверх текущего IFC4 в открытом BIM-редакторе Blender с аддоном Bonsai (ранее — BlenderBIM). Механизм не входит в спецификацию IFC4. Это идея самого Bonsai поверх штатного, ничем не примечательного элемента схемы (IfcPropertySet).

Виды моделирования

Неразрушающее (non-destructive) редактирование. Вместо финальной геометрии в файле хранятся параметры. По ним геометрия пересобирается заново при каждом изменении. Аналогией будут слои в Photoshop: правится не результат, а настройка, которую можно поменять туда-обратно без потери качества.

Разрушающее моделирование. Редактирование готовой формы напрямую (сдвиг вершин, вырезание полигонов); вернуться к прежнему виду можно только вручную. Здесь аналогией станет растровая графика вроде файла *.jpg. Каждое редактирование в Paint необратимо стирает исходные пиксели; восстановить прежний вид можно только по памяти, вручную нарисовав заново.

Параметрическое моделирование в Revit, ArchiCAD существует десятилетиями. Но в каждой из этих программ параметрический «рецепт приготовления геометрии» хранится в закрытом проприетарном формате (.rvt у Revit). При экспорте в открытый IFC формат рецепт бесследно теряется и остаётся только «застывшая» геометрия. Параметрика не переживает границу экспорта в открытый формат.

Как Bonsai решает проблему «застывшей геометрии»

Bonsai не имеет собственного проприетарного формата хранения. Модель целиком живёт в IFC-файле. Соответственно, спрятать параметрический рецепт лестницы или крыши в «свой» формат невозможно в принципе. У нас есть только IFC-файл.

Для простых объектов (плита постоянной толщины или стена) стандартной схемы IFC4 вполне достаточно: геометрия описывается штатным IfcExtrudedAreaSolid (2D-контур + направление и глубина выдавливания), толщина слоя — через IfcMaterialLayerSet.

Для геометрически сложных объектов (лестницы, скатные крыши, окна, двери, перила) штатных механизмов схемы недостаточно.

Механизм: JSON-рецепт внутри Pset

Для таких объектов Bonsai создаёт кастомный IfcPropertySet с именем, начинающимся на BBIM_ (например, BBIM_Roof). Внутри будет только одно свойство с типом данных IfcText, содержащее сериализованный JSON со всеми параметрами формы.

Пример параметрической скатной крыши. Приведено в виде обчыного JSON для удобства чтения.

{"roof_type": "HIP/GABLE ROOF", "generation_method": "ANGLE", "roof_thickness": 0.1, "rafter_edge_angle": 1.5707963705062866, "angle": 0.1745329201221466, "percentage": 17.63269805908203, "path_data": {"edges": [[0, 1], [1, 2], [2, 3], [3, 0]], "verts": [[-5.0, -5.0, 0.0], [-5.0, 5.0, 0.0], [5.0, 5.0, 0.0], [5.0, -5.0, 0.0]]}}

Или в виде сериализованного JSON

{"roof_type": "HIP/GABLE ROOF", "generation_method": "ANGLE", "roof_thickness": 0.1, "rafter_edge_angle": 1.5707963705062866, "angle": 0.1745329201221466, "percentage": 17.63269805908203, "path_data": {"edges": [[0, 1], [1, 2], [2, 3], [3, 0]], "verts": [[-5.0, -5.0, 0.0], [-5.0, 5.0, 0.0], [5.0, 5.0, 0.0], [5.0, -5.0, 0.0]]}}

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

В этом можно убедиться, если посмотеть на свойства типа в обычном вьювере BIM-Vision

В отличие от вьювера, код Bonsai умеет интерпретировать содержимое.

В интерфейсе Bonsai (вкладка Geometry and Materials → секция Parametric Geometry → Roof → панель «Roof parameters») эти же значения показаны не как сырой текст, а как обычные поля: Roof Type, Roof Generation Method, Roof Thickness, Rafter Edge Angle, Slope Angle, Slope %.

Важно: пересборка геометрии не происходит автоматически

Нужно понимать, что с изменением значения JSON у текствового параметра Data в BBIM_Roof с геометрией ничего не произойдет само по себе.

Более того, попытке отредактировать значения JSON у текствового параметра Data в BBIM_Roof напрямую, то есть через общую панель Property Sets, а не через панель Parametric Geometry, Bonsai выводит предупреждение:

Внимание! Этот настраиваемый набор параметров (pset) не следует редактировать напрямую — его нужно изменять через интерфейс Parametric Geometry UI.

Тем не менее, вместо того чтобы использовать интерфейс Parametric Geometry UI, сделаем закат солнца вручную. А именно откроем файл IFC в обычном блокноте и заменим предыдущие параметры JSON в BBIM_Roof на новые.

Вот так:

{"roof_type": "HIP/GABLE ROOF", "generation_method": "ANGLE","roof_thickness": 0.5, "rafter_edge_angle": 1.5707963705062866, "angle": 0.5235987901687622, "percentage": 57.73502731323242,"path_data": {"edges": [[0, 1], [1, 2], [2, 3], [3, 0]], "verts": [[-5.0, -5.0, 0.0], [-5.0, 5.0, 0.0], [5.0, 5.0, 0.0], [5.0, -5.0, 0.0]]}}

Сохраним изменения текста IFC-файла, сделанные в блокноте. После этого опять откроем, файл в Bonsai.

Что мы видим? И панель Parametric Geometry (Roof parameters), и панель Property Sets (BBIM_Roof → Data) просто читают текст из файла. При этом сама 3D-геометрия крыши во вьюпорте Blender и в BIM-Vision осталась прежней формы. Досадно, но крыша не соответствует новым параметрам.

Даже если пересохранить в Bonsai открытый файл IFC, геометрия не перестроится по новому рецепту.

Как применить новые параметры к крыше?

Способ простой. Нажать на иконку карандаша (Enable Editing) в панели Roof parameters. Затем подтвердить кликнув на галочку «Finish Editing». Вот теперь геометрия крыши перестроилась и стала соответствовать новым значениям.

Можно нажать ctrl+S для сохранения файла IFC и посмотреть результат во внешнем вьювере.

Вывод: JSON в BBIM_Roof и фактическая 3D-геометрия (IfcShapeRepresentation) в файле IFC существуют как два независимых куска данных. Изменение текста в параметре само по себе не запускает пересборку формы ни при открытии файла, ни при прямом редактировании текста. Пересборка происходит только при явном вызове соответствующей операции в панели Parametric Geometry.

Практическое следствие для тех, кто планирует менять параметры программно (через IfcOpenShell, в обход интерфейса Bonsai): недостаточно переписать значение параметров в Pset. Нужно отдельно вызвать операцию генерации геометрии, иначе итоговый файл будет содержать корректные параметры и не соответствующую им форму.

Не любой объект в IFC имеет параметрику из JSON

Если создать IfcSlab, не проходя через операцию генерации скатной геометрии, объект остаётся плоской плитой без BBIM_Roof и без параметров ската.

Скриншот из Bonsai показывает у объекта IfcSlab[ROOF] в наборе свойств EPset_Parametric параметр со значением: Bonsai.DumbLayer3.

Bonsai.DumbLayer3 — это название встроенного системного процедурного/параметрического «движка» (Engine) в Bonsai. Он отвечает за генерацию 3D-геометрии многослойных строительных элементов (стены, плиты перекрытия/кровли) на основе заданного набора слоев. DumbLayer (слоистое моделирование) генерирует геометрию, просто вытягивая (экструдируя) профиль по слоям (например, несущий слой + утеплитель + отделка).

Cпециальной сложно-параметрической геометрии в IfcSlab, как видим, не задано.

IfcRoof как отдельный класс схемы

Класс IfcRoof в IFC4 проектировался как составной элемент, т.е. контейнер-агрегатор высокого уровня.

Дочерние конструктивные элементы описываются своими физическими классами:

• IfcSlab с PredefinedType = ROOF (скаты крыши);

• IfcBeam (стропила, прогоны).

Связь между контейнером и дочерними элементами реализуется через отношение IfcRelAggregates (RelatingObject = IfcRoof, RelatedObjects = набор IfcSlab, IfcBeam и др.).

Использование геометрии в IfcRoof

Декомпозированная кровля (Best Practice)

Если кровля декомпозирована на составные части (IfcSlab, IfcBeam), сам IfcRoof не должен содержать собственного трёхмерного представления (Representation = NULL). Вся объёмная форма и массы определяются суммарной геометрией его дочерних элементов.

Единый объект без декомпозиции (Исключение спецификации)

Формальная спецификация IFC4 допускает и второй вариант — единая крыша без декомпозиции, где все геометрические представления являются сущностью IfcRoof. Наличие собственной геометрии у IfcRoof не запрещено схемой — оно опционально и зависит от того, декомпозирована модель или нет.

Важно: Совмещение двух подходов недопустимо. Если добавить геометрию одновременно и в IfcRoof, и в дочерние IfcSlab при декомпозиции, то это может вызвать дублирование объёма в сметных расчётах и трудности в коллизионном анализе.

Практика применения (BIM-конвенция)

На ранних стадиях проектирования, когда детализация модели ещё низкая (LOD 100–200), удобно использовать IfcRoof как единый объект со своей упрощённой геометрией — без декомпозиции. По мере детализации модели (LOD 300+) геометрию переносят на дочерние элементы (IfcSlab, IfcBeam), оставляя IfcRoof пустым контейнером-агрегатором.

Схема IFC4 не диктует этот переход жестко — это устоявшаяся практическая конвенция BIM-процесса, а не требование самого формата.

Совместимость с другими IFC-программами

BBIM_Roof всего лишь обычный IfcPropertySet, поэтому он виден в любом IFC-вьюере (например, в BIM Vision) в силу открытости формата. Но считывается он как строка текста. Сторонний вьюер не парсит вложенный JSON и не может ни отобразить поля по отдельности, ни пересобрать по ним геометрию.

Интерпретировать содержимое способен только код, который заранее знает про конвенцию BBIM_…, то есть сам Bonsai.

Отдельный нюанс. В примере Pset висел не на экземпляре объекта, а на его типе. Часть вьюеров показывает Pset-ы только экземпляра, не подтягивая унаследованные с типа. Поэтому при поиске BBIM_Roof в таких программах его стоит искать у типа объекта, а не у самого объекта.

Итог

• IFC5 закладывает компонентную архитектуру и неразрушающее редактирование на уровне спецификации; на момент публикации статьи финальный релиз ещё не вышел.

• Bonsai уже сейчас достигает похожего поведения в IFC4 не через изменение схемы, а через связку: JSON-рецепт приготовления геометрии внутри штатного IfcPropertySet, интерпретируемый собственным кодом программы.

• Сам по себе JSON в Pset не связан напрямую с геометрией. Пересборка формы требует явного вызова операции в интерфейсе Bonsai (или соответствующего вызова API при программной работе).

• Механизм работает только внутри программ, знающих что такое BBIM_… (например, Bonsai). Для остальных IFC-приложений это просто обычный текст.