Проблема в другом. Самые дорогие ошибки обычно не входят в список правил, потому что никто не догадался их туда внести. Стена толщиной 380 вместо 400 в одном месте из четырёхсот. Оборудование с массой 1200 кг там, где у соседних позиций 120. Дверь, которая по параметрам открывается в сторону лестничной клетки.

Правило на такое не напишешь: заранее не знаешь, что именно пойдёт не так. Зато можно искать не нарушения, а странности.

В чём разница

Правило говорит: «параметр Марка не должен быть пустым». Оно проверяет соответствие условию.

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

Такой подход не заменяет правила, а дополняет их. Правила отсекают известные ошибки. Аномалии подсвечивают неизвестные.

Что реально ищется

Числовые выбросы. Берём все элементы одного типа и смотрим на распределение параметров: толщина, высота, объём, масса, площадь. Значения, выпадающие из общей картины, попадают в отчёт.

Простая математика, никакого обучения не требуется. На реальных моделях эта проверка стабильно вылавливает опечатки: 2500 вместо 250, метры вместо миллиметров, лишний ноль.

Редкие сочетания параметров. Если девяносто восемь процентов дверей с шириной 900 имеют определённый тип, а две штуки другой, это стоит посмотреть. Может быть, там особый случай. Может быть, копировали не тот элемент.

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

Странности в именах. Элементы, чьи имена не подходят ни под один принятый в проекте шаблон. Здесь достаточно кластеризации по строкам: девять групп с понятной структурой и десятая с мусором.

Геометрические странности. Элементы нулевого или почти нулевого объёма, дубли в одной точке, элементы, торчащие далеко за габариты здания. Такое появляется от неудачного копирования и не ловится ни одним правилом качества.

Нужны ли для этого нейросети

Честно: чаще всего нет.

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

Языковая модель полезна на другом шаге: когда нужно объяснить находку человеку. «Элемент 5482: толщина 380 при том, что у остальных 412 стен этого типа она 400; вероятно, ручное изменение экземпляра» читается лучше, чем строка с числами. На больших отчётах это экономит время того, кто разбирает.

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

Что делать с результатом

Главная опасность такого отчёта в том, что он превращается в шум. Если система выдаёт четыреста «странностей» на модель, их никто не будет смотреть.

Поэтому три правила.

Первое: ограничивать выдачу. Двадцать самых сильных отклонений, а не всё подряд. Остальное доступно по запросу, но не лезет в глаза.

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

Третье: помечать проверенное. Если проектировщик посмотрел и сказал «так и должно быть», элемент не должен всплывать в следующем отчёте. Без этого механизма люди перестают открывать отчёт через неделю.

Пример с цифрами

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

Поиск аномалий дал 63 замечания после фильтрации. Из них:

• 8 оказались реальными ошибками (толщины, отметки, один элемент с массой в тоннах вместо килограммов);
• 21 штука оказалась осознанными исключениями, их пометили и больше не показывали;
• 34 были шумом от особенностей моделирования, после чего правило подсветки подкрутили.

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

С чего начать

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

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

И помните про порядок: сначала правила для известных ошибок, потом аномалии для неизвестных. Наоборот не работает: в модели без базовой дисциплины любой поиск странностей утонет в мусоре.

Задача выглядит идеальной для языковой модели: есть текстовое описание элемента, есть справочник, надо сопоставить. На практике всё сложнее, но не безнадёжно. Разберём, что здесь получается, а что заканчивается порчей модели.

Три задачи, которые путают

Заполнение по правилу. Всем стенам с типом «Наружная 400 газобетон» проставить материал и код. Тут никакого ИИ не нужно: это фильтр и пакетная правка, десять минут в Dynamo. Если вам предлагают нейросеть для такой задачи, вам продают лишнее.

Классификация. Элементу нужно присвоить код из классификатора: КСР, собственный корпоративный справочник, IFC-класс. Описание элемента текстовое, вариантов в справочнике тысячи, прямого соответствия нет. Вот здесь модель полезна.

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

Дальше речь про вторую и третью. Первая решается без ИИ, и это стоит помнить.

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

Казалось бы, достаточно поиска по совпадению слов. На практике совпадений нет. В модели написано «Труба стальная ВГП Ду25». В номенклатуре: «Труба стальная водогазопроводная оцинкованная 25х3,2 ГОСТ 3262-75». Общих слов мало, порядок другой, аббревиатура раскрыта. Точный поиск не находит ничего, нечёткий выдаёт десяток похожих позиций разного диаметра.

Добавьте сюда человеческий фактор: сокращения у каждого свои, где-то пробел, где-то дефис, где-то латинская «C» в русском слове «Сгон». Такие подмены букв глаз не различает, а точное сравнение строк различает прекрасно, и позиция просто не находится.

Языковая модель здесь работает лучше поиска, потому что понимает, что «ВГП» и «водогазопроводная» это одно и то же, а «Ду25» относится к диаметру, а не к марке стали.

Как это устроено у нас

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

Шаг 1. Сначала правила, потом модель. Всё, что сопоставляется однозначно по типу, коду или прямому совпадению, закрывается скриптом. Обычно это 60–70 процентов элементов. К языковой модели уходит только остаток, где правило не сработало.

Шаг 2. Кандидаты, а не свободный ответ. Модель не придумывает код из головы. Мы даём ей список из 10–20 подходящих позиций справочника, найденных нечётким поиском, и просим выбрать одну и объяснить выбор. Разница принципиальная: выбор из списка проверяем, свободную выдумку нет.

Шаг 3. Уверенность обязательна. Ответ должен содержать не только выбранную позицию, но и оценку уверенности с причиной. «Совпал диаметр и материал, но не совпал ГОСТ»: это сигнал человеку посмотреть.

Шаг 4. Порог и очередь на проверку. Высокая уверенность идёт в модель автоматически, средняя попадает в очередь на проверку глазами, низкая возвращается как «не определено». Пустое поле честнее неправильного кода.

Шаг 5. Запись решений. Каждое подтверждённое человеком сопоставление сохраняется в таблицу. На следующем проекте оно закроется правилом на первом шаге, без всякой модели. Через два-три объекта доля ручной работы падает вдвое, и это главный аргумент за такую схему: она дешевеет с каждым проектом, тогда как ручное заполнение стоит одинаково всегда и зависит только от того, сколько людей вы на него посадили.

Цифры, которые получаются

По последнему проекту среднего размера: 11 400 элементов инженерных систем. Правилами закрылось 7 900 позиций, это две трети. Модель обработала оставшиеся 3 500 и предложила варианты: с высокой уверенностью 2 100, со средней 1 000, отказалась от 400.

Человек проверял среднюю группу и отказы, всего 1 400 позиций. Это заняло полтора дня вместо двух недель на всё вручную. Из проверенных высокоуверенных выборочно смотрели 200 штук и нашли 6 ошибок. Все на позициях, где в номенклатуре есть похожие типоразмеры.

Вывод отсюда простой: полностью доверять нельзя даже уверенным ответам, но выборочная проверка ловит систематические промахи быстро.

Где она ошибается предсказуемо

Типоразмеры рядом. 25х3,2 и 25х2,8 для модели почти одинаковы, а для закупки это разные позиции. Лечится просто: числовые характеристики сравниваются отдельно, кодом.

Устаревшие позиции. В справочнике осталась старая номенклатура, помеченная как неактуальная. Модель её выберет, если не сказать, что нельзя. Фильтр по признаку актуальности ставится до передачи кандидатов.

Аналоги и заменители. «Можно взять вот это, оно почти то же самое»: рассуждение полезное для человека и вредное для автоматики. Мы просим модель не предлагать замены, а честно отвечать «не нашёл».

Редкие узлы и нетиповое оборудование. Здесь она угадывает, и точность падает резко. Такие позиции лучше сразу отправлять человеку, определив их по отсутствию близких кандидатов.

Что нужно, чтобы это заработало

Неприятная часть: без порядка в данных ничего не выйдет. Нужен один справочник, а не пять версий в разных отделах. Нужны заполненные типы и параметры в модели: если у элемента написано «Стена 1», сопоставлять нечего ни человеку, ни машине. Нужно решить, кто отвечает за подтверждение спорных позиций, иначе очередь на проверку никто не разберёт.

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

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

Когда не надо

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

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

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

Что модель делает хорошо

Каркас скрипта. Импорты, транзакция, сбор элементов через FilteredElementCollector, вывод результата. Эта часть повторяется в каждом скрипте, и модель её знает.

Логику обработки данных. Отфильтровать, сгруппировать, посчитать, отсортировать, собрать словарь. Обычный Python, где Revit ни при чём. Здесь ошибок практически нет.

Регулярные выражения и парсинг строк. Разобрать марку вида «КЖ-1.3-205» на составляющие, собрать имя листа по шаблону, вытащить число из текста. Задача, на которой человек тратит полчаса и три опечатки.

Объяснение чужого кода. Прислали скрипт от предыдущего подрядчика, никто не понимает, что он делает. Модель разбирает построчно, и это честно экономит день.

Перевод между API. Есть рабочий код на C# из плагина, нужен аналог на Python для Dynamo. Структурно задача механическая, модель справляется.

Где она врёт

Главная проблема одна: модель не знает точную сигнатуру методов Revit API вашей версии и на месте пробела уверенно придумывает правдоподобное.

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

• метод, которого нет вовсе, но название звучит логично: element.SetParameterValue("Марка", "КЖ-1");
• перепутанные версии: код для Revit 2019 в проекте на 2024, где перечисления единиц измерения переехали в UnitTypeId;
• забытая транзакция: код меняет модель без Transaction, и Revit отвечает исключением;
• неверный порядок аргументов там, где их четыре и три из них похожи;
• обращение к параметру по русскому имени, когда в проекте он называется иначе.

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

Как просить, чтобы получалось

Разница между «получил мусор» и «получил рабочий код» почти целиком в постановке.

Указывайте версию. «Revit 2024, pyRevit, IronPython 3» в первой строке запроса убирает половину ошибок с несовместимостью.

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

Просите минимальную версию. «Без обработки ошибок, без логирования, только суть». Короткий код проще проверить. Красивую обвязку добавите потом, когда логика подтвердится.

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

Спрашивайте про допущения. Прямой вопрос «какие места здесь могут не работать в моей версии» заставляет модель самой указать на слабые точки. Она их обычно знает, просто не говорит, пока не спросят.

Порядок проверки, который спасает модель

Правило простое: скрипт от языковой модели не запускается на рабочем файле. Никогда, даже если выглядит очевидным.

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

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

Что это даёт по времени

Честные цифры из практики.

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

При этом задачи, где нужна тонкая работа с API (свои классы, обработка событий, расширения интерфейса), почти не ускорились. Там модель помогает как справочник, но пишет всё равно человек.

Средняя экономия по нашим задачам вышла процентов сорок. Не десятикратно, как обещают в роликах, но заметно.

Кому это подходит

Здесь важная оговорка.

Языковая модель ускоряет того, кто может проверить результат. Если вы читаете код и понимаете, что делает FilteredElementCollector, вы получите готовый скрипт за минуты вместо часа.

Если код читать не умеете, вы получите красивый текст, который непонятно почему не работает, и потратите на разбирательство больше, чем на изучение основ. Начинать в таком случае надо не с промптов, а с первого скрипта в Dynamo и понимания, как вообще устроен доступ к элементам.

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

Короткий чек-лист

Перед тем как просить код:

1. Назовите версию Revit и среду запуска.
2. Приложите образец своего рабочего скрипта.
3. Попросите сначала версию «только вывод, без записи».
4. Проверьте пять позиций из вывода глазами.
5. Запускайте на копии, потом на рабочем файле после синхронизации.

Пункт четвёртый пропускают чаще всего. Именно он ловит выдуманные методы и уехавшие единицы до того, как они попадут в модель.

Генеративное проектирование это не «ИИ придумал за нас». Это перебор вариантов по заданным правилам с оценкой по заданной функции. Вся сложность в правилах и в функции. Разберём, где на этом получается результат, а где выходит дорогая игрушка.

Что это на самом деле такое

Разберём по частям.

Три составные части, без которых ничего не работает.

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

Ограничения. Что нарушать нельзя: нормативные расстояния, минимальные площади, несущие оси, зоны обслуживания оборудования.

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

Дальше алгоритм генерирует варианты и оценивает. Метод перебора вторичен: от простого перебора сетки до эволюционных алгоритмов. Качество результата определяется тем, насколько честно описаны ограничения.

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

Где действительно взлетает

Размещение однотипных объектов

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

Здесь алгоритм выигрывает у человека. Задача чисто комбинаторная. На складе средней площади перебор находит компоновку на 8–12 процентов вместительнее той, что собирали руками, а это реальные деньги, посчитанные в квадратных метрах.

Трассировка сетей

Проложить трассу от точки А до точки Б по коридорам, обойдя зоны, где нельзя, с минимальной длиной и минимумом поворотов. Формальная задача, решается уверенно. Ограничение одно: работает, когда пространство уже определено. Есть модель, есть зоны, есть точки подключения. На стадии, когда планировка ещё плавает, толку мало.

Раскрой и подбор сечений

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

Варианты объёмно-планировочных решений на ранней стадии

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

Где остаётся демо

А теперь про обещания из презентаций.

«Оптимальная планировка квартиры»

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

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

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

Генерация фасадов и форм

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

«Полностью автоматический проект»

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

Что нужно на входе

Здесь начинается неприятная правда о стоимости.

Чтобы алгоритм перебирал варианты, кто-то должен формализовать правила. Это работа опытного проектировщика вместе с тем, кто пишет скрипт. Неделя-две на первую задачу, если правила простые. Месяц, если в них есть нормативные тонкости.

Дальше нужна проверка. Сгенерированные варианты кто-то должен отсмотреть. Алгоритм честно найдёт лазейку в описании ограничений: поставит оборудование так, что формально проход есть, а дверь шкафа не откроется.

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

Разовая задача на одном объекте почти всегда решается быстрее руками.

Без вариантов.

Как начать, если хочется попробовать

Точно не с планировок.

Возьмите узкую задачу, которая у вас повторяется, и где результат измеряется числом.

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

Дальше можно двигаться к трассировке и компоновке. Ключ не в том, чтобы «внедрить генеративное проектирование», а в том, чтобы решить конкретную задачу, у которой есть числовой критерий.

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

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

Работает: штампы и текстовые данные

Распознать основную надпись, номер листа, шифр, стадию и дату ревизии: задача, которую современный OCR решает почти без ошибок. На выходе таблица: файл, шифр, лист, ревизия.

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

Что ломает распознавание: сканы с перекосом больше пяти градусов, подписи от руки поверх штампа, объединённые ячейки нестандартной формы. На чистых PDF из CAD точность практически стопроцентная, на плохих сканах падает процентов до восьмидесяти, то есть каждый пятый лист придётся проверять глазами.

Работает: таблицы и спецификации

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

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

Отдельно предупреждение про цифры. Языковая модель может «улучшить» распознанное значение: увидела 12,5 там, где 125, и подставила то, что кажется правдоподобнее. Поэтому числа берут из OCR, а модель используют только для структуры таблицы, где заголовки, где единицы, к какой позиции относится строка.

Работает: поиск изменений между ревизиями

Задача, где сравнение картинок работает лучше человека. Два PDF одного листа разных ревизий, на выходе подсвеченные области, которые изменились.

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

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

Работает частично: векторизация

Превратить растровый чертёж в вектор (линии, дуги, замкнутые контуры) умеют давно, и алгоритмы стали заметно лучше.

Проблема не в линиях, а в смысле. Векторизатор выдаёт множество отрезков. Он не знает, что вот эти две параллельные линии на расстоянии 380 мм это стена, а вот эти, тоже параллельные, размерная линия с выносками. Без этого понимания вектор остаётся картинкой, только другого формата.

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

Не работает: «PDF на входе, готовая модель на выходе»

Здесь стоит объяснить, почему это не вопрос очередной версии.

Чертёж не содержит всей информации о здании. Он рассчитан на человека, который читает его вместе с пояснительной запиской, спецификациями, общими указаниями и собственным опытом. На плане не написано, что перегородка идёт до перекрытия, а не до подвесного потолка. Это следует из узла на другом листе. Толщина слоя пирога пола указана в одном месте на весь проект. Отметка низа балки берётся из разреза, которого может не быть.

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

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

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

Что даёт связка на практике

Собранный вместе набор выглядит так:

• Приёмка архива. За час получаем ведомость листов и список того, чего не хватает.
• Спецификации. Распознаются в таблицы, проверяются контрольными суммами и уходят к сметчику раньше, чем начнётся моделирование.
• Разметка DWG. Слои размечаются полуавтоматически, типовые планы собираются быстрее.
• Ревизии. Сравниваются автоматически, и на модель попадают только реальные изменения.

Экономия по проекту среднего размера: от нескольких дней до пары недель, в основном на подготовке и на сверке. Само моделирование ускоряется процентов на двадцать, не больше.

Это не звучит как революция, зато это работает каждый день, а не в презентации.

Как проверить чужое решение за час

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

Дальше смотрите на три вещи. Показывает ли система свою уверенность по каждому полю или выдаёт результат одинаково уверенно. Что происходит с числами, которые не удалось прочитать: пустое поле честнее правдоподобной выдумки. Сколько времени займёт проверка результата человеком. Если столько же, сколько ручной ввод, экономии нет.

Ответ «у нас точность 98 процентов» без указания, на каких документах она измерена, ничего не значит. На чистых PDF из CAD такую точность даёт и бесплатный OCR.

Тем, кто планирует переводить документацию в модель, полезно заранее посмотреть, как устроен процесс перевода 2D в BIM. А общая картина по применению языковых моделей в проектировании есть в разборе где LLM реально работают в BIM, а где нет.

Через три месяца сметчик просит по ней объёмы. И выясняется: у половины стен не указан материал, перегородки смоделированы одним типом, спецификация оборудования пустая. Формально работа сдана. В задании ведь было написано «выполнить BIM-модель».

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

1. Вес файла и что внутри

Начинайте со скучного.

Откройте модель и посмотрите на список связей и импортов.

Частая находка: вкрученные внутрь DWG-подложки, которые подрядчик забыл удалить. Они тянут вес, замедляют работу и иногда содержат чужую геометрию, которая попадает в спецификации.

Второе: количество семейств. Если в проекте 1200 типов семейств на 20 тысяч элементов, значит, элементы делали «каждый раз заново», и никакой массовой обработки по ним не выйдет.

