Два часа выгрузки ради пустого параметра: проверяем ЦИМ для АГР внутри Revit

Меня зовут Кирилл, я работаю BIM‑координатором, писал эту статью совместно со своей коллегой Анастасией. Помучавшись с разработкой ЦИМ без какой‑либо автоматизации, вместе мы подготовили плагин IDS Core. В этой статье — проблемы, которые нас натолкнули на создание нужных инструментов.
Мы оба давно работаем в BIM, и в начале 2026 года перед нами появилась новая задача: нужно было научиться стабильно готовить модели в IFC под новые требования ДГП.

С января 2026 года архитектурно‑градостроительные решения в Москве сдаются вместе с цифровой информационной моделью в IFC. Требования к ней описаны машиночитаемо — файлами IDS, проверяет их сервис «Строим просто». Схема, в общем, понятная. Пока не начнёшь ей пользоваться.

Наш вечер выглядел так. Настроил маппинг, собрал вид для выгрузки, нажал «Экспорт». Модель тяжёлая, экспорт идёт два часа. Загружаешь IFC в чекер — и узнаёшь, что у одной рампы не заполнен RUS_Slope. Исправил за минуту. И снова два часа. Уже половина первого ночи, а ты сидишь и думаешь: почему я узнаю про пустой параметр из файла, которого полчаса назад не существовало, если сам параметр лежит в модели прямо передо мной?

Так появилась проверка внутри Revit, а за ней — ещё несколько инструментов, каждый из которых вырос из конкретной вечерней злости. Ниже — что мы сделали и на чём споткнулись.

Проверка по IDS, не выходя из Revit

Сама идея простая: всё, что проверяет внешний сервис, можно проверить в модели. IDS — это XML с набором спецификаций, у каждой написано, к кому она применяется и что у этих объектов должно быть заполнено. Нужен ещё маппинг экспорта (тот самый export ifc *.txt), по которому понятно, в какое свойство IFC уедет какой параметр Revit.

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

Две вещи, которые пришлось делать аккуратнее, чем хотелось

Класс IFC мы определяем так же, как это сделает экспорт. Соблазн взять таблицу «категория Revit → класс IFC» большой, но она врёт: экспорт смотрит на параметры «Экспорт в IFC» и «Экспорт в IFC как», а в Revit 2022 и старше — на единственный IfcExportAs. Плюс есть «Параметры экспорта» со значением «Нет», которое выкидывает элемент из выгрузки поверх всего остального. Если это не повторить, проверка будет ругаться на элементы, которых в файле не будет, и молчать про те, что уедут пустыми.

Помещения и зоны надо различать. В IFC они оба IfcSpace, а требования к ним разные. Спасает то, что у помещений есть параметр RUS_StudioApart, а у зон его нет вовсе: по наличию параметра, а не по его значению, и решается, какая спецификация к чему применяется.

Заодно выяснилось, что отсечённые элементы нельзя просто прятать: мы показываем их отдельной вкладкой с причиной — «не экспортируется», «класс не определён», «технический элемент, которого нет в IDS». Иначе первый же вопрос: «почему проверено 2082, а в модели 2500, вы там ничего не потеряли?».

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

ТЭП: считаем в модели, а не выписываем из десяти спецификаций

Следующее место, где уходил вечер, — технико‑экономические показатели. Раньше это выглядело как десяток спецификаций с фильтрами, из которых значения выписываются руками в XML. И так заново при каждом изменении модели, потому что площади поехали.

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

Пара выводов из практики

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

Считать лучше из шаблона. Мы берём XML, сформированный на сервисе, — там уже заполнены данные об объекте и авторском коллективе, а площади пустые или заведомо неверные, — и записываем в него посчитанное. Так не приходится собирать XML с нуля и спорить со схемой.

И обязательно нужен предпросмотр: что сейчас в шаблоне, что насчитали мы, какая разница и по скольким элементам получено значение. Кнопка «записать» без этого шага — способ молча испортить файл, который готовили полдня.

Зона есть в Revit, а в IFC её нет

Дальше начинается любимое: в модели всё выглядит правильно. Зона нарисована, площадь посчитана, в спецификации она есть. В IFC её нет. ТЭП не сходится, а где именно потерялись метры — непонятно.

Revit и экспорт считают по‑разному. Revit посчитает площадь даже при дефектной границе — ему достаточно замкнуть контур приблизительно. Экспорту нужно построить объёмное тело, и тут любая мелочь становится фатальной.

