Самая недооцененная проблема Revit — семейства
Когда люди говорят о проблемах Revit, обычно вспоминают:
- тяжелые модели;
- тормоза;
- синхронизации;
- worksharing;
- Navisworks;
- ACC;
- “почему Revit опять завис”.
Но почти никто не говорит о том, что чаще всего убивает проект намного раньше.
Семейства.
И самое интересное — многие до сих пор вообще не понимают масштаб проблемы.
Очень часто к семействам относятся как к чему-то второстепенному:
— “Ну family и family.”
— “Скачали с сайта производителя.”
— “Главное чтобы выглядело похоже.”
— “Работает — не трогай.”
А потом начинается BIM.
И внезапно выясняется, что семейство влияет вообще на всё:
- производительность модели;
- спецификации;
- координацию;
- оформление;
- автоматизацию;
- работу фильтров;
- работу систем;
- Shop Drawings;
- композиты;
- IFC;
- Navisworks;
- Solibri.
Фактически семейства — это фундамент модели.
Плохое семейство способно разрушить нормальную работу целого проекта.
Причем проблема в том, что визуально всё может выглядеть нормально.
В 3D красиво.
На листе вроде тоже красиво.
Но внутри семейства может быть настоящий цифровой Чернобыль.
Особенно это касается контента от производителей.
Да, сейчас практически у каждого производителя есть BIM-контент.
Но проблема в том, что очень часто этот контент делается не BIM-специалистами, а маркетингом.
Главная задача такого семейства:
- красиво выглядеть в каталоге;
- крутиться в 3D;
- впечатлить заказчика.
А то, что потом:
- модель весит 5 гигабайт;
- спецификации ломаются;
- коннекторы работают неправильно;
- параметры дублируются;
- вложенные семейства живут своей жизнью;
- geometry detail level выше чем у космического корабля NASA —
это уже “не их проблема”.
Особенно весело становится на больших проектах.
Пока в модели 20 семейств — Revit терпит.
Когда их тысячи —
начинается расплата за инженерные грехи.
И тут появляется классическая ситуация:
компания годами собирает библиотеку отовсюду:
- что-то скачали;
- что-то купили;
- что-то принёс инженер с прошлого проекта;
- что-то “вроде нормальное” нашли на BIMobject;
- что-то делали разные BIM-мастера в разные годы.
В итоге библиотека превращается в музей хаоса.
Параметры называются по-разному.
Коннекторы настроены по-разному.
Категории неправильные.
LOD у всех разный.
Геометрия избыточная.
Shared Parameters конфликтуют.
Половина семейств вообще непонятно кем создавалась.
А потом руководство спрашивает:
— “Почему BIM работает нестабильно?”
Потому что BIM очень любит порядок.
И семейства — это не “дополнение к модели”.
Это инфраструктура BIM.
Хорошее семейство — это не красивая геометрия.
Хорошее семейство — это:
- правильная категория;
- правильные коннекторы;
- понятные параметры;
- логичная структура;
- адекватная детализация;
- правильное поведение в спецификациях;
- корректная работа в системах;
- нормальная производительность.
Иногда простое семейство работает лучше, чем “супердетализированный BIM-объект”, который убивает модель.
И это одна из самых недооцененных проблем Revit.
Потому что большинство компаний начинают задумываться о качестве семейств только тогда, когда:
- модель начинает тормозить;
- спецификации ломаются;
- координация разваливается;
- Navisworks показывает хаос;
- BIM-менеджер начинает пить валерьянку литрами.
Причем самое интересное —
семейства напрямую влияют на стоимость работы компании.
Плохие семейства — это:
- потеря времени;
- ручные исправления;
- ошибки;
- проблемы на стройке;
- дополнительные часы координации;
- постоянные “почему опять не работает”.
А хорошие библиотеки — это уже конкурентное преимущество компании.
Особенно в больших BIM-командах.
Потому что сильная BIM-команда — это не только люди.
Это:
- стандарты;
- шаблоны;
- процессы;
- библиотеки;
- автоматизация.
И библиотека семейств здесь занимает одно из ключевых мест.
На практике многие BIM-отделы со временем приходят к одной и той же мысли:
проще один раз создать свою нормальную библиотеку, чем бесконечно чинить чужой хаос.
Да, это долго.
Да, это дорого.
Да, это годы работы.
Но именно это потом позволяет:
- нормально выпускать проекты;
- ускорять моделирование;
- делать стабильные спецификации;
- автоматизировать процессы;
- и не превращать каждую координацию в экспедицию по поиску древних ошибок.