2. Уровни, оси и координаты

Проверяется за пять минут, а стоит дорого.

Отметки уровней должны совпадать с проектными, а не быть круглыми числами «примерно там». Оси называются так же, как на чертежах. Без исключений. Базовая точка проекта должна быть согласована, особенно если модель будут объединять с чужими файлами. Простой тест: откройте разрез и сверьте три произвольные отметки с чертежом. Если хоть одна не сходится, дальше можно не смотреть, пока не исправят.

3. Элементы на своих уровнях

Классика: перекрытие третьего этажа принадлежит второму, а высота задана вручную смещением. Визуально всё правильно, а в спецификации по этажам каша.

Проверка: сделайте спецификацию с группировкой по уровню и посмотрите на количества. Если на техническом этаже вдруг 40 дверей, значит, кто-то моделировал «на глаз».

4. Один тип, одно назначение

Посмотрите список типов стен. Здоровая модель: «Стена наружная 400 газобетон», «Перегородка ГКЛ 100». Больная: «Стена 1», «Стена 1 копия», «Стена 200 новая». То же самое с семействами дверей и оборудования. Названия это не эстетика: по ним потом фильтруют, считают и сопоставляют с номенклатурой. Хаос в названиях означает ручную работу на каждом шаге дальше.

5. Параметры: заполнено или пусто

Здесь начинается главное.

Именно тут проходит разница между моделью и картинкой.

Возьмите список параметров, который был в задании, и сделайте по каждому спецификацию с фильтром «значение пустое». Результат должен быть нулевым по обязательным полям.

Если задания с параметрами не было, минимум для проверки такой: марка, материал, тип, принадлежность к системе (для инженерки), высотная отметка. Пустые значения хотя бы в одном из них означают, что объёмы придётся добивать руками.

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

6. Спецификации сходятся с документацией

Самая полезная проверка. И самая пропускаемая.

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

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

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

7. Отчёт о расхождениях в исходниках

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

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

Нормальный отчёт выглядит как таблица: что нашли, на каких листах, как приняли решение, с кем согласовано.

Без этой таблицы приёмка превращается в веру на слово.

8. Проверка на коллизии, но с умом

Прогонять «все против всех» бессмысленно: получите тысячи пересечений и ничего не поймёте.

Полезнее три-четыре адресных проверки: конструкции против вентиляции, конструкции против водоснабжения, отверстия против несущих элементов. С допусками, чтобы изоляция и уклоны не поднимали шум.

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

Как оформить это в договоре

Чтобы приёмка не превращалась в спор, хватит трёх пунктов в задании.

Первое: таблица параметров, которые должны быть заполнены, с указанием, кто их источник. Второе: допустимое расхождение объёмов с проектными ведомостями по контрольным позициям. Третье: перечень проверок перед сдачей и требование приложить их результаты.

Формулировка «модель должна соответствовать LOD 300» без этих трёх пунктов не значит ничего: у каждого своё представление о трёхстах.

Что делать, если модель уже принята и она плохая

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

Разумный путь: не чинить всё, а выбрать то, что нужно ближайшие полгода. Нужны объёмы по бетону? Приводим в порядок конструкции: типы, материалы, марки. Нужна координация? Приводим в порядок уровни и связи. Остальное оставляем как есть.

Такая точечная доводка занимает одну-две недели. Полное перемоделирование, для сравнения, месяцы. Заодно становится видно, что из модели реально используется, а что было нарисовано просто так.

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

Честный ответ на этом этапе: «не знаю». Не из вредности: цена перевода 2D в модель зависит не от количества листов, а от того, насколько чертежи сходятся друг с другом. Пока их не открыли, этого не видно.

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

Что вообще значит «перевести в BIM»

Под одной фразой заказчики понимают три разные работы.

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

Модель для расчётов. Из неё берут объёмы, считают смету, планируют закупки. Значит, у элементов должны быть заполнены параметры, материалы и марки, а спецификации обязаны сходиться с ведомостями из проекта.

Модель для эксплуатации. В неё вносят оборудование с паспортами, сроками обслуживания, привязками к системам. Такое заказывают собственники зданий, а не строители.

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

Пять этапов, из которых состоит работа

1. Разбор исходников

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

Этап скучный, занимает от двух дней до недели. Пропускать его нельзя: моделировать по несогласованным чертежам значит перемоделировать потом.

2. Настройка шаблона и правил

До первой стены договариваются о структуре: уровни, оси, единая система координат, наименование семейств, набор параметров, разбивка по файлам. Если делать это «по ходу», к середине проекта получится модель, где стены названы четырьмя способами.

Здесь же определяют LOD по элементам. Не «весь проект LOD 300», а конкретно. Несущие конструкции: точная геометрия и марки. Перегородки: габариты и тип. Инженерные системы: трассы с диаметрами. Оборудование: габариты и позиция по спецификации.

3. Моделирование

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

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

4. Наполнение данными

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

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

5. Проверка и отчёт о расхождениях

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

Отдельный документ, который заказчик обязан требовать: перечень расхождений между чертежами. Обычно там от 20 до 200 пунктов: несовпадение отметок, разные толщины одной стены на разных листах, оборудование, которого нет в спецификации. Это не придирки исполнителя, а список того, что пришлось решать за проектировщика.

Что реально влияет на цену

Площадь это только один множитель из пяти, и не главный.

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

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

Глубина проработки. Разница между «габариты и трассы» и «каждый фитинг с артикулом» это разница в стоимости в два-три раза.

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

Срок. Сжатый график означает больше людей на одном файле, а значит больше времени на координацию и больше рисков.

Сюрпризы, которые вылезают на второй неделе

Первую неделю всё идёт гладко. Потом начинается.

Отметки не совпадают: на плане отметка чистого пола 0.000, на разрезе тот же уровень подписан как +0.150. Кто прав, знает только автор, а моделировать нужно сегодня.

Оборудования нет в спецификации. На плане стоит, марка подписана, в ведомости отсутствует. Значит, объём по нему не посчитается, пока заказчик не подтвердит позицию.

Стены разной толщины на разных листах. Классика при нескольких ревизиях: план обновили, разрез забыли.

Инженерка идёт сквозь балки. В 2D это никого не смущало, потому что разделы никто не накладывал друг на друга. В модели видно сразу, и вопрос «а как теперь?» прилетает заказчику.

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

Что писать в задании

Минимальный набор, без которого начинать не стоит:

• Цель. Для чего модель: объёмы, коллизии, эксплуатация, тендер.
• Разделы и LOD по каждому. Отдельной таблицей, а не одной строкой на весь проект.
• Перечень параметров, которые должны быть заполнены. Если планируется выгрузка в смету или в снабжение, список согласуется с ними, а не придумывается на стороне подрядчика.
• Формат сдачи: RVT какой версии, нужен ли IFC, какая схема именования файлов.
• Что считается приёмкой: какие проверки прогоняются, какой процент незаполненных параметров допустим (обычно ноль по обязательным), нужен ли отчёт о расхождениях.
• Порядок работы с вопросами: кому уходят запросы, за сколько дней приходит ответ.

Половина конфликтов в таких проектах не про качество, а про то, что стороны по-разному поняли слово «модель». Таблица LOD и список параметров снимают этот спор до его начала.

Когда переводить не нужно

Не всякий проект стоит переводить целиком.

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

Если объект старый и документация не совпадает с фактом, начинать надо не с DWG, а с обмеров или лазерного сканирования. Модель по чертежам, которые расходятся с реальностью на 200 мм, будет красивой и бесполезной.

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

Что дальше

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

Если планируете такой проект, полезно заранее посмотреть, как принимать результат и на что смотреть при проверке модели: чек-лист приёмки модели, сделанной по вашим чертежам. И отдельно, как устроена проверка моделей по правилам компании, чтобы «принято» означало одно и то же для всех.

Так рынок и выглядит снаружи. Список есть, проверить его нечем. Под «автоматизацией BIM» одновременно понимают подписку на облачный сервис, разработку плагина за три недели и бригаду моделлеров на аутсорсе — вещи разной природы, с разной ценой и разным результатом.

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

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

Контекст, в котором всё это происходит: по отраслевым публикациям, применение информационных моделей у застройщиков в первом полугодии 2026 дошло примерно до 47%, а Минстрой утвердил план внедрения ИИ в строительстве на 2026 год — проверка документов на соответствие нормам, ценообразование, мастер-планирование. Спрос на контроль качества моделей растёт быстрее, чем предложение инструментов.

Сегмент 1. Коробочные продукты для проверки моделей

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

Tangl Control (tangl.cloud). Облачный сервис вокруг электронного EIR: проверка параметров, геометрических коллизий, соответствия проектных решений нормативным требованиям. Отчёт пересобирается автоматически после изменений, замечания возвращаются проектировщику прямо в Revit. Цену на сайте не публикует.

BIM Inspector от BIMTeam. Команда цифровой трансформации ПИК, инструмент вырос внутри крупного застройщика и вышел наружу. Работает панелью в Revit: конструктор правил, привязка правил к группам файлов, проверка соответствия машиночитаемым требованиям IDS без экспорта в IFC. Успешные проверки в панели зелёные, ошибки красные: инструмент координатора, а не отчёт на сорок страниц.

G-Tech (gmini.tech). Здесь проверки — один модуль большой платформы: среда общих данных, расчёт объёмов, тендеры, стройконтроль, интеграция с 1С. Правила проверки связаны с электронным EIR и классификацией элементов, отчёты выгружаются в XLS или BI. По заявлению компании, в 2026 году в модуль добавляется проверка на коллизии.

Solibri — зарубежный эталон rule-based проверки по IFC, на который до сих пор ссылаются в спорах о «правильной» методике. Официальных поставок в Россию нет, компании доживают на ранее купленных лицензиях либо переходят на отечественные продукты.

Кому подходит. Требования типовые или близки к типовым, результат нужен через неделю, своего разработчика нет. Коробка закроет 70-80% формальных проверок сразу, и это честная сделка.

Чем ограничены. Правила живут внутри чужой модели данных: проверить можно то, что предусмотрел разработчик. Пункт EIR вроде «наименование должно быть корректным» коробка не понимает — его надо превращать в маску, а маска у каждого заказчика своя. Результат оказывается в их интерфейсе, и если ваш процесс построен вокруг 1С или собственного классификатора, стыковка становится отдельным проектом.

Сегмент 2. Студии заказной разработки под Revit API и Dynamo

Как устроено. Вам пишут код под ваши процессы: скрипт Dynamo, плагин с кнопкой в Revit, сервис на API. Продаётся не лицензия, а время и результат.

Кто заметен по открытым сайтам на сентябрь 2026:

• bimlib.pro — плагины и приложения для Revit, AutoCAD и других САПР на C#, Python, Java, C++, вплоть до отдельных веб- и десктоп-приложений.
• Академия BIM (bimacad.ru) — разработка Dynamo-скриптов с описанным циклом: аналитика, прототип, разработка, тестирование, сопровождение. Рядом каталог готовых скриптов и продукты партнёров.
• ЭНЭКА — команда координаторов, мастеров и программистов; на сайте заявлено больше 20 сложных плагинов и свыше 100 скриптов для разных разделов в Revit и Civil 3D.
• ALTEC Systems (Екатеринбург) — индивидуальные BIM-решения с 2020 года, плагины и семейства Revit; в 2022 году выпустили веб-сервис расчёта инсоляции и КЕО с выгрузкой модели прямо из Revit.
• BIM Global, BIMLAB (bimlab.ru), Tiver Group — программирование Dynamo, плагины к Revit и AutoCAD, работа с Revit API, C#, Python, Forge.
• Отдельная подгруппа — магазины плагинов вроде bim2b.ru и внутренние команды больших компаний, выкладывающие свои инструменты наружу. Показательный кейс КРОК на Хабре описывает типичный путь: сначала скрипты Dynamo, потом собственный плагин, потом SQL Server под данные.

Формат работы у всех почти одинаковый: разбор задачи, оценка, прототип, доводка, передача с инструкцией. Разница в глубине — кто-то останавливается на скриптах, кто-то доводит до сервиса с базой данных.

Возвращаясь к списку от ассистента. Сайтами с описанием услуг подтвердились ЭНЭКА, ALTEC Systems, BIM Global, BIMLAB и Академия BIM. По BIM Machine, HAPPY BIM и BIM Support прямой поиск публичной страницы услуг ничего внятного не дал: возможно, эти команды известны по чатам и конференциям, а не по сайтам. Списку от нейросети верить на слово не стоит, проверять по источникам придётся всё равно.

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

Сегмент 3. BIM-моделирование как услуга

Что покупают. Модель, а не инструмент. Оплата идёт за объём: квадратные метры, уровень проработки LOD, стадия проекта. Либо за день работы специалиста.

Кто: ec-rs.ru, twize.ru, obmery-zamery.ru, ir-proekt.ru и десятки региональных бюро. Услуги — моделирование по чертежам или облаку точек, scan-to-BIM, восстановление документации, ведение по стадиям от предпроекта до исполнительной модели.

Единственный сегмент, где цены публикуют открыто. По состоянию на сентябрь 2026: ec-rs.ru указывает «от 39 000 ₽» за проект, twize.ru — ориентир от 30 000 ₽ за день работы специалиста, bimlab.ru пишет, что BIM-проектирование дороже классического CAD на 25-35% при сроках примерно на 30% дольше. Лицензии ПО на рабочее место оцениваются в 2 000-16 000 $ в год.

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

Сравнение сегментов

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

Как выбрать под свою задачу

Вопросы к себе, в порядке важности. Отвечать честно, иначе смысла нет.

Сколько объектов в год? До пяти похожих объектов автоматизация чаще не окупается: проще проверять руками или взять коробку на минимальном тарифе. От десяти повторяющихся объектов разработка начинает возвращать деньги на третьем-пятом запуске.

Есть ли записанный BIM-стандарт или EIR? Если правил нет на бумаге, не поможет ни коробка, ни разработка. Проверять нечего. Начинать надо с описания правил, и это работа BIM-менеджера, а не подрядчика.

Нужен ли доступ к 1С, ERP или своему классификатору? Ответ «да» почти наверняка выводит вас из первого сегмента. Исключение — платформы, у которых интеграция заявлена как функция, вроде G-Tech.

Есть ли свой разработчик или сильный BIM-менеджер? Есть — половину задач закроете сами, дешевле купить обучение и сопровождение. Нет — считайте, что вместе с инструментом покупаете и того, кто будет чинить его через год.

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

Кто отвечает за инструмент внутри компании? Без владельца процесса тихо умирает и коробка, и заказной код.

Где на этой карте BIM Pulse Ufa

Второй сегмент, узкая его часть: автоматизация проверок под правила конкретной компании и интеграции через API с системами заказчика. Исходники передаём, подписки нет.

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

Чего на рынке нет

Итог обзора честнее выглядит через пробелы, а не через список компаний.

Цен. Из трёх сегментов их публикует только моделирование, где конкуренция по стоимости и деваться некуда. Разработка и коробочные продукты цену прячут целиком. Для заказчика это означает недели переговоров ради понимания порядка суммы.

Независимых сравнений. Ни один продукт не показывает, сколько нарушений он находит на одной и той же тестовой модели рядом с конкурентом. Бенчмарка нет, выбор идёт по демо и по знакомым.

Связки BIM с учётными системами. Интеграцию с 1С заявляет G-Tech, у остальных это либо кастом, либо не заявлено вовсе. Между тем именно там живут деньги: объёмы, спецификации, закупки.

Услуг вокруг ИИ. Статей про искусственный интеллект в проектировании много, готовых инструментов единицы, а компаний, которые делают ИИ-разбор под конкретный процесс проектной организации, в открытой выдаче почти нет. Разрыв между разговорами и предложением здесь самый широкий на рынке.

Разговора про исходники. Кто владеет кодом после сдачи, что будет при выходе новой версии Revit, можно ли сопровождать инструмент без автора — эти вопросы на сайтах не поднимает почти никто, а всплывают они через год.

Частые вопросы

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

Сколько стоит автоматизация проверки BIM-моделей в 2026 году? Российские продукты цену публично не называют. По заказной разработке публичный ориентир: простой скрипт 15-40 тыс. ₽, средний 60-120 тыс. ₽, плагин с интерфейсом 150-350 тыс. ₽; рабочий контур из 10-15 проверок сопоставим с месяцем работы инженера-автоматизатора.

Можно ли заменить Solibri российским аналогом? Частично. Tangl Control, BIM Inspector и модуль проверок G-Tech закрывают основные сценарии по параметрам и коллизиям, но методика правил и работа с IFC у них устроены иначе, и переносить настройки один в один не получится.

Что выбрать, если объектов мало? Ручную проверку по чек-листу плюс минимальный набор скриптов на самые частые ошибки. При пяти объектах в год ни подписка, ни разработка обычно не окупаются.

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

Что делать дальше

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

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

На этом месте застревает каждый, кто впервые открыл узел Python Script и дёрнул AsDouble(). Дальше начинается интереснее: округление, накопление погрешности, запятая вместо точки в русской локали и спецификация, где объём отличается от правильного в 35 раз. Разберём по порядку, с кодом.

Что Revit хранит внутри

Отображение на экране и хранение в базе — разные вещи. Настройки единиц проекта (вкладка «Управление» → «Единицы проекта») меняют только показ. Внутри всегда одно и то же:

• длины — в десятичных футах;
• площади — в квадратных футах;
• объёмы — в кубических футах;
• углы — в радианах;
• координаты точек — в футах от внутреннего начала координат.

Коэффициенты, которые стоит держать в голове: 304.8 мм в футе, 0.09290304 м² в квадратном футе, 0.028316846 м³ в кубическом.

Отсюда классика жанра. Забыли пересчитать объём — цифры в ведомости бетона отличаются в 35 раз. Умножили длину на 304.8 дважды — получили километры вместо метров. И самое обидное: записали в параметр 3000, имея в виду миллиметры, а Revit прочитал 3000 футов и построил элемент длиной 914 метров.

AsDouble, AsValueString, AsString: чем отличаются

Три метода параметра, которые путают чаще всего.

AsDouble() возвращает число во внутренних единицах. Для длины — футы. Работает только если у параметра StorageType = Double, иначе вернёт мусор или ноль.