Сегмент короче допуска короткой кривой (по умолчанию 0,78 мм). Разрыв между сегментами — глазом не видно, тело не строится. Наслоение двух граничных линий друг на друга. Самопересечение контура. Находить это несложно: берём границы зоны, собираем контур, пробуем построить тело — не построилось, значит до IFC зона не доедет.

А вот чинить автоматически оказалось куда опаснее, чем находить.

Грабли первые: группы. Граничные линии часто лежат внутри групп — типовая секция, типовая квартира. Правка одной линии меняет определение группы, то есть все её копии. Поправили границу на первом этаже — на остальных девяти зоны остались без контура. Красиво. Теперь линии внутри групп инструмент не трогает вовсе: они работают «магнитом», к которому подтягиваются соседние свободные концы, а в отчёте написано, сколько таких линий и в каких группах.

Грабли вторые: доброжелательный Revit. Правка идёт в транзакции, у транзакции есть обработчик сообщений. Типовая реализация гасит предупреждения и соглашается с тем, что Revit предлагает по умолчанию. Разумно ровно до первого случая, когда для ошибки «в одной замкнутой области несколько зон» предложение по умолчанию — удалить лишние зоны. Диалог погашен, пользователь ничего не видит, зоны исчезают. Инструмент, который чинит зоны, их удаляет.

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

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

Газон, который считается трижды

Ещё одна история про площади — из благоустройства, и она про то, как правильная модель даёт неправильные цифры.

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

При выгрузке такое перекрытие распадается на несколько объектов, и площадь исходного элемента относится к каждому. Сервис считает по IFC и показывает озеленения больше, чем есть. Мы долго сверяли спецификацию с отчётом и не понимали, кто из них врёт. Оба не врут — они считают разные вещи.

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

Коллизии: 1500 в Navisworks против 200 на сервисе

Отдельная история вышла с проверкой пересечений. Мы выгрузили отчёт из Navisworks и получили полторы тысячи коллизий. Загрузили те же модели на сервис — двести.

Разница не магическая: Navisworks по умолчанию ищет по категориям Revit, а сервис — по классам IFC и своим правилам. Можно долго настраивать поисковые наборы, чтобы повторить чужую логику, а можно принять простую мысль: ориентироваться стоит на правила того, кто проверяет.

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

Тем, кто тоже разбирает эти отчёты, полезно знать: формат живой. Осенью 2026 года конфликты переехали внутрь «Матрицы коллизий» и разложились по парам дисциплин, а прежний счётчик в отчёте остался нулевым. Инструмент, который читал только старое место, честно сообщал «конфликтов нет» на отчёте с двумя с половиной тысячами пересечений. Так что если парсите чужие отчёты — проверяйте не только наличие поля, но и то, что оно не переехало.

Заодно сделали выгрузку в XML формата Navisworks: у части заказчиков приёмка устроена так, что им нужен именно он.

Семь версий Revit из одного исходника

Про совместимость спрашивают чаще, чем про всё остальное, поэтому коротко.

Самое заметное — идентификатор элемента. До Revit 2023 это 32-битное целое, с 2024-го — 64-битное. Мелочь, но вылезает везде, где идентификатор пишется в отчёт или читается обратно, поэтому вся работа с ним сведена в один небольшой слой: остальной код не знает, какая версия собирается.

Второе — платформа: 2020–2024 живут на.NET Framework 4.8, 2025 и 2026 — на.NET 8. Это один проект с переключателем, а не семь копий кода, иначе правку пришлось бы вносить семь раз и в семи местах о ней забывать.

Третье, неочевидное: чтобы собрать плагин под версию Revit, её не обязательно иметь на машине — API берётся из пакетов со ссылочными сборками. Но собранное не значит работающее: версии, которых нет под рукой, остаются зоной риска, и честнее это признавать, чем писать «поддерживаются все».

И привет тем, кто прогоняет сборку через обфускатор: Revit ищет классы команд по именам из манифеста и ленты, а интерфейс на WPF — свойства по именам в привязках. Публичные имена придётся сохранить, иначе окно откроется пустым, а кнопка не найдёт команду. Узнаете об этом не при сборке, а от пользователя.

Что в итоге

Три вывода, которые не зависят от инструмента:

• проверять модель до экспорта дешевле ровно на время экспорта — и это, внезапно, основная экономия, а не «удобный интерфейс»;

• считать по тем же правилам, по которым считает проверяющая сторона, дешевле, чем спорить с её цифрами;

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

Расскажите нам, пожалуйста, ваш опыт разработки ЦИМ для АГР. Возможно, что‑то мы сможем наладить и упростить жизнь для всех, кто занимается этой работой.