AsValueString() возвращает строку ровно в том виде, в каком значение показано в интерфейсе: «3000» или «3000,0 мм», в зависимости от настроек единиц проекта. Удобно для отчёта, опасно для вычислений.

AsString() для числового параметра вернёт None. Он для текстовых. Отсюда любимая ошибка новичка: AttributeError: 'NoneType' object has no attribute 'strip'.

Правильный порядок — сначала спросить тип хранения, потом читать:

from Autodesk.Revit.DB import StorageType

def prochitat(p):
    if p is None or not p.HasValue:
        return None
    st = p.StorageType
    if st == StorageType.Double:
        return p.AsDouble()          # футы, радианы, кубофуты
    if st == StorageType.Integer:
        return p.AsInteger()         # в том числе Да/Нет: 1 и 0
    if st == StorageType.String:
        return p.AsString()
    if st == StorageType.ElementId:
        return p.AsElementId()
    return None

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

Конвертация: UnitUtils и UnitTypeId

С Revit 2021 единицы описываются через ForgeTypeId, и рабочая пара выглядит так:

from Autodesk.Revit.DB import UnitUtils, UnitTypeId

futy = param.AsDouble()
mm = UnitUtils.ConvertFromInternalUnits(futy, UnitTypeId.Millimeters)

# обратно, когда пишем в модель
param.Set(UnitUtils.ConvertToInternalUnits(3000.0, UnitTypeId.Millimeters))

Полезные значения: UnitTypeId.Millimeters, Meters, SquareMeters, CubicMeters, Degrees, Kilograms.

Старый код на DisplayUnitType.DUT_MILLIMETERS писался под Revit 2020 и раньше. В 2021 он помечен устаревшим, в 2022 из API убран, и скрипт падает с AttributeError: 'DisplayUnitType' object has no attribute ... или сообщением о неподдерживаемом типе. Если тащите библиотеку скриптов из старых версий, это первое, что придётся переписать.

Почему не просто делить на 304.8? Для длин разницы нет. Для площадей, объёмов и всего, что связано с массой и температурой, коэффициенты нетривиальны, и UnitUtils избавляет от их поиска. Плюс код читается: ConvertFromInternalUnits(v, UnitTypeId.CubicMeters) понятнее, чем v * 0.028316846.

Отдельная деталь — общие параметры типа «Число» (Number). У них нет единиц вообще, значение хранится как есть. Конвертировать их нельзя, иначе коэффициент армирования 0.85 превратится в 259.

Почему в ноде 3000, а в питоне 9.84

Дело в том, что штатные узлы Dynamo уже конвертируют значения. Element.GetParameterValueByName отдаёт число в единицах проекта, а вызов API внутри Python Script — во внутренних. Один и тот же параметр, два разных числа, и оба правильные.

Практический вывод: не смешивайте источники в одном графе. Либо всё читается узлами и дальше идёт как есть, либо всё читается через API и конвертируется на выходе. Гибрид даёт ошибку в 304.8 раза, которую замечают уже в напечатанной ведомости.

То же касается геометрии. Координаты точек, полученных из API, живут в футах, и складывать их с координатами из Dynamo-узлов без пересчёта нельзя.

Как устроен сам граф и куда вставлять питон, разбирал раньше: первый скрипт в Dynamo.

Округление и накопление ошибки

Правило одно: считать в футах, округлять только на выводе.

Соблазн округлить сразу понятен — числа страшные. Цена ошибки видна на простом примере. Берём 500 участков воздуховода, каждый по 1.2345 фута:

dliny = [1.2345] * 500

# плохо: округлили каждый кусок в мм, потом сложили
a = sum(round(UnitUtils.ConvertFromInternalUnits(d, UnitTypeId.Millimeters))
        for d in dliny)

# правильно: сложили в футах, конвертировали один раз, округлили в конце
b = round(UnitUtils.ConvertFromInternalUnits(sum(dliny), UnitTypeId.Millimeters), 1)

Разница на пятистах элементах набегает в несколько сантиметров, на тысячах — в десятки. В ведомости длин это выглядит как расхождение с моделью, которое невозможно объяснить заказчику.

Второе следствие — сравнение. Два числа с плавающей точкой никогда не сравнивают знаком равенства:

# так нельзя
if dlina_a == dlina_b:
    ...

# так можно: допуск 0,5 мм, переведённый в футы
DOPUSK = 0.5 / 304.8
if abs(dlina_a - dlina_b) < DOPUSK:
    ...

У самого Revit есть встроенный порог: doc.Application.ShortCurveTolerance — примерно 1/256 фута, около 0.8 мм. Короче этого линию он просто не создаст, и попытка кончится исключением.

Локаль: запятая, которая ломает всё

Самый неочевидный баг в русском Revit. AsValueString() на длине вернёт что-то вроде 3 000,00, где разделитель дробной части — запятая, а разделитель тысяч — неразрывный пробел (\xa0).

s = param.AsValueString()          # '3 000,00'
float(s)                           # ValueError: could not convert string to float

Чинится в одну строку, но знать про это надо заранее:

def v_chislo(s):
    if not s:
        return None
    s = s.replace('\xa0', '').replace(' ', '').replace(',', '.')
    s = ''.join(c for c in s if c.isdigit() or c in '.-')
    return float(s) if s else None

Отсюда общее правило обмена: AsValueString годится для того, что человек прочитает глазами. Для расчётов, выгрузок и сверок берётся AsDouble с явной конвертацией. Настройки единиц у соседнего файла могут отличаться, и тогда одна и та же выгрузка в понедельник даст миллиметры, а в среду сантиметры.

Обратная операция — SetValueString("3000") — разбирает строку по настройкам проекта. Удобно, когда значение пришло от пользователя из диалога, а не из расчёта.

Выгрузка в спецификацию

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

stroki = []
for e in UnwrapElement(IN[0]):
    p_dl = e.LookupParameter("Длина")
    p_ob = e.LookupParameter("Объем")
    dlina_mm = UnitUtils.ConvertFromInternalUnits(p_dl.AsDouble(), UnitTypeId.Millimeters) if p_dl else 0
    obem_m3 = UnitUtils.ConvertFromInternalUnits(p_ob.AsDouble(), UnitTypeId.CubicMeters) if p_ob else 0
    stroki.append([
        e.Id.IntegerValue,
        round(dlina_mm, 1),      # мм с одним знаком
        round(obem_m3, 3),       # м³ с тремя
    ])
OUT = stroki

Точность в 0.1 мм и 0.001 м³ покрывает практически любую форму. Больше знаков — таблица становится нечитаемой, меньше — итоги перестают сходиться с моделью.

Как довести такую выгрузку до готовой формы заказчика, расписано в статье про спецификации Revit в Excel.

Проверка себя за минуту

Прежде чем гнать скрипт по всей модели, возьмите один элемент с известным размером. Стену длиной ровно 6000 мм, круглый воздуховод диаметром 200, плиту толщиной 200. Выведите по нему все три величины рядом: сырое значение из AsDouble, результат конвертации и строку из AsValueString.

Дальше сверяете глазами. Сырое 19.685 и конвертированное 6000 при показанных «6000» — цепочка собрана правильно. Конвертированное 19.685 означает, что конвертацию где-то потеряли по дороге. Конвертированное 1828800 — что применили её дважды.

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

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

Где это не поможет

Конвертация не чинит неправильно заданный тип параметра. Если общий параметр создан как «Текст», а туда записывают размеры, никакой UnitUtils не спасёт: там строка, и в ней рано или поздно окажется «3000 (уточнить)».

Не поможет и там, где параметр вычисляемый. Формула в семействе считается по своим правилам, и запись в результат просто не пройдёт: параметр будет помечен как read-only, а Set() выбросит исключение о попытке изменить неизменяемое значение.

Углы отдельная песня. Радианы конвертируются штатно, но поворот 90° внутри семейства и поворот экземпляра в проекте — разные величины, и путать их UnitUtils не мешает.

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

Короткие ответы

Почему AsDouble возвращает 9.84 вместо 3000? Потому что внутренние единицы Revit — футы. 3000 мм / 304.8 = 9.8425. Конвертируйте через UnitUtils.ConvertFromInternalUnits.

Чем AsValueString отличается от AsDouble? Первый отдаёт строку в единицах проекта и годится для показа человеку, второй — число во внутренних единицах и годится для расчётов.

Как узнать, в каких единицах показан параметр? doc.GetUnits().GetFormatOptions(SpecTypeId.Length).GetUnitTypeId() вернёт текущую настройку длины для документа.

Работает ли старый код с DisplayUnitType? В Revit 2020 и раньше да, начиная с 2022 нет. Заменяется на UnitTypeId без изменения остальной логики.

Почему сумма длин не совпадает со спецификацией Revit? Чаще всего из-за раннего округления в скрипте. Складывайте во внутренних единицах, округляйте один раз на выводе.

Что сделать прямо сейчас

Откройте любой свой рабочий граф и найдите в нём число 304.8 или 3.28. Если оно встречается больше одного раза, там уже сидит будущая ошибка — вынесите конвертацию в одну функцию на выходе.

Нужен скрипт, который читает модель и отдаёт цифры в правильных единицах и в вашей форме, — напишите в Telegram или через контакты. Разбор модели и оценка занимают день.

Матрица при этом не украшение для альбома BIM-стандарта, а прямой источник настроек. Каждая заполненная клетка превращается в тест Clash Detective. Ниже — как пройти путь от таблицы в Excel до набора тестов, который переживёт три объекта подряд.

Что такое матрица пересечений

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

Смысл в том, чтобы договориться о правилах до первого прогона. Иначе координатор гоняет тесты по интуиции, и на вопрос «а вентиляцию с пожаротушением проверяли?» честного ответа нет.

Рабочая матрица для жилого дома с подземным паркингом:

Шесть разделов дают пятнадцать пар. Клетку АР × ЭОМ мы обычно закрываем: розетки и выключатели честно сидят в стенах, и тест выдаёт тысячи «конфликтов», которые никто не собирается решать. Остаётся четырнадцать пар плюс четыре теста на зоны обслуживания — восемнадцать тестов, и это нормальный размер для объекта в 40 тысяч квадратов.

Дальше в матрицу дописывают, кто отвечает за клетку и как часто её гоняют. У нас три уровня: критичные пары (КР со всей инженеркой) идут еженедельно, остальные раз в две недели, зоны обслуживания перед выдачей раздела.

Допуски: откуда берутся цифры

Tolerance в Navisworks — это глубина проникновения, при которой конфликт считается конфликтом. При допуске 10 мм труба, зашедшая в стену на 6 мм, в отчёт не попадёт.

10 мм для несущих конструкций. Пересечение с колонной или балкой — всегда дорогая проблема, и мелочиться тут незачем. Ноль ставить нельзя: получите касания по стыкам плит и по общим граням.

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

25 мм между инженерными разделами. Монтажные зазоры между воздуховодом и лотком всё равно закладываются на площадке. Допуск в 5 мм добавит вам двести пунктов, из которых ноль дойдёт до реального решения.

Clearance 600–800 мм для оборудования. Проверка не на пересечение, а на сближение: перед щитом должен быть проход, у приточной установки — место, чтобы вынуть фильтр. Цифры берутся не из головы, а из паспорта оборудования и норм по конкретному помещению.

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

Из матрицы в наборы поиска

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

Home → Sets → Manage Sets → Find Items. Слева дерево файлов, справа условия: Category, Property, Condition, Value.

Только Search Set, не Selection Set. Первый запоминает условие и после Refresh моделей пересобирается сам, второй запоминает конкретные элементы и рассыпается при первой же перевыгрузке. Разница — между «настроил один раз» и «настраиваю каждую неделю».

Минимальный комплект под матрицу выше:

• КР несущие — свойство Structural (Несущие) со значением Да, иначе в набор влезут перегородки;
• АР стены и перекрытия — по категориям, отдельным набором лестницы и пандусы;
• ОВ — воздуховоды плюс отдельный набор «фитинги воздуховодов», их забывают в девяти случаях из десяти;
• ВК — фильтр по параметру «Тип системы», а не по имени семейства: семейства переименовывают, типы систем нет;
• ЭОМ — лотки, короба, шинопроводы;
• Оборудование — по категории «Оборудование» с фильтром по разделу;
• Изоляция — отдельно, зачем, объясню ниже.

Проверка качества набора занимает пять секунд: нажмите Update и посмотрите счётчик элементов внизу окна. Ноль или подозрительно мало — условие бьёт мимо.

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

Тесты по клеткам матрицы

Clash Detective → Add Test. Для каждой заполненной клетки: набор A слева, набор B справа, тип, допуск.

Имя теста — самая недооценённая деталь. Оно попадает в отчёт, и его читает живой инженер. Формат, который у нас прижился: 03_КР x ОВ (Hard 10). Номер держит порядок в списке, разделы читаются с первого взгляда, допуск виден без открытия настроек.

Вкладка Rules внутри теста, три галочки включаются всегда: Items in Same Layer, Items in Same Group/Block/Cell, Items with Coincident Snap Points. Они убирают самопересечения внутри системы — врезки, тройники, отводы. Без них первый прогон по инженерке выдаёт четырёхзначное число и деморализует команду.

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

Батч-прогон

Кнопка, ради которой всё затевалось, живёт внизу списка тестов: Update All. Она прогоняет все тесты по свежей геометрии, сохраняя статусы, комментарии и группировку. Рядом Reset All (сбрасывает результаты, статусы теряются — жать не надо) и Compact All (чистит закрытые пункты).

Порядок еженедельного прогона:

1. Home → Refresh — подтянуть свежие NWC от смежников.
2. Sets → Update по наборам, если менялись условия.
3. Clash Detective → Update All.
4. Пятнадцать минут на просмотр новых пунктов, группировка, статусы.
5. Report по критичным тестам, отправка.

Машинное время на модели в полтора гигабайта — от 20 минут до полутора часов. Ставьте на обед или на ночь: Navisworks во время прогона забирает всю память рабочей станции, параллельно работать не выйдет.

Тесты не пересобирают заново никогда. Правят наборы, жмут Update All, гоняют. Пересборка теста обнуляет всю историю статусов, и в понедельник вы получаете четыреста «новых» коллизий вместо сорока.

Как перенести настройку на следующий проект

Тут и появляется обещанный «один раз». В Clash Detective, справа над списком тестов, есть кнопки импорта и экспорта тестов в XML. Выгрузили с объекта, где всё отлажено, загрузили на новый — получили восемнадцать тестов с допусками и правилами за минуту.

Условие одно: имена наборов должны совпадать. Значит, они пишутся по стандарту и от проекта к проекту не меняются.

Второй способ проще и надёжнее: держать шаблонный NWF. Пустая сборка, в которой уже есть наборы поиска, тесты, правила и настройки отображения. Начинается новый объект — копируете файл, делаете Append свежих NWC, поправляете имена файлов в наборах. Полчаса вместо дня.

Шаблон лежит в CDE рядом с BIM-стандартом, а не на рабочем столе у координатора. Иначе с уходом человека уходит и настройка.

Чего Navisworks не сделает

Он не запускает Clash Detective сам по расписанию. Штатный Batch Utility умеет собирать и публиковать NWD ночью, а прогонять тесты — нет. Настоящая автоматизация тут делается либо через API (.NET-плагин, который открывает NWF, дёргает тесты и пишет отчёт), либо переездом на облачную координацию, где проверка запускается при публикации модели. И то и другое стоит денег или времени разработчика, поэтому в 90% команд живёт ручной Update All раз в неделю. Это нормально.

Он не понимает норм. Расстояние от газовой трубы до кабеля, нормируемый уклон канализации, высота прохода под коробом — ничего этого в матрице не выразить. Clash Detective сравнивает объёмы, а не требования СП.

Он не видит того, чего нет в модели. Зона обслуживания существует, если её нарисовали объёмом. Пустой воздух вокруг щита машина конфликтом не считает.

И матрица не решает организационных проблем. Если раздел ВК публикуется раз в месяц, вы будете еженедельно проверять устаревшую геометрию по всем правилам. Лечится это регламентом обмена, а не настройками, и про это есть отдельный разбор — рабочий процесс clash detection.

Короткие ответы

Сколько тестов нормально для жилого дома? Пятнадцать-двадцать. Меньше восьми — скорее всего, забыли пары. Больше двадцати пяти — прогон не влезает в рабочий день, и часть тестов начинают пропускать.

Можно ли обойтись одним тестом «всё против всего»? Технически да, практически нет. Результаты невозможно распределить по ответственным, а допуск придётся ставить один на все случаи.

Кто утверждает матрицу? BIM-координатор пишет, ГИП утверждает, разделы расписываются, что видели. Без последнего пункта на первом же спорном пересечении начнётся «мы так не договаривались».

Как быть с мягкими коллизиями? Тест типа Clearance с нужным зазором и отдельный статус. Смешивать их с Hard в одном тесте нельзя: приоритет разный, и сроки решения разные.

Что делать, если один тест выдал 800 результатов? Смотреть первые двадцать позиций. Одинаковые — виноват не проект, а системная ошибка: сдвинутый уровень, задвоенная связь, кривой набор.

С чего начать

Нарисуйте матрицу на одну страницу, вычеркните пары, которые точно проверять не будете, и покажите её ГИПу. Дальше три часа на наборы и тесты — и на следующий понедельник у вас появится кнопка вместо ритуала.

Если нужен готовый шаблон под ваш BIM-стандарт, мы собираем такие вместе с наборами, допусками и формой отчёта. Что входит в работу, видно на странице автоматизации проверки моделей.

Опишите объект в Telegram или через контакты — скажем, сколько тестов реально нужно и что можно не проверять вообще.

Это происходит на каждом втором объекте, и причина почти всегда одна из четырёх. Разберём, что Navisworks кладёт в точку обзора, чего не кладёт никогда, и какие две галочки закрывают вопрос за минуту.

Точка обзора не хранит выделение

Начнём с недоразумения, из которого растёт всё остальное. Viewpoint не запоминает выбранные элементы. Ни в 2022, ни в 2024, ни в одной версии до них. Выделение (Selection) существует только в текущей сессии и умирает при переключении на соседнюю точку.

Что точка обзора хранит на самом деле:

• положение камеры, угол поля зрения, тип проекции, режим навигации;
• секущие плоскости, если включено Sectioning;
• скрытые и «обязательные» элементы (Hide / Required) — но только если разрешено сохранять этот атрибут;
• переопределение материала и толщины линий — тоже по разрешению;
• редлайны, теги и комментарии, привязанные к этой точке;
• настройки освещения и режима отображения.

Отсюда правило, которое экономит часы: если получатель должен увидеть две конкретные трубы, их надо не выделять, а фиксировать. Цветом и скрытием остального.

Две галочки в настройках

File → Options → Interface → Viewpoint Defaults. Три чекбокса:

• Save Hide/Required Attributes — сохранять, что было скрыто;
• Override Material — сохранять цветовое переопределение;
• Override Line Thickness — толщину линий, нужна редко.

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

Ловушка в слове Defaults. Настройки применяются к новым точкам, уже созданные они не чинят. Если у вас 34 точки без атрибутов, включение галочек ничего не изменит, придётся пересоздавать. Для одиночной точки есть быстрый путь: правой кнопкой по ней в окне Saved Viewpoints → Edit → блок Saved Attributes, там те же чекбоксы.

Настройки живут в профиле пользователя, а не в файле. Значит, у каждого в команде они свои. Внизу окна Options Editor есть кнопка Export: выгружаете .xml, кладёте в папку проекта, коллеги делают Import. Пять минут один раз за проект.

Правильный маршрут из Clash Detective

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

Шаг 1. Clash Detective → вкладка Results → блок Display Settings. Highlighting: Item 1 красный, Item 2 зелёный, галка Highlight all clashes выключена. Isolation: для передачи наружу лучше Hide Other, а не Dim Other — на затемнённой модели половина мониторов не покажет разницы. Auto-reveal оставляем включённым, он убирает то, что заслоняет конфликт.

Шаг 2. Прокликайте три-четыре результата и убедитесь, что картинка читается. Проверять надо именно сейчас, а не после экспорта.

Шаг 3. Вкладка Report. Report Type — Current test или All tests. Report Format — As Viewpoints. Кнопка Write Report.

В окне Saved Viewpoints (View → Windows → Saved Viewpoints) появится папка с именем теста и по точке на каждый конфликт. Если результатов больше сотни, ставьте Include Clashes = Group headers only, иначе получите папку на 400 позиций, по которой никто не пройдёт.

Пересоздавать отчёт после смены настроек надо с удалением старой папки. Navisworks не перезаписывает точки, а добавляет вторую пачку с теми же именами.

Как выстроить сам процесс проверки до этого шага, разобрано отдельно: проверка коллизий в Navisworks.

Четыре причины, по которым подсветка слетает

Галочки не стояли в момент создания. Самый частый случай, разобран выше. Лечение — включить и написать отчёт заново.

В экспортёре Revit выключен Convert element Ids. Точки ссылаются на элементы по идентификаторам. Перевыгрузили раздел, идентификаторы поехали, привязка порвалась. Внешне это выглядит так: камера на месте, а модель показана целиком, без скрытий и цвета. Галка живёт в диалоге экспорта NWC («Надстройки» → External Tools → Navisworks → Navisworks Settings).

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

Отправили NWF вместо NWD. NWF — это ссылки на исходные NWC весом в килобайты. У получателя этих NWC нет, он открывает пустоту с идеально настроенными камерами. Наружу всегда уходит NWD: Output → Publish, там же ставится дата истечения и пароль, если нужно.

Экспорт в XML и что отдавать смежникам

Output → Export Data → Viewpoints. На выходе XML: камеры, имена, комментарии, редлайны, ссылки на скрытые элементы. Импорт — правой кнопкой по пустому месту в окне Saved Viewpoints → Import Viewpoints.

XML нужен в трёх ситуациях: перенос точек в другую сборку, передача коллеге, у которого своя NWF, и переезд между версиями Navisworks. Приятный побочный эффект — файл текстовый, и массовое переименование точек делается поиском с заменой за минуту вместо получаса кликов.

Что кому отдавать по опыту:

BCF из коробки Navisworks не умеет, нужен плагин вроде BCF Manager или BIMcollab. Если смежники сидят в Revit и ArchiCAD, этот плагин окупается за первую неделю: человек нажимает пункт в списке и оказывается в нужном месте своей модели, а не ищет ось 7 по описанию из письма.

Перенос между версиями

Navisworks не открывает файлы более новых версий. NWD, сохранённый в 2024, в 2022 не откроется, и обходного пути нет. Поэтому на проекте держат одну версию у всех, а не «у кого какая стоит».

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

Свойство Camera → Focal Length при переносе иногда съезжает, если в файле-приёмнике другой тип проекции. Проверяйте первые три точки после импорта, дальше можно доверять.

Порядок, который работает

1. Включить Save Hide/Required Attributes и Override Material до создания первой точки.
2. Выгрузить настройки Options в .xml и раздать команде.
3. Настроить Display Settings в Results, проверить на трёх конфликтах глазами.
4. Написать отчёт As Viewpoints, сгруппировав результаты.
5. Опубликовать NWD, рядом положить XML точек.
6. В письме указать дату прогона и версии моделей.

Шесть пунктов, минут пятнадцать. Без них переписка по коллизиям превращается в уточнение, что именно имел в виду отправитель.

Чего от точек обзора ждать не надо

Они не обновляются вместе с моделью. Геометрию подвинули, камера осталась смотреть в пустое место. Точки по закрытым конфликтам надо чистить, иначе к третьему прогону в папке будет вдвое больше мусора, чем дела.

Они не хранят выделение, и это не лечится настройками. Любой совет из интернета вида «сохрани выделение в viewpoint» описывает то, чего в программе нет. Работает связка: набор поиска для повторяемости, скрытие лишнего и цвет для наглядности.

Цвет привязан к элементам, а не к картинке. После перевыгрузки раздела с новыми идентификаторами он не вернётся сам, точки придётся пересоздать. На активной стадии проще принять это как данность и генерировать точки заново после каждого прогона, а не чинить старые.

Freedom показывает чужие точки, но сохранить свои в нём некуда: он просмотрщик. Если смежник должен отвечать точками, ему нужен Manage или маршрут через BCF.

Что спрашивают чаще всего

Почему точка обзора открывается, а модель серая? Скорее всего, у получателя NWF без исходных NWC. Проверяется мгновенно: если в дереве Selection Tree файлы помечены как недоступные, отправляйте NWD.

Можно ли сохранить выделение элементов в Navisworks? Как выделение — нет. Сохраните элементы в Selection Set или Search Set (Home → Sets), набор переживёт и перезапуск, и перевыгрузку моделей.

Сколько точек обзора отдавать смежнику за раз? Мы стараемся не выходить за 30-40 на письмо. Больше означает, что список не разобран и не сгруппирован, а вместо работы отправлена свалка.

Как перенести точки в новый файл сборки? Output → Export Data → Viewpoints в старом файле, Import Viewpoints в новом. Состав и порядок подключённых моделей должны совпадать, иначе скрытия встанут не на те элементы.

Почему после Refresh точки показывают не то? Модели обновились, идентификаторы элементов изменились. Проверьте, что в экспорте NWC включён Convert element Ids, и пересоздайте отчёт As Viewpoints.

С чего начать

Откройте текущую сборку и загляните в Viewpoint Defaults. Если галочки выключены, вы уже неделями отправляете смежникам камеры без содержания.

Дальше по маршруту: наладить сам цикл разбора коллизий помогает рабочий процесс clash detection, а поставить проверки на поток — автоматизация проверки моделей.

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

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

Замер: без него вы лечите наугад

Прежде чем трогать модель, зафиксируйте четыре числа. Секундомером, честно, на своей машине.

• Время открытия с центрального файла, с обычными настройками.
• Время синхронизации без изменений (пустой Synchronize).
• Переключение между двумя тяжёлыми видами: план этажа и общий 3D.
• Отклик при перемещении стены: сколько ждёте перерисовки.

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

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

Замеряйте не только у себя. Возьмите машину коллеги, у которого «всё летает», и повторите те же четыре пробы. Две колонки цифр рядом сразу показывают, где искать: в файле или в железе с сетью. Мы обычно берём три рабочих места разного возраста, разброс между ними говорит больше любых догадок.

Аудит и предупреждения

Начинаем с открытия файла с включённой галочкой Audit. На большой модели это займёт от 10 до 40 минут, зато Revit проверит и починит внутренние ошибки структуры.

Дальше Manage → Warnings. Список выгружается кнопкой Export в HTML, оттуда удобно считать по типам.

Ориентир по количеству: до 500 предупреждений на крупный раздел это рабочая ситуация, 3-5 тысяч уже влияют на отклик, 15 тысяч означают, что модель никто не чистил ни разу.

В том проекте предупреждений было 6 800. Больше половины оказались дублями элементов после копирования этажей. Чистка заняла три часа и дала около минуты на открытии. Заметно меньше, чем ожидалось, но подсчёты объёмов после этого сошлись с ведомостью.

Purge, но без иллюзий

Manage → Purge Unused, снять и поставить все галочки, выполнить. Повторить два-три раза: после первой чистки освобождаются вложенные типы, которые в первый проход считались используемыми.

Что даёт: на модели, которую чистят регулярно, почти ничего. На модели, которую не чистили два года, файл худеет на 10-20 процентов. Скорость открытия при этом растёт слабо, зато синхронизация становится приятнее.

Осторожно с типами, которые понадобятся позже. Если проект живой, лучше сначала выгрузить список удаляемого и глазами пройтись по нему, а не жать «ОК» вслепую.

Импортированный DWG: тот самый пункт на пять минут

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

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

Как найти: Manage → Purge Unused покажет часть, но надёжнее посмотреть Insert → Manage Links → CAD Formats, а также прогнать спецификацию по категории «Импортированные символы». В диспетчере проекта импортированные категории видны в настройках видимости (VV → Imported Categories): если там перечислены слои чужих чертежей, они у вас в модели.

Что делать: чистить семейства по одному, вставлять их заново без подложки. Работы на несколько часов, эффект в том проекте составил пять минут из восьми и 500 МБ веса.

Отдельный запрет, который стоит прописать в стандарте компании: никогда не делать Explode импортированному DWG. Разбитый чертёж превращается в тысячи линий стилей, которые расползаются по всей модели и не вычищаются потом ничем.

Связи и рабочие наборы

Каждая связанная модель загружается в память целиком. Если в АР подгружены КР, ОВ, ВК, ЭОМ и топосъёмка, вы держите открытыми шесть моделей сразу.

Что помогает:

1. Разложить связи по отдельным рабочим наборам, по одному на связь. Тогда каждый инженер открывает файл, отключая чужие разделы.
2. Открывать через Open → Specify, снимая галочки с ненужных наборов. На нашей практике это самая быстрая победа: минус 2-4 минуты на открытии, без единой правки в модели.
3. Ставить связям тип Overlay вместо Attachment, чтобы они не тянулись каскадом через чужие файлы.
4. Держать топосъёмку и генплан отдельной связью, которая выгружается на время работы по этажам.

Рабочие наборы сами по себе модель не ускоряют. Ускоряет привычка не загружать то, что сейчас не нужно.

Виды, шаблоны и мелочи

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

• Тени и полутени в 3D съедают отклик заметнее всего. Выключите и почувствуйте разницу за секунду.
• Уровень детализации Fine на общем виде здания не нужен никому.
• Открытые окна видов: Revit пересчитывает все. Держите одно-два, закрывайте остальные (WT и WC в помощь).
• Неиспользуемые виды и листы: сотни забытых видов в диспетчере ощутимо тормозят открытие и синхронизацию.
• Шаблоны видов на все рабочие виды: заодно избавляют от ручных настроек и лишних переключений.
• Модели на месте (In-Place) вместо семейств: тяжёлые, плохо чистятся, множатся. Переводите в загружаемые семейства при первой возможности.

Три жалобы и что за ними стоит

«У меня открывается 11 минут, у соседа 3».

Дело не в модели. Смотрим локальный кеш, антивирус и путь к центральному файлу. Скопируйте файл на локальный диск и замерьте открытие оттуда. Разница в разы означает сеть или проверку rvt антивирусом на лету.

«Синхронизация занимает 15 минут».

Обычно виноваты три вещи сразу: тысячи предупреждений, гора мелких правок за один сеанс и синхронизация всей командой одновременно. Синхронизируйтесь чаще и вразнобой, раз в 30-40 минут, а не раз в день перед уходом.

«Revit падает при открытии общего 3D».

Тени, высокая детализация и все связи разом. Заведите рабочий 3D-вид: тени выключены, детализация средняя, связи отключены через рабочие наборы. Падения обычно прекращаются в тот же день.

Прежде чем звать айтишников

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

Четыре проверки закрывают большинство обращений «Revit тормозит» без единой правки в модели.

Гигиена: двадцать минут раз в месяц

• Выгрузить список предупреждений и посчитать по типам. Растёт число дублей, значит этажи копируют без проверки.
• Посмотреть вес файла в динамике. Скачок на 200 МБ за месяц означает, что в модель что-то приехало.
• Пробежать Manage Links: не появились ли новые импорты CAD и лишние связи.
• Проверить диспетчер проекта на виды без шаблона и на дубли листов.

Четыре пункта, двадцать минут. Модель, которую так смотрят, не превращается в полтора гигабайта за год работы.

Поставьте напоминание на первый рабочий день месяца. Без напоминания процедура умирает на втором месяце, проверено не на одной команде.

Что оказалось мифом

«Compact Central File каждый день». Сжатие центрального файла делает синхронизацию заметно дольше, а даёт немного. Раз в месяц достаточно.

«Купим больше оперативки». На 32 ГБ переход к 64 ГБ обычно не меняет ничего: на большинстве операций Revit упирается в одно ядро и в скорость диска. Быстрый процессор с высокой частотой и NVMe помогают сильнее.

«Разобьём модель на файлы». Иногда правильный ход, но связи тоже стоят памяти и времени. Дробление ради дробления даёт шесть тормозящих файлов вместо одного. Делить стоит по границам ответственности, а не по весу.

«Обновим Revit до свежей версии». Разница между соседними версиями измеряется процентами. Модель на 1,4 ГБ с шестью тысячами предупреждений будет тормозить в любой.

«Отключим аппаратное ускорение». Помогает в редких случаях с конкретными видеокартами, чаще делает хуже. Проверять только по замеру, не по совету из форума.

Итог по замерам

Как распределился выигрыш на том проекте.

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

Где это не сработает

Модель бывает тяжёлой по существу. Комплекс на 120 тысяч квадратных метров в одном файле, генплан с рельефом на 40 гектаров, фасад со сложной параметрикой: там не чистить надо, а перекраивать структуру файлов. Это отдельная работа на неделю с пересборкой связей и координат.

Не поможет чистка и при узком канале. Центральный файл на сервере при сети 100 Мбит и десяти синхронизациях в час создаёт очередь, которую не лечат настройками Revit. Проверяется просто: скопируйте файл на локальный диск и замерьте открытие оттуда. Разница в разы означает, что проблема в сети, а не в модели.

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

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

Частые вопросы коротко

Какой вес модели считать нормальным? Раздел АР жилого дома живёт в 300-600 МБ. Гигабайт и выше почти всегда означает мусор внутри, а не сложность объекта.

Делить модель по этажам? Редко хорошая мысль. Делите по разделам и корпусам, а этажи держите вместе: разрезы и фасады через связи собирать больно.

SSD решит проблему? Ускорит открытие и сохранение, отклик при работе почти не изменит. Порядок вложений такой: частота процессора, потом диск, потом память.

Что делать с тяжёлыми моделями подрядчика? Не чинить их руками каждый месяц. Прописать требования к передаваемым моделям и проверять на входе, возвращая файл при нарушении.

Сколько времени занимает полная чистка? Один-два рабочих дня на раздел, если модель запущена. Половина уходит на семейства с импортами, их правят по одному.

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

Что сделать на этой неделе

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

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

Напишите в Telegram или через контакты, скажите вес модели и время открытия. Подскажем, что смотреть первым, даже если дальше вы будете делать это сами.

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

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

Способ 1. Встроенный экспорт

Открываем спецификацию, «Файл» → «Экспорт» → «Отчёты» → «Спецификация». Revit предлагает сохранить .txt, спрашивает про разделители и заголовки.

Дальше файл открывается в Excel через «Данные» → «Из текста», с указанием кодировки. Именно тут ломается кириллица. Revit пишет UTF-16, Excel по умолчанию ждёт что-то другое, на выходе вместо «Дверь ДГ 21-9» получается набор вопросительных знаков. Лечится выбором Unicode при импорте, но каждый раз вручную.

Что ещё теряется:

• многоуровневая группировка превращается в обычные строки, вложенность видна только по отступам;
• итоги и промежуточные суммы приезжают как текстовые строки посреди таблицы;
• форматирование чисел уходит целиком, «2 100» становится текстом с неразрывным пробелом;
• обратной загрузки нет вообще, это односторонний путь.

Время: 2 минуты на выгрузку плюс 5 на приведение таблицы в вид, который не стыдно отправить. Цена: ноль. Годится, когда нужно один раз что-то отдать смежникам и забыть.

Способ 2. Dynamo

Здесь начинается управляемость. Граф собирает элементы по категории, читает параметры и пишет их в лист Excel в нужном вам порядке.

Минимальный набор нод: Categories → All Elements of Category → Element.GetParameterValueByName → List.Transpose → Data.ExportExcel. Транспонирование почти всегда обязательно: Dynamo собирает данные колонками, а Excel ждёт строки.

# Что делает граф, на языке человека
элементы = все двери проекта
для каждой двери:
    строка = [Марка, Ширина, Высота, Уровень, Комментарий]
записать строки на лист "Двери" начиная с ячейки A2

Три подводных камня, о которых узнаёшь на второй раз.

Data.ExportExcel требует установленного Excel. Нода работает через COM, то есть реально открывает приложение в фоне. На машине без офиса граф падает. На 6000 строк выгрузка занимала у меня около трёх минут, и всё это время Excel лучше не трогать. Альтернатива: Data.ExportCSV, работает мгновенно и без офиса, но теряет типы данных и требует правильного разделителя.

Единицы. Длины Revit хранит во внутренних единицах (футы). Часть нод отдаёт значения уже пересчитанными в единицы проекта, часть нет. Проверка одна: выгрузите три двери и сверьте ширину с тем, что видно в свойствах. Если вместо 900 стоит 2.95, вы смотрите на футы.

Пустые параметры. Ноды возвращают null, и Excel получает пустые ячейки без предупреждения. Незаполненный параметр в модели и ошибка чтения параметра выглядят в выгрузке одинаково.

Время: первый граф собирается за 2-4 часа, дальше запуск за минуту. Цена: ваше время. Плюс в том, что тот же граф умеет читать Excel обратно нодой Data.ImportExcel.

Способ 3. Плагины

Готовые инструменты закрывают обе стороны обмена. Из бесплатного я использовал SheetLink от DiRoots: ставится за 5 минут, поддерживает Revit 2019-2024, выгружает выбранные категории и параметры в .xlsx и загружает их обратно. Из платного известен Ideate BIMLink, он умнее и дороже, лицензия считается на рабочее место.

Что даёт плагин против самописного графа:

• сохраняет служебный столбец с ElementId, по нему и находит элементы при обратной загрузке;
• показывает список изменений до применения, а не после;
• умеет отсеивать read-only параметры, вместо того чтобы падать на них.

Что не даёт: гибкости. Нужна выгрузка со сложной логикой (посчитать площадь отделки по помещениям с учётом типа стен и вычесть проёмы) - плагин так не умеет, там нужен Dynamo.

Сравнение

Обратная загрузка: где рвётся

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

Якорь. Элемент ищется по ElementId. Уникальный номер в пределах файла, но не между файлами и не после пересоздания элемента. Удалили дверь и поставили заново - id новый, а в таблице старый. Загрузка либо промахнётся, либо запишет параметры не туда. Правило простое: между выгрузкой и загрузкой модель не меняем.

Excel-самодеятельность. Артикул 007 превращается в 7. Значение 1.5 в русской локали иногда становится датой. Длинный код спецификации сворачивается в 1,2E+11. Всё это Excel делает сам, без спроса, и в модель приезжает мусор. Формат колонок ставьте текстовым до того, как отдадите файл смежнику.

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

Read-only. Площадь, объём, периметр, отметки уровня считает сам Revit. Запись в них падает с ошибкой, и хорошо, если падает громко. Хуже, когда скрипт ловит исключение и молча идёт дальше: половина строк записалась, половина нет, а сообщения об этом нет.

Синхронизация. Если файл в общей работе, все правки уходят в вашу локальную копию. Не синхронизировали до перезаписи - готовьтесь разбирать конфликты вручную.

Чек-лист перед обратной загрузкой

Список короткий, но каждый пункт написан после того, как что-то пошло не так.

1. Копия файла сделана и лежит рядом. Не «есть бэкап где-то на сервере», а копия за минуту до загрузки.
2. Модель синхронизирована, чужих незакрытых правок в ней нет.
3. Столбец с ElementId цел, не отсортирован отдельно от остальных, не содержит пустых ячеек.
4. Колонки с артикулами и кодами имеют текстовый формат.
5. Загружаются только те колонки, которые правил смежник. Остальные из файла лучше убрать физически.
6. Первый прогон делается на выборке из 10 строк. Смотрим глазами в модели, потом пускаем целиком.

На объекте с 1200 элементами инженерных систем этот круг занимает у меня минут двадцать против трёх часов ручного ввода. Единственный раз, когда я пропустил пункт про копию, стоил половины дня на восстановление разделов из архива. Больше не пропускаю.

Чего ждать не надо

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

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

И отдельно: не отдавайте боевую выгрузку без служебного столбца. Смежник добавит строку, отсортирует по-своему, удалит колонку с id, и обратная загрузка станет невозможной. Столбец id должен быть первым, заблокированным и подписанным «не трогать».

Три ошибки обмена и что с ними делать

«Warning: Data.ExportExcel operation failed. The RPC server is unavailable.»

Классика Dynamo. Нода не смогла достучаться до Excel через COM. Причины по убыванию частоты: файл, в который пишем, открыт в самом Excel; Excel в момент запуска показывает диалог активации лицензии; на машине стоит только просмотрщик, а не полный офис. Первое лечится закрытием файла, третье не лечится вообще, там нужен Data.ExportCSV.

«The process cannot access the file because it is being used by another process.»

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

«Warning: Element.SetParameterByName operation failed. The parameter storage type is not a number.»

Обратная загрузка. Excel отдал строку "2100" вместо числа 2100, потому что колонка была текстовой. Между Data.ImportExcel и записью ставьте String.ToNumber, а перед ним List.Clean для отсева пустых ячеек. Проверяется одним взглядом на превью ноды: числа выравниваются иначе, чем строки.

Ещё одна беда без единого сообщения об ошибке: строки съехали на одну. Заголовок таблицы посчитали данными, и все 400 значений записались соседним элементам. Ошибок нет, скрипт доволен, модель испорчена. Поэтому в графе указывают явное смещение (читать с ячейки A2) и всегда проверяют первое и последнее значение вручную.

Какой формат выбирать

Все спецификации разом

Отдельный сценарий, который окупается быстрее прочих. Ноды All Elements of Type с типом ViewSchedule собирают все спецификации проекта, дальше цикл выгружает каждую на свой лист одной книги. Имя листа берётся из имени спецификации, только помните про ограничение Excel: 31 символ и запрет на символы \ / ? * [ ]. Спецификация «Ведомость перемычек (секция 1/2)» уронит граф именно на слэше.

На разделе из 34 спецификаций такая выгрузка идёт четыре минуты. Руками это полтора часа кликов, и обычно к тридцатой вкладке кто-нибудь ошибается с именем.

Короткие ответы на частые вопросы

Можно ли выгрузить спецификацию из связанной модели? Данные читаются, сама спецификация нет. Собираете элементы связи через Document.Elements для нужного экземпляра связи и строите таблицу в Dynamo с нуля.

Почему в Excel числа стали текстом с зелёным уголком? Revit отдал значение вместе с единицами измерения («2100 мм»). Разделяйте значение и единицы ещё в графе, иначе сумма в Excel не посчитается.

Google Таблицы вместо Excel? Работают, но только через .csv и ручную загрузку. Прямой ноды нет, обмен через API гуглов делается python-скриптом и требует ключа сервисного аккаунта. Для одного отдела овчинка обычно не стоит выделки.

Обязательно ли платить за плагин? Нет. Бесплатного SheetLink хватает 90% команд. Платные инструменты берут за пакетную обработку нескольких файлов и за поддержку, а не за саму функцию обмена.

С чего начать

На пробу возьмите одну категорию и три параметра. Выгрузите, поправьте одно значение, загрузите обратно на копии файла. Пройдёте этот круг без потерь - масштабируйте на реальный объём.

Если данных много и они регулярно нужны за пределами Revit, обмен через Excel быстро упирается в потолок. Дальше начинается хранение атрибутов в базе: как это устроено, показано в разборе Revit и PostgreSQL. Промежуточный вариант, когда выгрузки нужны каждому в команде, разобран в статье про Dynamo Player.

Опишите свою выгрузку в Telegram или через форму на странице контактов: скажем честно, хватит ли бесплатного плагина или под вашу логику нужен скрипт. Что делаем на таких задачах, коротко есть в услугах.

Скрипт закрывает то же самое за минуту. Но перед тем как его писать, надо разобраться, куда именно вы собираетесь писать. Половина неудач с автозаполнением случается не в скрипте, а в непонимании устройства параметров.

Три вида параметров и почему это важно

В Revit параметр живёт в одном из мест, и от этого зависит, что произойдёт при записи.

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

Параметр типа. Значение общее для всех элементов этого типа. Модель двери, материал сердцевины, огнестойкость. Записали значение через один экземпляр - изменились все двери этого типа в проекте. На объекте, где типов 12, а дверей 400, промах в одну строчку правит треть модели. Это самая дорогая ошибка в теме автозаполнения.

Общий параметр (shared). Хранится не в файле, а в отдельном текстовом файле ФОП с уникальными GUID. Только общие параметры попадают в спецификации, марки и IFC-выгрузку корректно. Ключевое свойство: два параметра с одинаковым именем, но из разных ФОП, для Revit разные. Именно поэтому в проекте иногда живут «Обозначение» и «Обозначение», и заполняется не то.

Проектный параметр (project) занимает промежуточную позицию: живёт в файле, привязан к категориям, в марку не попадёт.

Перед первым скриптом ответьте на два вопроса: параметр экземпляра или типа, и общий или проектный. Ответ смотрится в «Управление» → «Параметры проекта».

Что заполняется автоматически хорошо

Не всё стоит автоматизировать. Годятся случаи, где значение выводится из чего-то, что уже есть в модели:

• обозначение по шаблону из марки типа, уровня и порядкового номера;
• «Помещение» у оборудования, вычисленное по геометрии (в какой комнате стоит точка вставки);
• код по классификатору, подставленный из соответствия «семейство → код»;
• этажность, секция, стадия, подсистема: всё, что определяется положением элемента;
• зачистка мусора: убрать двойные пробелы, привести регистр, обрезать лишние символы.

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

Скрипт: сбор, вычисление, запись

Структура любого графа автозаполнения одинакова. Три части.

Сбор. Categories → All Elements of Category. Если нужны элементы только с активного вида, берите All Elements of Category in View: на большой модели разница во времени в разы.

Вычисление. Читаем исходные параметры через Element.GetParameterValueByName, склеиваем в Code Block. Пример формулы обозначения:

марка + "-" + этаж + "-" + String.PadLeft(number, 3, "0");

Дальше это уходит в один вход, а список элементов в другой.

Запись. Element.SetParameterByName. Три входа: элемент, имя параметра строкой, значение. Порядок и длина списков должны совпадать. Если элементов 340, а значений 339, лейсинг Shortest тихо обработает 339, и вы этого не заметите.

Полезный кусок на Python внутри Dynamo, когда нужно писать только в пустые поля и не трогать заполненные:

import clr
clr.AddReference("RevitAPI")
clr.AddReference("RevitServices")
from Autodesk.Revit.DB import *
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager

doc = DocumentManager.Instance.CurrentDBDocument
elems = UnwrapElement(IN[0])
pname = IN[1]
values = IN[2]

TransactionManager.Instance.EnsureInTransaction(doc)
tronuli = 0
for e, v in zip(elems, values):
    p = e.LookupParameter(pname)
    if p is None or p.IsReadOnly:
        continue
    if p.AsString():          # уже заполнено - пропускаем
        continue
    p.Set(str(v))
    tronuli += 1
TransactionManager.Instance.TransactionTaskDone()

OUT = tronuli

Возврат количества обработанных элементов - привычка, которая экономит нервы. Запустили, увидели «307», сравнили с ожидаемыми 340, пошли искать разницу. Без счётчика скрипт молчит, и вы верите, что всё прошло.

Единицы, типы и прочие мелочи

Строковый параметр принимает строку, числовой число, длина хранится во внутренних футах. Запись 1000 в параметр длины через API даёт 1000 футов, то есть 304 метра. Революции в модели не будет, но геометрия уедет.

Проверяйте на одном элементе. Всегда. Записали, открыли свойства, посмотрели глазами. Только после этого пускайте на все 340.

Параметр Yes/No ждёт 0 или 1. Параметр-материал ждёт ElementId материала, а не его название. Параметр типа «Текст» проглотит что угодно, включая случайно попавший null, который превратится в строку «null» и потом всплывёт в спецификации.

Проверка результата

Скрипт отработал. Дальше три уровня контроля, по возрастанию надёжности.

Первый: спецификация с фильтром «параметр не заполнен». Ставится один раз, живёт в шаблоне, показывает пустые поля моментально. Держите такую в каждом проекте.

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

Третий: обратный прогон. Собрать значения тем же графом и проверить List.UniqueItems и List.Count. Обозначения должны быть уникальны, коды - принадлежать заранее известному множеству. Расхождение говорит о том, что скрипт где-то ошибся или кто-то поправил руками.

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

Где это не работает

Read-only параметры. Площадь, объём, периметр, длина стены, отметки. Их считает Revit по геометрии, запись невозможна. Скрипт либо упадёт, либо пропустит, в зависимости от того, как написан.

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

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

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

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

Три ошибки записи, разобранные по шагам

«Warning: Element.SetParameterByName operation failed. The parameter is read-only.»

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

«Warning: Element.SetParameterByName operation failed. The parameter storage type is not a string.»

Тип значения не совпал с типом параметра. Пытаетесь записать текст в числовое поле или наоборот. В Dynamo это лечится нодами String.ToNumber и String from Object, в python - явным str() или float(). Отдельный случай: параметр Yes/No ждёт 1 или 0, а не «Да».

Записалось, а в спецификации пусто.

Ошибок нет, значения в свойствах элемента видны, спецификация показывает пустую колонку. Почти всегда причина одна: в проекте два параметра с одинаковым именем. Один проектный, другой общий из ФОП, и спецификация выводит не тот, в который вы записали. Проверяется в «Управление» → «Параметры проекта»: если в списке два «Обозначения», вы нашли виновника. Чинится удалением лишнего и повторным прогоном, но сначала убедитесь, что удаляемый параметр нигде не выводится в марках.

Четвёртая по счёту, но первая по ущербу ситуация: скрипт отработал на 400 элементах вместо 40. Фильтр собрал не ту категорию, лейсинг растянул значение на весь список, вложенные семейства попали в выборку. Отсюда правило про счётчик обработанных элементов и первый прогон в режиме отчёта.

Куда писать: сравнение

Что проверить перед массовым прогоном

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

Короткие ответы на частые вопросы

Можно ли заполнить параметр без скриптов вообще? Да, и это недооценённый путь. Ключевая спецификация (Key Schedule) заполняет пачку параметров по одному ключевому полю: выбрали в выпадающем списке «Тип отделки 3», и три параметра проставились сами. Настраивается за полчаса, не ломается при обновлении Revit, работает у всех без Dynamo. Логику вычислений она не потянет, но для справочников подходит лучше скрипта.

Как заполнить параметры у элементов связанной модели? Никак. Чужой файл открыт на чтение. Работать можно только с копией связи, вставленной в свой проект, или запрашивать правку у автора модели.

Отменяется ли массовая запись? Ctrl+Z откатывает весь прогон одним шагом, пока вы не сделали в Revit других действий. После синхронизации откат превращается в отдельную работу с архивом.

Что быстрее на 3000 элементов: Dynamo или python внутри него? Python. Ноды тратят время на обёртки и превью, чистый цикл через Revit API проходит те же элементы в несколько раз быстрее. На тысяче элементов разница незаметна, на десятках тысяч ощутима.

Что делать дальше

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

Не собирали графов раньше - начните с пошагового разбора первого скрипта, там подробно про ноды, порты и уровни списков. Если значения приходят из внешней таблицы, посмотрите разбор обмена с Excel. Когда скрипт готов и им хочет пользоваться вся команда, дальше по маршруту Dynamo Player.

Не уверены, куда именно писать в вашей схеме параметров, или в проекте уже два «Обозначения» из разных ФОП? Напишите в Telegram или через форму на странице контактов, разберём структуру. Наведение порядка в параметрах и шаблонах есть в списке услуг.

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

Почему встречи глохнут у большинства

Причин обычно четыре, и все организационные.

Обсуждают, а не решают. Половина времени уходит на «а почему у вас труба здесь». Виноватого ищут, решение не записывают.

У пункта нет хозяина. Коллизия числится за разделом ОВ и разделом КР одновременно. Оба ждут другого.

Нет письменного следа. Договорились устно, через две недели у каждого своя версия договорённости.

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

Добавьте к этому отчёт на 214 позиций, который никто не открывал до встречи, и получите ритуал вместо работы.

Частота: привязать к циклу выпуска

Универсального интервала нет, есть привязка к стадии.

• Стадия «П», активная разработка: раз в две недели, 60 минут.
• Стадия «Р», основной объём: еженедельно, 45 минут.
• За три недели до выдачи комплекта: дважды в неделю, 30 минут, только критичное.
• После выдачи: раз в месяц, контроль изменений.

Важнее интервала предсказуемость. Вторник, 10:00, каждую неделю, в календаре у всех, без переносов. Как только встреча начинает плавать по дням, посещаемость падает за месяц.

Отдельно фиксируем срок публикации моделей: пятница до 17:00. Координатор берёт модели в субботу, проверяет, рассылает отчёт в понедельник до обеда. Ко вторнику у людей есть сутки посмотреть свои пункты.

Кто нужен на встрече

Оптимальный состав: пять-семь человек.

От раздела приходит один человек, который отвечает за раздел. Не два, не «а можно я послушаю». Слушатели растягивают встречу вдвое.

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

Что происходит до встречи

Половина результата делается координатором заранее.

1. Прогон проверки по настроенным наборам и тестам. Механика подробно разобрана в статье про проверку коллизий в Navisworks.
2. Чистка ложных срабатываний. На встречу не выносится ни одного пункта, который координатор не посмотрел глазами.
3. Группировка. Двенадцать пересечений одного стояка это один пункт повестки.
4. Назначение по разделам и рассылка за 24 часа до встречи.
5. Повестка: 15-20 пунктов, не больше. Отсортированы по стоимости ошибки, а не по номеру.

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

Как идёт сама встреча

Жёсткий тайминг: три минуты на пункт. Экран показывает координатор, модель уже открыта на нужном ракурсе.

По каждому пункту произносится и записывается одно предложение: кто, что делает, к какой дате. «ОВ опускает короб на отметку 2,95, до 19.05». Формулировки вида «посмотрим», «уточним», «постараемся» в протокол не попадают, вместо них назначается дата следующего разговора.

Если решение требует расчёта или согласования с заказчиком, пункт получает статус «эскалация» и уходит к ГИПу с датой. Спорить об этом на встрече дольше трёх минут смысла нет.

Ещё одно правило, которое экономит часы: не открываем Revit во время встречи. Соблазн «сейчас поправим» ломает тайминг и превращает встречу в чужую рабочую сессию.

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

Камеры включать необязательно. Разговор идёт по модели на экране, лица тут ничего не добавляют, зато канал забивают.

Повестка на 45 минут, по минутам

• 0-3: цифры прошлой недели. Сколько новых, сколько закрытых, сколько просрочено. Без обсуждения.
• 3-8: просроченное. По каждому пункту одна фраза о причине задержки.
• 8-35: разбор. Восемь-десять пунктов по три минуты.
• 35-40: эскалации. ГИП заходит именно на этот отрезок.
• 40-45: кто что делает до следующей встречи. Вслух, по кругу.

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

Статусы и кто закрывает пункт

Ключевой вопрос всего регламента: кто имеет право сказать «решено». Ответ один: не автор правки.

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

Статус «согласован» без текстового обоснования не принимается. Через полгода на стройке спросят, почему труба идёт в 40 мм от балки, и ответ должен быть в файле, а не в чьей-то памяти.

Протокол на одном экране

Длинные протоколы не читают. Формат, который работает:

• Дата, версии моделей по разделам, число открытых пунктов и динамика к прошлой неделе.
• Таблица решений: пункт, решение одной строкой, ответственный, срок.
• Список эскалаций для ГИПа.
• Три строки «риски»: что не решено и чем это грозит на монтаже.

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

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

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

Три протокола, которые не работают

Протокол-стенограмма. Шесть страниц пересказа, кто что сказал и как ответил. Читателей ноль. Лечится жёстким шаблоном: только решения, ответственные, даты.

Протокол без дат. Строка «ОВ поправит короб» без числа означает «когда-нибудь». Дата ставится всегда, пусть даже приблизительная. Сдвинутый срок обсуждаем, отсутствующий срок обсудить невозможно.

Протокол в личной переписке. Ушёл в чат, утонул за сутки под мемами и вопросами по зарплате. Место хранения одно и постоянное, рядом с моделями и отчётом.

Чек-лист координатора за сутки до встречи

• Модели всех разделов свежие, дата публикации по каждому известна.
• Прогон сделан, ложные срабатывания вычищены руками.
• Повестка разослана, у каждого пункта назван раздел-получатель.
• Прошлый протокол открыт, просроченные пункты подсвечены.
• Спорные пункты предупреждены отдельным сообщением: «на встрече спросим вас».

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

Если участник не приходит

Разбираем по причине, а не по эмоциям.

Пропустил один раз: пункты его раздела остаются открытыми, в протоколе строка «решение не принято, ответственный отсутствовал». Две такие строки подряд, и вопрос уходит к ГИПу.

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

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

По времени регламент стоит примерно столько: координатору 6-8 часов в неделю на прогон, чистку, повестку и протокол, ответственному по разделу час на встречу плюс 2-4 часа на правки. На объекте в 15 тысяч квадратных метров это укладывается в десятую часть рабочего времени команды. Выходит вдвое больше, значит на встречу тащат то, что решается перепиской.

Где регламент не поможет

Он не работает, когда у координатора нет полномочий. Если ответственный по разделу может просто не прийти и ему за это ничего не будет, никакая процедура не спасёт. Полномочия даёт ГИП или руководитель, и это решение принимается один раз, до старта.

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

Мелкому проекту тяжёлая процедура вредна. Пристройка на 800 квадратных метров с тремя разделами прекрасно координируется перепиской и одним звонком. Регламент со статусами начинает окупаться примерно от 8-10 тысяч квадратных метров или от пяти разделов.

И последнее. Если в компании принято «решим на стройке», координация будет буксовать, сколько бы встреч вы ни назначили. Здесь помогает не регламент, а посчитанная стоимость переделок по паре прошлых объектов. Цифры меняют позицию быстрее уговоров.

Вопросы, которые задают на внедрении

Свой координатор или внешний? До двух-трёх параллельных объектов дешевле внешний: своему нужна полная загрузка и обучение. От четырёх объектов выгоднее держать человека внутри.

ГИП не ходит на встречи, что делать? Не звать его на всю встречу. Пять минут в конце по списку эскалаций, с вопросами, на которые отвечают «да» или «нет».

У нас есть BCF, зачем ещё протокол? BCF хранит замечания, протокол хранит решения и сроки. Первое читает инженер в модели, второе читает руководитель в переписке. Дублирования тут нет.

Как считать, что координация окупилась? Возьмите число переделок на монтаже по прошлому объекту и умножьте на среднюю стоимость одной. Через полгода сравните с новым числом. Другой честной метрики мы не нашли.

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

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

С чего начать

Возьмите ближайшую встречу и сделайте три вещи: сократите состав до одного человека от раздела, разошлите повестку из 15 пунктов за сутки, запишите решения формулой «кто, что, к какой дате». Этого достаточно, чтобы через месяц увидеть разницу в числе открытых пунктов.

Дальше добавляйте статусы и правило перепроверки перед закрытием.

Мы настраиваем такой цикл под конкретную команду и ведём его первые два-три месяца, пока он не станет привычкой. Что входит в сопровождение, видно на странице BIM-координации.

Напишите в Telegram или через контакты, опишите проект и состав разделов. Скажем, какой ритм встреч выдержит ваша команда и с чего начинать.

pyRevit ровно про это. Бесплатный, открытый, ставится за 10 минут, кнопки делаются папками и файлами. Компилировать ничего не нужно, Visual Studio не нужен, C# не нужен. Вечера хватает на установку, три рабочие кнопки и раздачу их команде.

Установка

Идём на github.com/pyrevitlabs/pyRevit, в разделе Releases берём подписанный установщик последней стабильной версии ветки 4.8. Он поддерживает Revit с 2019 по 2025, включая нужные нам 2022, 2023 и 2024.

Ставится в две минуты. Установщик сам находит установленные Revit и подцепляется к ним. Открываем Revit: на ленте появилась вкладка pyRevit с полусотней готовых инструментов от сообщества. Уже ради них стоит поставить: там и поиск элементов по id, и сравнение моделей, и массовое переименование видов.

Что проверить сразу:

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

Ставить лучше «для текущего пользователя», без прав администратора. На машинах в организациях это обычно единственный способ поставить что-то самому.

Как устроено расширение

Вся структура интерфейса - это папки с говорящими окончаниями. Никакого XML, никакой регистрации.

MyTools.extension\
    Отдел.tab\
        Проверки.panel\
            Пустые номера.pushbutton\
                script.py
                icon.png
            Дубли марок.pushbutton\
                script.py
                icon.png
        Выгрузки.panel\
            Ведомость дверей.pushbutton\
                script.py

Читается так: расширение → вкладка на ленте → панель внутри вкладки → кнопка внутри панели. Имя папки становится подписью, script.py - тем, что выполнится по нажатию, icon.png - картинкой (png 96 на 96, прозрачный фон).

Кроме pushbutton есть pulldown (выпадающий список кнопок), splitbutton, stack (три мелкие кнопки в столбик), smartbutton. На первом вечере они не нужны.

Папку расширения кладём куда-нибудь, где её не снесёт: C:\pyRevitExt\ или сразу на сетевой диск. Дальше в Revit: вкладка pyRevit → Settings → Custom Extension Directories → добавляем путь. Reload, и ваша вкладка на ленте.

Первый скрипт

Классическая первая задача: найти помещения с пустым номером и показать их списком, по которому можно кликнуть.

# -*- coding: utf-8 -*-
__title__ = "Пустые\nномера"
__doc__ = "Показывает помещения без заполненного номера. Модель не меняет."

from pyrevit import revit, DB, script

doc = revit.doc
out = script.get_output()

rooms = DB.FilteredElementCollector(doc) \
    .OfCategory(DB.BuiltInCategory.OST_Rooms) \
    .WhereElementIsNotElementType() \
    .ToElements()

pustye = []
for r in rooms:
    nomer = r.get_Parameter(DB.BuiltInParameter.ROOM_NUMBER).AsString()
    if not nomer or not nomer.strip():
        pustye.append(r)

out.print_md("## Помещений без номера: {}".format(len(pustye)))
for r in pustye:
    imya = r.get_Parameter(DB.BuiltInParameter.ROOM_NAME).AsString()
    out.print_md("- {} {}".format(imya, out.linkify(r.Id)))

Сохранили, нажали Reload на вкладке pyRevit, нажали свою кнопку. В окне вывода список помещений, и каждая строка кликабельна: клик выделяет элемент в модели. Это linkify, одна из вещей, ради которых стоит писать на pyRevit, а не собирать граф.

Разбор по строчкам:

• __title__ с \n переносит подпись на две строки, иначе кнопка растянется на пол-панели;
• __doc__ становится всплывающей подсказкой, туда пишите, меняет ли скрипт модель;
• revit.doc - текущий документ, не надо доставать его из uiapp вручную;
• FilteredElementCollector - штатный способ собрать элементы через Revit API, работает быстрее переборов;
• script.get_output() даёт окно с поддержкой markdown, таблиц и ссылок.

Запись в модель оборачивается в транзакцию:

with revit.Transaction("Заполнить номера"):
    for r in pustye:
        r.get_Parameter(DB.BuiltInParameter.ROOM_NUMBER).Set("б/н")

Забыли транзакцию - Revit выбросит исключение о запрете модификации вне транзакции. Открыли и не закрыли - получите повисшую транзакцию и «залипшую» модель. Конструкция with закрывает её сама, в том числе при ошибке.

Диалоги за две строки

Модуль forms закрывает всё, ради чего в Dynamo приходится изворачиваться.

from pyrevit import forms

variant = forms.SelectFromList.show(
    ["Все помещения", "Только активный вид"],
    title="Что обрабатываем",
    button_name="Поехали")

if not variant:
    script.exit()      # пользователь закрыл окно - выходим тихо

Есть готовые окна выбора уровней, видов, семейств, файлов, прогресс-бар и forms.alert с кнопками. На такое в Dynamo Player рассчитывать нельзя, там сценарий линейный.

Раздача команде

Два маршрута, выбирайте по размеру команды.

Сетевая папка. Кладёте MyTools.extension на \\server\BIM\pyrevit\, каждый добавляет путь в Settings. Пять минут на человека, обновления прилетают всем сразу при следующем Reload. Минус: Revit стартует медленнее, а при недоступной сети кнопки просто исчезают.

Git-репозиторий. pyRevit умеет подключать расширение как клон репозитория и обновлять его кнопкой Update. Правки катятся коммитами, история видна, откат в одну команду. Настраивается дольше, но на команде от пяти человек окупается за месяц.

Отдельно про доверие. Первую кнопку команде давайте такую, которая ничего не меняет в модели: проверка, поиск, отчёт. Человек нажимает, видит пользу, ничем не рискует. После двух-трёх таких кнопок к пишущим относятся спокойно. В обратном порядке это не работает: одна испорченная модель, и к вашей вкладке больше не подойдут.

Грабли

IronPython против CPython. По умолчанию скрипты идут на IronPython 2.7. Кириллица в нём требует # -- coding: utf-8 -- в первой строке, иначе получите ошибку при первом же русском тексте. Нужен Python 3 с его библиотеками (requests, pandas) - первой строкой пишется #! python3, и скрипт исполняется другим движком. Смешивать их в одном расширении можно, но помнить надо.

Reload не всё подхватывает. Правки в script.py подхватываются сразу, а новые папки-кнопки и переименования - только после Reload. Иногда требуется перезапуск Revit.

Ошибка в скрипте роняет не Revit, а окно вывода. Это хорошая новость. Трейсбек показывается прямо в окне, с номером строки. Отладка идёт быстрее, чем в Dynamo, где ошибка прячется внутри жёлтой ноды.

Revit API не прощает версий. Метод, работавший в 2022, в 2024 может быть переименован или помечен устаревшим. Перед переходом на новую версию прогоните все свои кнопки на тестовой модели. У меня из восьми скриптов при переезде с 2021 на 2023 сломался один, и то из-за изменения в работе с единицами измерения.

Где pyRevit не подойдёт

Он не заменяет полноценный плагин на C#. Тяжёлые вычисления на десятках тысяч элементов на IronPython идут заметно медленнее. Своя оконная форма со сложным интерфейсом, лицензирование, продажа инструмента наружу - всё это территория обычной надстройки. Разница подробно разобрана в сравнении плагина и Dynamo.

Не подойдёт он и там, где IT-политика запрещает сторонние надстройки. Спорить бесполезно, лучше заранее показать службе безопасности открытый код и подписанный установщик.

И не ждите, что кнопки сами по себе поменяют процессы. Инструмент ускоряет то, что уже устроено разумно. Если в модели бардак с параметрами, кнопка будет быстро и красиво обрабатывать бардак.

Три трейсбека первого вечера

Окно вывода pyRevit показывает ошибку полностью, с номером строки. Это приятнее жёлтых нод Dynamo, но читать всё равно надо уметь.

«Autodesk.Revit.Exceptions.InvalidOperationException: Starting a transaction from an external application running outside of API context is not allowed.»

Длинно, а смысл простой: вы пытаетесь менять модель без транзакции. Оберните запись в with revit.Transaction("Название"):. Название попадёт в список отмены Revit, поэтому пишите его по-русски и понятно: пользователь увидит эту строку, когда нажмёт Ctrl+Z.

«SyntaxError: Non-ASCII character '\xd0' in file script.py on line 3, but no encoding declared.»

Привет от IronPython 2.7. Первой строкой файла ставится # -- coding: utf-8 --, и проблема исчезает. Сам файл при этом должен быть сохранён в UTF-8: Блокнот Windows любит записать в другой кодировке, и тогда кириллица в кнопках превращается в кашу. Пишите скрипты в VS Code, там кодировка видна в строке состояния.

«AttributeError: 'NoneType' object has no attribute 'AsString'.»

Параметра у элемента нет, LookupParameter вернул None, а вы сразу дёрнули метод. На разнородной выборке это происходит постоянно: у одного семейства параметр есть, у другого нет. Проверка на None перед обращением стоит одну строку и экономит вечер.

Отдельная история без всякого трейсбека: кнопка не появилась на ленте. Проверьте окончания папок (.extension, .tab, .panel, .pushbutton, точка обязательна), наличие script.py внутри и путь в Custom Extension Directories. Помогает нажатие Reload, иногда требуется перезапуск Revit.

Чек-лист перед раздачей команде

• Все кнопки прогнаны на трёх моделях разного размера, включая тяжёлую.
• В __doc__ каждой кнопки написано, меняет ли она модель. Это единственный текст, который пользователь прочитает, наведя курсор.
• Иконки нарисованы. Кнопка без картинки выглядит сломанной, и её не нажимают.
• Скрипты, меняющие модель, лежат на отдельной панели, визуально отделённой от проверок.
• Проверено на чужой машине, а не только на вашей: пути, права на сетевую папку, версия Revit.
• Есть человек номер два, который знает, где лежит расширение и как его откатить.
• Расширение не грузится с диска, который отваливается при работе из дома через VPN.

Короткие ответы на частые вопросы

Сколько стоит pyRevit? Нисколько. Открытый исходный код, бесплатен и для коммерческой работы. Деньги в этой теме уходят только на ваше время и на разработку своих инструментов.

Что скажет служба безопасности? Обычно ничего, если прийти к ним заранее. Установщик подписан, код открыт и лежит на GitHub, расширения читаются с вашего же сетевого диска. Конфликт возникает там, где надстройку ставят молча, а потом её находит аудит.

Можно ли запускать Dynamo-графы кнопкой pyRevit? Технически можно через API Dynamo, но связка хрупкая и ломается при обновлениях. Проще переписать логику графа на python: то, что в Dynamo занимает 30 нод, обычно укладывается в 40 строк кода и работает быстрее.

Что будет при переходе на новую версию Revit? Прогоняете установщик заново, он подцепляет свежую версию. Дальше проверяете свои кнопки на тестовой модели: код на python версий не боится, а вот методы Revit API иногда меняются.

Dynamo теперь не нужен? Нужен. Геометрию и всё, что удобно смотреть глазами по шагам, быстрее собрать графом. pyRevit выигрывает на логике, интерфейсе и скорости запуска. В командах, где живут оба инструмента, графы обычно остаются у проектировщиков, а кнопки пишет один человек на весь отдел.

Что сделать сегодня

Поставьте pyRevit, создайте папку расширения с одной кнопкой-проверкой и скопируйте туда скрипт выше. Полчаса от нуля до работающей кнопки, из них 20 минут уйдёт на угадывание правильных имён папок.

Дальше по маршруту: если ещё не собирали графы, посмотрите разбор первого скрипта в Dynamo - логика та же, синтаксис проще. Хорошее содержимое для первых кнопок берётся из автозаполнения параметров и выгрузок в Excel. А про то, как вообще приживаются инструменты в команде, написано в статье про Dynamo Player.

Нужен набор кнопок под ваши регламенты, с проверками модели по вашему BIM-стандарту? Напишите в Telegram или через форму на странице контактов, обсудим объём. Что мы делаем на таких задачах, коротко в услугах.

Ниже порядок, по которому мы это делаем. Если его пропустить, Clash Detective выдаёт свалку. Отчёт на 300 страниц уходит смежникам, и через две недели его перестают открывать.

Что сделать до запуска Navisworks

Больше половины странных результатов рождается ещё в Revit.

Координаты. Все разделы выгружаются в одной системе. В экспортёре NWC ставим Coordinates = Shared. Если АР ушёл в Internal Origin, а ОВ в Shared, модели разъедутся на метры, и проверять будет нечего.

Формат. Берём NWC. Он легче IFC, тянет параметры Revit и открывается за секунды. IFC подключаем, только если смежник сидит не в Revit. Тогда состав свойств проверяем отдельно: что доехало, что потерялось по дороге (разбор в статье про экспорт IFC из Revit).

Настройки экспортёра. Вкладка «Надстройки» → External Tools → Navisworks. Включаем Convert element properties и Convert element Ids. Без них в свойствах не будет ни системы, ни марки, ни номера этажа, и группировать результаты станет не по чему. Convert linked files выключаем: связи подцепим в Navisworks отдельными файлами, так их видно поимённо.

Имена файлов. Рабочая выгрузка живёт под постоянным именем: OV.nwc. Датированная копия (OV_2026-05-12.nwc) уезжает в архивную подпапку и в сборку не подключается. Так и история публикаций сохраняется, и пути в сборке не рвутся при каждой перевыгрузке.

Дальше собираем NWF: File → Append, по файлу на раздел. NWF хранит ссылки, а не геометрию, и весит килобайты. Перевыгрузили NWC, открыли NWF, модель уже свежая. NWD пакуем только для отправки наружу.

Наборы поиска вместо выделения мышью

Selection Set запоминает конкретные элементы. Перевыгрузили раздел, и набор рассыпался.

Search Set запоминает условие. После обновления моделей он собирает элементы заново, сам. Разница простая: перенастраивать проверку каждую неделю или нажать одну кнопку.

Собираются наборы в Home → Sets → Manage Sets → Find Items. Слева дерево загруженных файлов, справа строки условий: Category, Property, Condition, Value.

Рабочие примеры условий:

• Воздуховоды: Category = Element, Property = Category, Condition = Contains, Value = Воздуховоды. Отдельным набором добавляем «Фитинги воздуховодов», их часто забывают.
• Несущие конструкции: свойство «Несущие» (Structural) со значением Да. Так в набор не попадут перегородки.
• Магистрали ВК: фильтр по параметру «Тип системы» со значением из вашего шаблона, а не по имени семейства.
• Изоляция: отдельный набор, дальше объясню зачем.

Минимальный комплект для жилого дома: АР стены, АР перекрытия и лестницы, КР несущие, ОВ воздуховоды, ОВ трубопроводы, ВК трубопроводы, ЭОМ лотки и шинопроводы. Семь наборов закрывают процентов восемьдесят реальных проблем.

Наборы живут в NWF. Один раз собрали, дальше они работают весь проект.

Тесты в Clash Detective

Home → Clash Detective → Add Test. В каждом тесте выбираем набор A и набор B, тип проверки и допуск.

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

Допуск задаётся в поле Tolerance и работает как порог глубины пересечения. При 10 мм труба, зашедшая в стену на 6 мм, в отчёт не попадёт. Ставить 0 бессмысленно: получите тысячи касаний по стыкам плит.

Название теста пишем человеческим языком: «ОВ х КР несущие, 10 мм». Оно попадёт в отчёт, и его будет читать инженер, а не робот.

Сотни ложных пересечений: что с ними делать

Первый прогон почти всегда выглядит катастрофой. Дальше идёт чистка, и она занимает больше времени, чем сама проверка.

Правила. Вкладка Rules внутри теста. Включаем Items in Same Layer, Items in Same Group/Block/Cell и Items with Coincident Snap Points. Три галочки убирают самопересечения внутри одной системы: врезки, тройники, отводы.

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

Допуск по здравому смыслу. Между лотком и воздуховодом 25 мм лучше десяти: монтажные зазоры всё равно закладываются на площадке.

Проверка на подмену задачи. Если один тест выдал больше 500 результатов, чаще всего сломан набор, а не проект. Смотрим первые двадцать позиций. Одинаковые? Значит виновата одна системная ошибка: сдвинутый уровень, задвоенная связь, забытый черновой этаж.

После чистки из 4 812 пересечений в том проекте осталось 340 сгруппированных пунктов, из них к обсуждению 57.

Группировка и статусы

Сырой список не выдают проектировщику никогда. Двенадцать пересечений одного стояка с двенадцатью перекрытиями это один вопрос, а не двенадцать.

В окне Results сортируем по Grid Intersection или по имени элемента, выделяем связанные строки, правая кнопка → Group. Группе даём имя: «Стояк К1, оси 3-4, проходы через перекрытия». Дальше работаем только с группами.

Статусы в Navisworks встроенные:

• New появился в текущем прогоне.
• Active был раньше, не решён.
• Reviewed просмотрен координатором, отправлен в работу.
• Approved согласован как допустимый, решать не нужно.
• Resolved закрыт, при следующем прогоне геометрия не пересекается.

Approved ставит только координатор и всегда с комментарием. Без комментария через месяц никто не вспомнит, почему пересечение признали нормальным.

Поле Assign To заполняем по разделу, не по фамилии: раздел никуда не денется, а сотрудник может уйти в отпуск.

Как часто гонять проверку

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

Полный прогон по всем тестам ставим на ночь или на выходные. Navisworks на модели в полтора гигабайта забирает всю память рабочей станции, параллельно работать не выйдет.

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

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

Три симптома сломанной проверки

Тест выдал ноль коллизий, а пересечения видно глазами.

Виноват набор. Условие в Search Set написано по имени семейства, а семейства в модели переименовали. Откройте набор, нажмите Update и посмотрите счётчик элементов внизу окна. Пусто или подозрительно мало, значит условие бьёт мимо. Лечится переводом условия на категорию или на параметр типа системы.

При открытии NWF выскакивает Cannot find file.

Кто-то переложил или переименовал NWC, а сборка хранит путь. Все выгрузки держим в одной папке проекта под постоянными именами, датированные копии живут отдельно. Правило простое: путь в сборке настраивается один раз за проект.

После перевыгрузки все статусы слетели в New.

Так бывает, когда тест пересобрали заново вместо обновления исходников. Тесты не удаляем никогда: правим наборы, жмём Update All, потом Run. Вторая причина того же симптома: в экспорте Revit выключен Convert element Ids, и Navisworks просто не узнаёт элементы после обновления.

Отчёт, который читают

Вкладка Report. Формат HTML (Tabular) даёт таблицу с картинками, открывается в любом браузере, весит немного при разумном числе позиций.

Настройки Contents: оставляем Image, Clash Point, Item 1/Item 2 (имя, категория, уровень), Status, Comments, Assigned To. Всё остальное выключаем.

Include Clashes ставим на Group headers only, если групп больше сотни, иначе документ распухнет до сотен мегабайт.

Для точек обзора удобнее XML или BCF (через плагин BCF Manager): смежник открывает пункт прямо в своей модели с нужным ракурсом. HTML идёт руководителю проекта, BCF рабочим инженерам.

Что дописываем к отчёту вручную, одной страницей: дата, версии моделей, число проверок, статистика по разделам, десять самых дорогих пунктов. Эту сводку читают, а таблицу на 340 строк нет.

Перед отправкой отчёта смежникам

• Открыть отчёт самому и пролистать до конца. Битые картинки и пустые строки видно сразу.
• Проверить, что получатель у каждого пункта назван разделом, а не фамилией.
• Убедиться, что пункты со статусом Approved в файл не попали.
• Написать в теле письма три цифры: новых, закрытых, висящих дольше двух недель.
• Указать дату прогона и версии моделей, по которым считали. Без этого первым ответом будет «а у нас уже поправлено».

Пять пунктов, три минуты. Отчёт, отправленный без них, обычно возвращается вопросами, а не решениями.

Что спрашивают чаще всего

Сколько коллизий это нормально? На жилом доме перед выдачей рабочей документации мы считаем рабочим диапазон 30-80 открытых пунктов после группировки. Ноль означает, что проверка настроена неправильно.

Проверять по IFC или по NWC? По NWC, когда вся команда сидит в Revit. IFC берут, если в проекте есть вторая среда, и тогда сначала проверяют качество самого IFC.

Manage или Freedom? Clash Detective живёт только в Manage. Freedom бесплатен, но это просмотрщик: смежникам его хватает, координатору нет.

Можно ли проверять модели, сделанные в разных версиях Revit? Да, NWC не тянет за собой версию исходника. Экспортёр ставится под каждую версию Revit отдельно, это единственное ограничение.

Кто должен гонять проверку: координатор или каждый раздел сам? Полный прогон делает координатор, иначе получите четыре разных набора правил. Инженерам полезно проверять свой раздел локально, перед публикацией.

Чего от Navisworks ждать не надо

Он не понимает норм. Расстояние от газовой трубы до электрокабеля, высота прохода под коробом, нормируемый уклон канализации: ничего этого Clash Detective не проверит. Он сравнивает объёмы, а не требования СП.

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

Организационные проблемы ему не по зубам. Если смежник присылает модель раз в месяц и без предупреждения, проверка покажет свежие коллизии по устаревшей геометрии. Это лечится не настройками, а порядком обмена и встречами, про которые есть отдельный разбор: регламент BIM-координации.

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

С чего начать на своём проекте

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

Дальше масштабируйте наборы на весь дом и ставьте проверку на расписание.

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

Опишите задачу в Telegram или через контакты: скажем, что делается за неделю, а что требует изменения процесса.

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

Какую версию ставить

В экспортёре Revit версий 2020-2025 в списке лежит десяток вариантов. Реально используются два.

IFC 2x3 Coordination View 2.0. Рабочая лошадь для координации. Её понимают все: Navisworks, Solibri, BIMcollab, Tekla, отечественные просмотрщики. Если смежник не сказал иначе, отдавайте этот вариант.

IFC4 Reference View. Точнее описывает геометрию, компактнее по кривым поверхностям, лучше держит параметрические профили. Проблема одна: поддержка на приёмной стороне неровная. Один просмотрщик откроет идеально, второй потеряет часть свойств, третий покажет серые коробки.

Остальные схемы под конкретные задачи: GSA Concept Design под американские требования, Basic FM HandOver под сдачу модели службе, которая будет обслуживать здание, IFC4 Design Transfer View под попытку передать редактируемую геометрию.

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

Где лежат настройки и что в них важно

File → Export → IFC → Modify setup. Пять вкладок, и на каждой есть по паре пунктов, которые решают судьбу файла.

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

Coordinate base. Здесь выбирают точку отсчёта. Shared Coordinates даёт файл, который встанет в общую сборку без сдвигов. Internal Coordinates выдаёт модель, уехавшую на координаты площадки, и смежник получает здание в трёх километрах от остальных.

Export only elements visible in view. Без этой галочки в файл уедет всё, включая черновые массы, временные объёмы и чужие связи. С галочкой вы контролируете состав: сделайте 3D-вид «IFC_export», настройте видимость по рабочим наборам и фильтрам, проверьте глазами. Этот вид становится частью процесса и живёт в шаблоне.

Store IFC GUID in element parameter. Пишет в элемент Revit тот же идентификатор, который уйдёт в IFC. Дальше замечание из BCF или из отчёта по коллизиям находится в модели поиском по GUID, а не «где-то на третьем этаже возле оси Г».

Маппинг категорий: почему всё стало IfcBuildingElementProxy

Revit сопоставляет свои категории классам IFC по таблице. Открывается она через File → Export → Options → IFC Options: слева категория Revit, справа IFC Class Name и подтип.

Основная беда живёт в категории «Обобщённые модели». Всё, что смоделировано семейством этой категории, уезжает как IfcBuildingElementProxy. Для смежника это означает объект без класса: он не попадёт ни в фильтр по стенам, ни в фильтр по оборудованию, ни в расчёт объёмов. А в «Обобщённые модели» у проектировщиков попадает многое: закладные, нестандартные шахты, ограждения, часть оборудования.

Лечится двумя способами.

Первый: правка таблицы. Меняете класс для категории целиком, сохраняете файл маппинга и раздаёте команде. Работает, когда категория используется однородно.

Второй, точнее: параметры IfcExportAs и IfcExportType. Добавляете их как общие параметры типа (текстовые), пишете значение вроде IfcCovering или IfcRailing, и конкретное семейство уезжает нужным классом независимо от категории. Мы обычно зашиваем эти параметры сразу в шаблон и в основные семейства, тогда рядовой проектировщик про них даже не вспоминает.

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

Что теряется при экспорте всегда

IFC переносит объём и свойства. Всё, что было логикой Revit, остаётся в Revit.

• Параметрика семейств. Уезжает геометрия в текущем состоянии, ручки и формулы нет.
• Связи и зависимости: привязка стены к уровню, соединения элементов, автоматическое подрезание.
• Двумерное оформление: штриховки, аннотации, размеры, виды. Галочка Export 2D plan view elements переносит немногое и обычно мусорит.
• Заливка помещений, если не включён экспорт IfcSpace. По умолчанию помещения из 3D-видов не выгружаются, и смежник не увидит ни площадей, ни границ.
• Часть параметров экземпляра, если выключены Revit property sets. Тогда остаётся только базовый набор IFC.
• Материалы приходят названиями, а не физическими свойствами.

Отдельная история со стенами и колоннами через несколько этажей. Без Split walls and columns by level элемент уедет одним объектом на всю высоту, и любая поэтажная выборка у смежника поедет. Считать объёмы по этажам по такому файлу нельзя.

Проверка перед отправкой: 10 минут

Экспорт без проверки это отправка вслепую. Минимальный чек-лист, который экономит дни переписки.

1. Открыть свой же IFC в стороннем просмотрщике. Не в Revit, он покажет слишком лояльно. Подходит любой бесплатный просмотрщик IFC или Navisworks с плагином.
2. Сверить число элементов. В Revit спецификация с фильтром по тому же 3D-виду, в просмотрщике счётчик объектов. Расхождение больше пары процентов означает, что в файл уехало лишнее или недоехало нужное.
3. Ткнуть в пять случайных элементов разных категорий и посмотреть свойства. Марка, тип, уровень, материал на месте? Если пусто, вернитесь на вкладку Property Sets.
4. Проверить точку привязки. Совместите IFC с моделью АР или с топосъёмкой. Сдвиг виден сразу.
5. Посмотреть дерево уровней. Элементы должны сидеть на своих этажах, а не в разделе «Без уровня».
6. Сравнить объёмы по трём позициям: бетон, стены, воздуховоды. Расхождение с ведомостью Revit больше пяти процентов это повод разбираться, а не отправлять.

Пункты 2 и 6 автоматизируются: выгрузка свойств из IFC в таблицу и сверка со спецификацией Revit делается скриптом за пару секунд. На объёмах от десяти файлов в месяц это окупается сразу.

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

Если выгрузок много, заведите лог: дата, версия модели, кто выгружал, что менялось в настройках. Три строки на выгрузку. Зато вопрос «откуда взялся этот файл» закрывается за минуту, а не за полдня переписки.

Четыре жалобы смежников и что за ними стоит

«Файл пустой, ничего не видно». Экспорт шёл с галочкой Export only elements visible in view, а вид оказался с фильтрами или подрезкой. Состав вида проверяют до выгрузки, а не после звонка.

«Ваш дом стоит в трёх километрах от нашего». В Coordinate base стояли Internal Coordinates или Survey Point. Ставим Shared Coordinates и отправляем заново.

«У элементов нет ни одного свойства». Выключены Revit property sets. Включить и проверить на пяти элементах перед отправкой.

«Двери у вас не двери, а какие-то прокси». Семейства сделаны в категории обобщённых моделей. Правится таблицей маппинга или параметром IfcExportAs.

Пятая жалоба стоит особняком: «объёмы в вашем IFC не сходятся с ведомостью». Обычно виноваты выключенные base quantities или сквозные стены без разбивки по этажам. Проверяется на трёх позициях за пять минут.

Что приложить к файлу

• Схему и версию: IFC 2x3 CV 2.0 или IFC4 RV.
• Дату выгрузки и версию исходной модели.
• Имя вида, из которого шёл экспорт.
• Чего в файле нет намеренно: черновая геометрия, временные конструкции, чужие связи.

Четыре строки в письме снимают половину вопросов. Смежник сразу видит, что перед ним, и не тратит день на выяснение, у кого в цепочке потерялись свойства.

Что смотреть в чужом IFC на приёме

Входной контроль занимает те же десять минут и снимает половину будущих претензий.

• Схема и версия совпадают с тем, о чём договаривались на старте.
• Файл встаёт в общую сборку без ручного сдвига.
• Доля IfcBuildingElementProxy. Больше пяти процентов, и ваши фильтры работать не будут.
• Есть свойства, по которым вы собираетесь группировать коллизии и считать объёмы.
• Уровни на месте, элементы сидят на своих этажах.
• Не приехала чужая черновая геометрия и связи соседних разделов.

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

Чего от IFC ждать не надо

Он не заменяет исходную модель. IFC годится для координации, проверки, подсчёта и передачи заказчику. Проектировать в нём и править его как родной файл нельзя: Design Transfer View обещает больше, чем даёт на практике.

Круговой обмен без потерь не выйдет. Экспорт из Revit, правка у смежника, импорт обратно: каша почти гарантирована. Работают иначе. Каждый ведёт свой раздел в своей программе, а IFC служит для чтения, проверки и подсчёта.

Он не гарантирует одинаковой картинки в разных программах. Один и тот же файл в двух просмотрщиках может показать разное число объектов, потому что каждый по-своему разбирает вложенные сборки. Ошибки экспорта тут нет. Держите это в голове, когда спорите о числах со смежником.

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

Коротко по частым вопросам

IFC или NWC для координации? NWC, если все работают в Revit: он легче и точнее тянет параметры. IFC нужен, когда в проекте больше одной среды проектирования.

Можно ли по IFC считать спецификации? Можно, при включённых property sets и base quantities. Выгрузка свойств в таблицу и сверка с ведомостью Revit автоматизируется скриптом за час работы.

Почему один файл в разных программах показывает разное число объектов? Разные правила разбора вложенных сборок. Считайте в одной программе и зафиксируйте её в договорённостях по проекту.

Связи выгружать отдельными файлами? Да. Export linked files as separate IFCs даёт по файлу на раздел, и смежник обновляет их поштучно. Единый файл со всеми связями неудобно перевыпускать.

Кто отвечает за выгрузку: автор раздела или BIM-специалист? Выгружает автор, проверяет координатор. Схема, где за всю компанию выгружает один человек, ломается на первом же его отпуске.

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

Следующий шаг

Сделайте одну вещь на ближайшей выдаче: экспортируйте по чек-листу выше и откройте свой файл сторонним просмотрщиком до отправки. За десять минут вы увидите, что именно получает смежник. Обычно это отрезвляет.

Дальше настройте один общий сетап экспорта на команду, зашейте IfcExportAs в шаблон и опишите правила в BIM-стандарте. Как это стыкуется с проверкой моделей, разобрано в статье про проверку коллизий в Navisworks, а хранение и версии файлов в статье про среду общих данных.

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

Пришлите пробный IFC в Telegram или напишите через контакты. Посмотрим файл и скажем, что в нём поедет у смежника.

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

Что такое Player и чего он не умеет

Кнопка на вкладке «Управление», рядом с самим Dynamo. Открывается панель со списком графов из указанной папки. Каждый граф - строка с названием, описанием и кнопкой запуска.

Player запускает .dyn без открытия среды Dynamo, поэтому стартует за пару секунд вместо двадцати. Показывает поля ввода, которые вы разрешили. Отдаёт результат в модель.

Чего он не делает:

• не показывает предупреждения нод (жёлтые узлы в Player невидимы);
• не даёт откатить частично выполненный граф;
• не умеет диалоговых сценариев «сначала выбери одно, потом покажу второе»;
• при ошибке пишет что-то невнятное вроде «Graph has issues», без указания места.

Последнее означает: отлаживать всё равно придётся в Dynamo. Player - витрина, а не среда разработки.

Подготовка графа: пять шагов

1. Режим запуска Manual. Открываете граф, переключаете Run на Manual, сохраняете. Граф, сохранённый в Automatic, в Player ведёт себя непредсказуемо.

2. Помечаем входы. Правый клик по ноде → Is Input. Только помеченные ноды попадут в панель Player. Поддерживаются не все типы: Number Slider, Integer Slider, String, Boolean, File Path, Directory Path, Select Model Element и Select Model Elements. Code Block входом быть не может, выпадающий список Categories - тоже, и это первое разочарование при подготовке.

Обходной путь для выбора категории: строковый вход с точным именем плюс Category.ByName внутри графа. Пользователь пишет «Двери», граф разбирается сам. Работает, но требует от человека точного написания, поэтому в описании обязательно перечислите допустимые варианты.

3. Переименовываем входные ноды. Имя ноды становится подписью поля. String в панели выглядит как String, и человек не понимает, что туда писать. Двойной клик по заголовку ноды, пишем по-человечески: Имя параметра (например, Обозначение), Префикс номера, Куда сохранить отчёт.

4. Заполняем свойства графа. В Dynamo: «Файл» → «Свойства графа». Там имя, описание, автор и картинка-превью. Описание видно прямо в панели Player, и это единственная документация, которую пользователь реально прочитает. Пишите в нём не «скрипт для нумерации», а что произойдёт с моделью: «Перенумерует все помещения на активном виде. Старые номера будут перезаписаны. Отмена через Ctrl+Z».

5. Выход тоже помечаем. Правый клик → Is Output на ноде Watch со сводкой. Пользователь увидит «обработано 307 элементов» и поймёт, что скрипт отработал. Без этого он видит пустую панель и не понимает, случилось ли что-нибудь.

Папки, версии, пакеты

В панели Player есть шестерёнка: там задаётся путь к папке с графами. Кладите её на сетевой диск, к которому у всех есть доступ на чтение: \\server\BIM\dynamo\. Запись оставьте себе.

Внутри разложите по подпапкам. Player показывает их вкладками, и это единственная навигация, которая у вас есть:

Версию пишите в имени файла: Нумерация_помещений_v4.dyn. Не «финал», не «новый», не «финал2». Когда у половины команды Revit 2022, а у половины 2024, добавляйте версию Revit в имя папки, потому что граф с нодами из свежего ядра в старом Dynamo просто не откроется.

Пакеты - главная техническая причина «у меня не запускается». Если граф использует Clockwork, archi-lab или Rhythm, а у пользователя их нет, Player покажет ошибку. Два решения. Первое: собирать графы для команды только на нодах ядра, даже если это на 20% дольше. Второе: положить папку packages на тот же сетевой диск и прописать всем путь в настройках Dynamo («Параметры» → «Управление путями к узлам и пакетам»). Второй вариант надёжнее, но требует один раз пройтись по машинам.

Инструкция на одну страницу

Пять пунктов, не больше. Люди не читают документацию длиннее экрана, и это не их недостаток.

1. Что делает скрипт, одной фразой.
2. Что должно быть открыто до запуска: какой вид, какая модель, синхронизирована ли.
3. Что вводить в поля, с примером реального значения.
4. Что появится в результате и как это проверить.
5. К кому идти, когда сломалось. С именем, а не «в отдел BIM».

Держите инструкцию рядом с графом, в той же папке, в PDF. Ссылку на неё вставьте в описание графа.

Почему внедрение проваливается

Технически всё готово, а пользуются двое из шести. Причины из практики, по частоте.

Скрипт решает не ту задачу. Автор автоматизировал то, что раздражало лично его. У остальных болит другое. Лечится наблюдением: сядьте рядом с проектировщиком на полчаса и посмотрите, что он делает руками чаще всего.

О скрипте никто не знает. Разослали письмо, все прочитали и забыли через день. Работает только показ: 15 минут на планёрке, на боевой модели, с реальным результатом на экране.

Один раз испортил модель. Самая тяжёлая причина. Скрипт что-то перезаписал, человек потерял час на восстановление, и больше он к Player не подойдёт никогда. Доверие возвращается месяцами. Профилактика: первые версии графов делайте в режиме «только отчёт», пусть они показывают, что собираются изменить, и ничего не пишут.

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

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

Где это не работает

Player не годится для операций, требующих выбора по ходу дела. Диалоги, подтверждения, разветвления сценария - для этого нужен либо forms из pyRevit, либо полноценный плагин. Разница между подходами разобрана в статье про плагин и Dynamo.

Тяжёлые графы в Player запускать неудобно. Пять минут молчащего интерфейса без прогресс-бара человек воспринимает как зависание и жмёт Escape посреди транзакции. Всё, что дольше минуты, лучше оформлять отдельной процедурой с явным предупреждением.

И не ждите, что Player заменит обучение. Он снижает порог, но не отменяет понимания того, что скрипт делает с моделью. Человек, который не знает разницы между параметром типа и экземпляра, нажмёт кнопку и получит сорок изменённых дверей вместо одной.

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

«Пишет Graph has issues, и всё».

Player не показывает, что именно сломалось. Открывайте этот же граф в Dynamo и смотрите на красные ноды. Три частые причины: не установлен пакет, граф сохранён в другой версии Dynamo, входная нода помечена как Is Input, но её тип Player не поддерживает. Последнее коварно тем, что у автора всё работает: он-то запускает из среды.

«Кнопка нажалась, а ничего не произошло».

Скрипт отработал на активном виде, а человек стоял на 3D-виде или на листе. Либо выборка пуста, потому что нужные элементы лежат на другом уровне. Лечится двумя способами: ставить в граф проверку контекста с внятным сообщением («откройте план этажа») и обязательно выводить в Is Output количество обработанных элементов. Пустой результат должен выглядеть как «обработано 0», а не как тишина.

«Он мне всё перезаписал».

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

Чек-лист перед раздачей

• Граф отработал на трёх разных моделях, а не только на той, где писался.
• Имена входных полей понятны человеку, который граф не писал. Проверяется просто: покажите панель коллеге и спросите, что он туда впишет.
• В описании сказано, что меняется в модели и что делать при ошибке.
• Скрипт не падает на пустой выборке и на модели без нужной категории.
• Пакетов нет. Если есть, путь к общей папке пакетов прописан у всех, и это проверено на чужой машине, а не на вашей.
• Есть версия в имени файла и предыдущая копия в _archive.
• Кто-то из команды, кроме вас, знает, где лежат исходники и как их открыть.

Короткие ответы на частые вопросы

Player входит в Revit или его надо покупать? Входит, начиная с Revit 2017, отдельная лицензия не нужна. Это часть Dynamo for Revit.

Можно ли запускать графы по расписанию, ночью? Через Player нет, он требует открытого Revit и живого человека у кнопки. Пакетная обработка моделей делается другими средствами: Design Automation или обвязка на pyRevit с журналами Revit. Тема отдельная и заметно дороже в настройке.

Как запретить части команды пользоваться скриптами? Правами на папку. Player видит только то, что доступно пользователю на чтение. Разложите графы по подпапкам под разные отделы и раздайте доступ по группам.

Работает ли Player в Revit LT? Нет. В LT нет Dynamo и API для надстроек, и обойти это нечем.

Сколько графов нормально держать в библиотеке? У команд, которые я видел вблизи, живут 8-15 штук. Всё, что сверху, обычно лежит мёртвым грузом: люди помнят десяток инструментов, дальше начинают искать, а поиска в Player нет.

Следующий шаг

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

Графа пока нет? Соберите первый по пошаговому разбору. Хорошие кандидаты на раздачу команде: автозаполнение параметров и выгрузки в Excel. Когда библиотека перерастёт два десятка графов, пора смотреть в сторону собственных кнопок на pyRevit.

Хотите собрать библиотеку скриптов для отдела и не тратить на это полгода? Напишите в Telegram или через форму на странице контактов. Что мы делаем на таких внедрениях, есть в услугах, частые вопросы собраны в FAQ.

Разберём такой скрипт от пустого холста до записанного параметра. Не «обзор возможностей», а конкретная сборка: какие ноды, в какой порт, что сломается и почему.

Почему именно нумерация

Первую автоматизацию выбирают неправильно. Берут что-нибудь красивое: расстановку по кривой, генеративный фасад, разбор IFC. Потом две недели ковыряются, бросают и делают вывод, что Dynamo «не для реальных задач».

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

Версии. У меня под рукой Revit 2022 (Dynamo 2.12), 2023 и 2024 (Dynamo 2.17 и выше). Всё, что ниже, работает во всех трёх без пакетов из Package Manager. Это важно: скрипт без внешних пакетов вы потом отдадите коллеге, и у него он тоже запустится.

Открываем и настраиваем

Вкладка «Управление» (Manage) → Dynamo. Открывается стартовое окно, жмём New.

Первое, что нужно сделать до всего остального: переключить режим запуска. Внизу левой панели есть выпадающий список Run: Automatic / Manual / Periodic. По умолчанию стоит Automatic, и это единственная настройка, из-за которой новички теряют модели. В автоматическом режиме граф пересчитывается на каждое ваше действие. Подключили ноду записи параметра, случайно задели значение, и Dynamo уже записал что-то в 212 помещений. Ctrl+Z в Revit это откатывает, но не всегда так, как вы ждёте.

Ставьте Manual. Запуск только по кнопке Run, когда вы к нему готовы.

Сборка графа

Ноды ищутся двойным кликом по пустому холсту. Начинаем.

1. Categories. Выпадающий список всех категорий Revit. Выбираем «Помещения» (Rooms). Выход у ноды один, называется Category.

2. All Elements of Category. Вход Category соединяем с выходом предыдущей ноды. На выходе получаем список всех помещений в модели. Раскройте превью под нодой: там должно быть 212 строк вида Room. Если ноль, значит вы в файле, где помещений нет, или они в связанной модели (об этом ниже).

3. Element.GetParameterValueByName. Здесь начинается работа с данными. Вход element берёт наш список, вход parameterName ждёт строку. Строку даём через ноду String, вписываем туда Уровень. Именно так, как параметр называется в вашей локализации Revit, с той же буквой и без лишних пробелов. Русский Revit ждёт русское имя, английский - Level. Это причина примерно половины пустых выходов на первом часу знакомства с Dynamo.

4. List.GroupByKey. Раскладывает помещения по уровням. Вход list - помещения, вход keys - уровни с предыдущей ноды. На выходе два порта: groups (списки помещений по этажам) и uniqueKeys (сами уровни). Нам нужен groups.

5. Сортировка внутри этажа. Помещения на этаже лежат в том порядке, в каком их создавал проектировщик, то есть в случайном. Сортируем по координате. Берём Element.GetLocation (в Dynamo 2.13+ это ядро, в 2.12 придётся взять Clockwork или маленький Python-узел), из точки достаём Point.X и Point.Y, дальше List.SortByKey.

Честно: сортировка «по часовой стрелке» через координаты работает только на регулярных планировках. На доме-башне с ядром посередине я в итоге сортировал по углу от центра секции. Это отдельная история и лишние полчаса.

6. Code Block с номерами. Двойной клик, пишем:

"К" + (1..List.Count(rooms));

Code Block - это текстовое поле для языка DesignScript. Он умеет то, ради чего иначе пришлось бы ставить пять нод. Запись 1..25 даёт диапазон чисел, 1..#25 - ровно 25 значений, "К" + число склеивает строку.

7. Element.SetParameterByName. Финал. Вход element - отсортированный список, parameterName - строка Номер, value - наши номера.

Порты, связи и лейсинг

Три вещи, которые в учебниках проговаривают вскользь, а на практике съедают вечер.

Цвет и направление. Выход всегда справа, вход слева. Тянуть можно в любую сторону, но связь пойдёт только выход → вход. Порт, подсвеченный красным после запуска, означает не «ошибку соединения», а ошибку внутри ноды: наведите курсор, там текст предупреждения.

Лейсинг (Lacing). Правый клик по ноде → Lacing. Три варианта: Shortest, Longest, Cross Product. Разница видна, когда на входах списки разной длины. Подаёте 212 помещений и одно имя параметра: при Shortest обработается одно помещение, при Longest все 212. Значение по умолчанию Auto обычно угадывает, но не всегда. Пустой результат при живых входных данных - первый подозреваемый именно лейсинг.

Уровни списков (List Levels). У входного порта есть маленькая стрелка >, за ней настройка @L1, @L2, @L3. После GroupByKey у вас список списков: этажи, внутри этажей помещения. Нода, которая ждёт плоский список, на вложенном ведёт себя странно. Иногда ошибка, иногда молча берёт первый уровень. Переключение на @L2 заставляет ноду работать с каждым подсписком отдельно. Разобравшись с этим один раз, вы закрываете половину вопросов «почему у меня не считается».

Ловушка, о которой не пишут

Запускаем. Dynamo желтеет, в предупреждениях висит что-то про duplicate number, а в модели вместо К1, К2, К3 появились К1, К2 2, К3 3.

Причина простая. Номер помещения в Revit уникален в пределах проекта. Пока вы пишете новые номера, старые ещё на месте. Скрипт добирается до пятого помещения, пытается записать К5, а К5 уже занят помещением на другом этаже. Revit не ругается на весь скрипт, он тихо дописывает суффикс.

Лечится в два прохода. Первый: пишем всем помещениям временные значения, которых в проекте гарантированно нет.

// Code Block, проход 1: временные номера
"tmp_" + (1..List.Count(rooms));

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

Вторая мелочь того же рода: помещения без границ (Not Enclosed) и незамещённые (Redundant) тоже попадают в выборку. Их лучше отфильтровать через Element.GetParameterValueByName по площади и List.FilterByBoolMask, иначе нумерация поедет на пустых объектах.

Проверка результата

Скрипт отработал, но верить ему на слово нельзя. Три способа убедиться, что всё встало правильно:

• спецификация помещений, отсортированная по номеру, глазами по 20 строкам с каждого этажа;
• фильтр вида, подсвечивающий помещения с пустым номером красным (10 минут настройки, дальше пользуетесь всегда);
• обратный прогон Dynamo: собрать номера и прогнать через List.Count и List.UniqueItems - если числа разошлись, где-то дубли.

Третий вариант я держу отдельным маленьким графом-проверялкой. Он ничего не пишет в модель, только считает. Полезно давать его вместе с основным скриптом.

Где это не работает

Скрипт не тронет помещения в связанной модели. All Elements of Category собирает элементы только текущего документа. Для связей нужен другой набор нод и права на запись, которых у вас в чужом файле нет.

Не сработает и на файлах, где номер помещения заполняется из внешней таблицы через плагин заказчика: скрипт запишет своё, плагин при следующей синхронизации перезапишет обратно. Такое встречалось на объекте с BIM-регламентом от техзаказчика, там нумерацию отдавали их системе.

Не ждите, что первый граф будет работать вечно. Обновили Revit до следующей версии - проверьте. Ноды ядра стабильны, но параметры проекта и шаблоны меняются чаще, чем сам Dynamo.

И честно про экономию времени. Написание этого скрипта с нуля новичком занимает от четырёх часов до двух дней. На одном доме он не окупается. Окупается на пятом, когда его запускают за минуту и без раздумий.

Три сообщения, которые вы точно увидите

Ошибки в Dynamo выглядят одинаково: нода желтеет, под ней текст. Текст английский и не всегда честный. Разберём три самых частых.

«Warning: Element.GetParameterValueByName operation failed. The parameter name is not found.»

Перевод на человеческий: параметра с таким именем у элемента нет. В девяти случаях из десяти виновата не модель, а строка на входе. Лишний пробел в конце, латинская C вместо русской, «Номер помещения» вместо «Номер». Лечится за минуту: выделите элемент в Revit, откройте свойства, скопируйте имя параметра оттуда буква в букву. Второй по частоте виновник - локализация: граф писали в русском Revit, запускают в английском.

«Warning: Element.SetParameterByName operation failed. The parameter is read-only.»

Вы пытаетесь писать в поле, которое считает сам Revit. Площадь помещения, объём, периметр, отметка уровня. Список read-only параметров нигде не опубликован полностью, узнаётся опытом. Если запись нужна принципиально, значение кладут в отдельный общий параметр и уже его выводят в спецификацию.

«Dereferencing a non-pointer.»

Самое загадочное сообщение Dynamo и самое частое у новичков. Означает примерно следующее: нода ждала один элемент, а получила список, или наоборот. Иногда в цепочку пробрался null от помещения без границ. Порядок разбора такой: раскрыть превью у каждой ноды слева направо, найти первую, где вместо данных пустота, и смотреть уровни списков у её входа. В 80% случаев проблема решается переключением порта на @L2 или вставкой List.Flatten.

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

Что проверить, прежде чем показывать граф коллеге

• Граф сохранён в режиме Manual.
• Все ноды подписаны по-русски: через месяц вы сами не вспомните, что делает Code Block в углу холста.
• Пакеты не используются вообще. Если без Clockwork не обошлось, напишите это в описании графа.
• На пустой выборке скрипт не падает, а сообщает «обработано 0 элементов». Это отдельная ветка с List.Count, минут на десять работы, зато пользователь понимает, что произошло.
• Файл лежит не на вашем рабочем столе.
• Вы прогнали граф дважды подряд на одной модели и результат не изменился. Скрипт, который при повторном запуске дописывает префикс поверх префикса, вернётся к вам вечером пятницы.

Короткие ответы на частые вопросы

Нужно ли уметь программировать? Для первого графа нет. Уровня «понимаю, что такое список и цикл» достаточно. Python понадобится, когда захочется условий сложнее двух ветвей.

Скрипт может испортить модель? Может. Он делает ровно то, что написано, включая запись не туда. Отсюда правило про копию файла и Manual-режим. Ctrl+Z после запуска откатывает всё изменённое графом одним шагом, но только пока вы не сделали в Revit ничего другого.

Почему у коллеги мой .dyn не открывается? Три причины по частоте: у него старше версия Dynamo (граф из 2.17 в 2.12 не откроется), нет установленного пакета, другая локализация Revit и не совпали имена параметров.

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

Следующий шаг

Соберите этот граф на копии рабочего файла. Не на боевом. Дойдя до первой записи параметра, сохраните файл под новым именем и только потом жмите Run.

Когда граф заработает, его захотят коллеги. Отдавать .dyn по почте не надо, для этого есть Dynamo Player: как подготовить скрипт к передаче, разобрано в отдельной статье. Если руки чешутся автоматизировать не нумерацию, а заполнение параметров пачкой, начните с этого разбора. А когда скриптов станет больше десятка и захочется настоящих кнопок в интерфейсе, посмотрите на pyRevit.

Задача сложнее учебной? Опишите её в Telegram или через форму на странице контактов: посмотрим, решается ли она графом за вечер или там уже нужен плагин. Что мы делаем на таких задачах, коротко описано в разделе услуг.