Всё про IFC

Встречайте, Lapin! Это полноценная бесплатная BIM-система на базе стандарта IFC. Что можно делать: - да всё! строить стены, перекрытия, двери и окна и многое другое как полноценные IFC-элементы со своими слоями, типами и свойствами. - формировать планы, разрезы, фасады и чертежные листы, которые можно экспортировать в форматы PDF и DXF. - над одним проектом можно работать совместно с другими пользователями в режиме реального времени. - создавать календарный план. - проверять на коллизии и выгружать в BCF. - и много чего еще. Очевидно, за рубежом наблюдается интересная тенденция в сфере САПР: сначала Bonsai, потом BIMCraft, теперь еще и Lapin. Подробнее тут: - Видеоуроки по Lapin - User гайд - Ссылка на гитхаб - и еще видеообзорчик со стороны @ifc_ru @ifc_club

🚀 Мини-курс «Постобработка IFC в Blender + Bonsai: начинающий уровень» уже доступен! Никогда не открывали Blender + Bonsai и не знаете, с чего начать? Этот курс — для вас. 🎓 Мы подготовили базовый минимум знаний, который поможет освоиться в ПО и начать решать прикладные задачи по постобработке IFC-файлов. Начнём с установки и знакомства с интерфейсом, а затем перейдём к практике. Что будем делать: 🔹 Менять схему и классы IFC, перестраивать структуру модели и работать с контейнерами. 🔹 Создавать и редактировать параметры, выгружать данные в Excel и использовать его для пакетного заполнения параметров. 🔹 Проверять модели по IDS и подключать связанные модели. 🔹 Извлекать нужные элементы и объединять несколько IFC-файлов в один. ⏱️ 16 коротких уроков — 1 час 34 минуты. 💻 Предварительные знания не требуются. 🙌 Бесплатно для всех желающих. 👉 Перейти к курсу: Постобработка IFC в Blender + Bonsai: начинающий уровень 🔐 Для доступа к курсу необходимо зарегистрироваться на сайте и войти в свой аккаунт. Без регистрации материалы курса недоступны. Интересны более сложные кейсы работы в Blender + Bonsai? Ставьте 🔥 — так мы поймём, что вам интересно продолжение! 📩 Если появятся вопросы или предложения по курсу, пишите нам на info@marksdigital.ru — будем рады помочь и услышать ваши идеи!

Требования к ЦИМ в формате IDS от Мособлэкспертизы Мособлэкспертиза разработала новую редакцию требований к ЦИМ, в том числе в формате IDS: - Требования к ЦИМ автомобильных дорог и улично-дорожной сети. - Требования к ЦИМ наружных инженерных сетей. - Требования к ЦИМ производственным и непроизводственным ОКС. > СКАЧАТЬ < @IFC_ru @IFC_club

А вот интересное: из вот этого видео: https://www.youtube.com/watch?v=Ksz-9552gKY (канал крайне рекомендую, автор использует FreeCAD в около-IFC темах) узнал про вот этот визуальный редактор IDS: https://www.idsedit.com/ Пара но: • Ссылка открылась только из-под ВПН; • Как и бывает с подобными визуальными редакторами, с более-менее серьёзной спецификацией (IDS СПб ГАУ ЦГЭ (Конструктивные решения).ids, например) уже неудобно.

О методическом пособии по созданию цифровых требований: как исправить проблемы (часть 2/2) Попробуем предложить решения проблемы. Важность создания методики мы не будем отрицать, но надо подумать над интеграционным фундаментом, когда бы нас понимали все, а не только в рамках данной методики. Порассуждаем над конкретными шагами, как исправить ситуацию: 🛑 Устранить семантический разрыв. Не вводить новый формат, а надстраиваться над тем, что есть. Для этого надо признать, наконец, IFC основным стандартом представления данных и создать надстройку. А надстройка - это IDS, работающий инструмент для описания описания проверок. Он уже живёт, развивается, под него пишут функционал. Его можно и нужно дорабатывать. Синхронизироваться с мировым опытом и национальными разработками в рамках ТК 505, а не загонять самих себя в технологическую изоляцию. Также не мешало бы скоординировать работу с разработчиками национального расширения IDS-стандарта. 🛑 Не описывать сущности в требованиях кодами по КСИ. КСИ - важный справочник, но его коды не должны жестко вшиваться в структуру требований. В IFC есть механизм, присваивать элементам классификационную ссылку через IfcClassification и IfcClassificationReference. Это позволяет гибко использовать КСИ и любой другой классификатор одновременно, без переписывания правил. 🛑 Использовать стандартные свойства IFC и всю его мощь как онтологии. На первом этапе вместо введения тысяч новых полей - разработать таблицу мэппинга произвольных свойств требований к стандартным наборам IFC (Pset_ и Qto_). Хотите проверять "Предел огнестойкости"? Сопоставьте это требование со стандартным свойством FireRating из Pset_WallCommon. На следующем этапе - начинать работать со связями. Предлагаемый путь - это переход от создания "ещё одного формата" к интеграции методики в существующую онтологию данных строительной отрасли, описанную в IFC. Это снимет ряд технических противоречий, устранит двойные трудозатраты и, главное, даст на выходе практический инструмент для сложных междисциплинарных проверок. Кратко: - IFC - как базовый фундамент; - механизм классификационных ссылок для гибкости; - таблицы мэппинга свойств и использование связей IFC; - развитие IDS. 👥 @IFC_ru 👥 @IFC_club

О методическом пособии по созданию цифровых требований (часть 1/2) "НИЦ ЦПС" по заказу ФАУ "ФЦС" разработал методическое пособие по созданию цифровых требований для проверки ЦИМ. Мы не можем пройти мимо этого документа, так как направляли в ФАУ "ФЦС" наши комментарии по нему, но они остались без ответа. Проанализируем документ и обозначим некоторые вопросы. Сразу обозначим, что создавать формат для требований без привязки к формализованной схеме данных - это как писать правила дорожного движения, не зная, какие бывают машины, дороги и знаки. Здесь предполагается ввести свой «язык» описания проверок, игнорируя тот факт, что модели уже давно представляются по стандарту IFC (ГОСТ Р 10.0.02-2019). К чему это приведёт на практике? 🔴 Семантический разрыв. Требования будут описывать одни сущности и связи, а данные в IFC-модели будут содержать другие. Глухой телефон. 🔴 Эпоха коннекторов. Вместо следования единому стандарту каждой системе автоматизированной проверки придется писать собственный "переводчик" с языка методики. Это приведет к двойным трудозатратам для всех: и для составителей требований, и для разработчиков ПО. 🔴 Методика делает ставку исключительно на КСИ. Но строительная отрасль им не ограничивается: используются МССК, отраслевые классификаторы РЖД и т.д. Привязка только к КСИ не только игнорирует это, но и делает всю систему заложником его частых обновлений (4+ раза в год!): все созданные ранее правила проверок придется постоянно актуализировать из-за возможной смены кодов. 🔴 Игнорирование IFC. Самое тревожное - подход заточен только под проверку атрибутов ("параметров"). Он игнорирует мощь объектно-ориентированной модели IFC как онтологии: типизированные связи, наследование свойств - не слышали? Скатываясь к примитивному способу проверок, их ценность просто потеряется. И тогда зачем это всё? Создавать изолированный язык для проверок - это методологический тупик. Мы рискуем получить стройный, но, к сожалению, бесполезный реестр требований. Проверка моделей на эти требования не будет иметь большой значимости и смысла. Далее напишем - как попытаться всё поправить. @IFC_ru @IFC_club

Коллизии. Новый взгляд? (Дополнение) Над предложенным выше делением коллизий еще стоить поработать, но здесь важен сам подход. Кстати, он принципиально отличается от того, что предлагается в ЕСИМ, где дефекты подразделяются на: 🔴 устранимые и неустранимые (по возможности исправления); 🔴 скрытые и явные (по вероятности/сложности обнаружения); 🔴 критические и некритические (по приоритету). Подход ЕСИМ лежит в другой плоскости. И это никакая не классификация по типам коллизий (как нас уверяют разработчики стандартов), а их статусы, так как эти характеристики подойдут предложенных нами типов. Но с ними можно согласиться и даже расширить, так как с их помощью можно будет определять уровень риска коллизии. А это может улучшить практику управления проектом. То есть оба подхода могут друг друга хорошо дополнить. 1️⃣ Структура по типам коллизий даст удобную навигацию и поможет найти источник проблемы, а также назначить исполнителя. 2️⃣ Оценка риска дефекта позволит понять последствия и вовремя предпринять нужные решения. 👥 @IFC_ru 👥 @IFC_club

Коллизии. Новый взгляд? Продолжаем тему коллизий. Сегодня сложилось обывательское убеждение, что «проверка на коллизии» - это про геометрические пересечения. А во времена BIM-стандартов от вендоров предлагалось что-то странное: жесткие коллизии, мягкие, газообразные… Это аналогично 4D, 5D, 6D, 7D. Проблема в том, что пока не посмотришь, что это значит, не поймешь, о чем речь. В результате - недопонимание и проблемы в коммуникации. Поразмыслив мозгами, давайте попробуем переработать эту концепцию, и подумаем, как навести порядок в коллизиях и проверках. 🔍 В приложенном ниже файле я предложил структуру типов коллизий/дефектов, выявляемых в результате верификации и валидации. Коллизии представлены шире, чем только геометрические. На истину не претендую, просто предложение. 🔹 При верификации выявляются дефекты в синтаксисе и семантике набора данных (файла IFC, XML-документа и т.д.). Например, в IFC-файле обнаружен GUID, начинающий с буквы, хотя по правилам в IFC он должен начинаться с цифры. 🔹 При валидации проверяем данные на различные семантические требования (в том числе высокого уровня: нормативные требования). Это лишь набросок, но такое деление добавит системности и в перспективе не позволит упустить ни одну категорию проверок и будет основой для дальнейшей автоматизации. 👥 @IFC_ru 👥 @IFC_club

СОДЕРЖАНИЕ 2026 (обновляется) 1. Коллизии. Новый взгляд? + иерархия коллизий 2. Коллизии. Новый взгляд? Дополнение. 3. 4. 5. 6. 7. Подкасты "BIM-среда" на Youtube 📹 | Rutube 📺 👥 @IFC_ru 👥 @IFC_club

СОДЕРЖАНИЕ 2025 1. Проблемы излишней стандартизации имен файлов моделей 2. "Формат RVT - это де-факто стандарт отрасли" 3. Bonsai - еще не САПР, но больше, чем САПР 4. Как посмотреть структуру IFC-файла 5. DeepSeek и IFC. Пример запроса 6. Как подружить элементы и документы в IFC 7. Проверка IFC моделей по требованиям IDS (статья) 8. Связи BIM-стандартов ISO 9. Тестируем выгрузку стен из Revit 10. Обзор библиотек для просмотра IFC в веб-приложениях 11. Машинно-интерпретируемые требования: иллюзия или реальность? 12. Интероперабельность. Роль заказчика и разработчика ПО 13. Альтернативная классификация. Что делать, если не хватает классов IFC? 14. Встреча с Аллой Землянской. О цифровых требованиях IDS 15. Проект приказа Минстроя о составе ЦИМ в IDS 16. Что нового в Revit 2026 в части IFC 17. Завершился 10-ый курс по ТИМ 18. ИИ-классификация элементов на основе геометрии в Qonic 19. IfcBuildingElementProxy: удобный костыль или скрытая проблема? 20. IfcBuildingElementProxy: причины (зло)употребления 21. IfcBuildingElementProxy: как классифицировать элементы и расширить классификацию 22. 7D Modeler 1.5: новый релиз! 23. Список MVD для IFC4x3 дополнен 24. О новых типах объектов в IFC4x3 25. Открытый веб-валидатор IFC 26. 10 шагов по созданию корпоративного стандарта на базе IFC 27. О вариантах структуры IFC-проекта 28. Автоматизированный перевод IDS-требований в атрибуты ЦИМ 29. Топоматик 360 с крутыми возможностями! 30. Разбираем ТЗ на ЦИМ - 1. О классификации 31. Разбираем ТЗ на ЦИМ - 2. О делении модели на разделы 32. 1-ое место в ТИМ-лидерах! 33. О делении составных элементов на части 34. Разбираем ТЗ на ЦИМ - 3. Об информационном наполнении элементов 35. Разбираем ТЗ на ЦИМ - 4. О несоответствии атрибутивного состава целям моделирования 36. 1000 подписчиков! 37. Всё, что нужно знать про IFC5 38. Разбираем ТЗ на ЦИМ - 5. Проблема LOD 39. ПНСТ 909-2024 "Жилые здания" в IDS! 40. Разбираем ТЗ на ЦИМ - 6. О матрице коллизий 41. Цикл постов с разборами ТЗ на ЦИМ 42. Еще раз о проекте приказа Минстроя о составе ЦИМ (презентация) 43. Выгрузка в IFC из Revit. Без Revit 44. Структура в инфраструктуре 45. Атрибутивка из требований прямо в IFC - это реально. Без нативных форматов 46. Как совместить IFC-модель с чертежами 47. Связка IFC и чертежей: проблема целостности данных 48. IfcCheckingTool_Lite - инструмент проверки семантической и синтаксической корректности IFC 49. Способы связки чертежей с моделями в IFC 50. Ежегодный форум РосТИМ 2025 51. Перевод реестра требований в цифровой вид. Презентация ИСП РАН 52. Предновогодний анализ постов через ИИ Проверь себя в IFC: Вопрос №1 Вопрос №2 Вопрос №3 Вопрос №4 Вопрос №5 Вопрос №6 Вопрос №7 Вопрос №8 Вопрос №9 Вопрос №10 Вопрос №11 Вопрос №12 Вопрос №13 Вопрос №14 Подкасты "BIM-среда" на Youtube 📹 | Rutube 📺 👥 @IFC_ru 👥 @IFC_club

Предновогодний прогон всех постов канала через ИИ (+статистика от TGStat) В дополнение к статистике от ТGStat пропустили через ИИ все посты нашего канала. И вот что он сказал: В лидерах по темам в 2025 году оказались: 1. Цифровые требования (IDS) и их развитие – 14 постов 2. Критика и разбор нормативных документов – 11 постов и упоминаний 3. Разбор ТЗ на ЦИМ (серия постов) – 10 постов и упоминаний 4. Инструменты для работы с IFC – 9 постов и упоминаний 5. IFC-структура, классы и связи – 8 постов 6. Интеграция ИИ и IFC – 7 постов 7. OpenBIM и открытые стандарты – 6 постов 8. Связь чертежей и IFC-моделей – 5 постов и упоминаний 9. Обучение и курсы – 4 поста 10. Инфраструктурные объекты и IFC – 4 поста 11. Прочие темы – 5 постов 💻 Самый популярный пост 💻 Вывод от ИИ:

2025 год стал годом цифровых требований (IDS) и глубокого анализа нормативной базы. Канал активно продвигал переход от «бумажных» стандартов к машиночитаемым форматам, критиковал противоречия в документах Минстроя и показывал практические инструменты для работы с IFC.

Главный месседж канала 2025 года по версии DeepSeek:

«IFC — это не просто формат обмена геометрией, а онтология для управления данными на всём жизненном цикле. Цифровые требования (IDS) и открытые стандарты — основа цифровой зрелости отрасли.»

Всех с Наступающим! 🎄 @IFC_ru 🎄 @IFC_club

BIM-форум: поговорим про чертежи и модели Завтра приму участие в Круглом столе «ЦИМ как отказ от чертежей: все «за» и все «против». Тема стара как мир, но вновь и вновь всплывает в BIM-среде. Для нее были поводы и у нас на канале: 🟡 XML-бомба, способная изменить всё! 🔵 BIM-среда: «Экспертиза без чертежей: ожидания и реальность» (гость: Сергей Сербин) и наше мнение о пилоте 🟣 Как совместить модель в IFC с чертежами 🔴 Связка IFC и чертежей: проблема целостности данных 🟢 Способы связки чертежей и модели в IFC Завтра обсудим эту важную и сложную тему с разных сторон. До встречи!

В Москве проходит ежегодный форум РосТИМ 2025 от Аскон. Неожиданно для себя получил награду за «популяризацию правильных подходов» по работе с открытыми форматами. Друзья! Искренне радует, что нашу деятельность оценивают и разработчики ПО. А значит, надеюсь, мы движемся в нужном направлении. Этот канал - это только часть нашей деятельности, здесь всё на энтузиазме. И хотя постов стало чуть меньше (в связи с загрузкой под конец года), но я считаю, что лучше писать что-то интересное и по делу, чем просто написать что-нибудь о BIM. 👥 @IFC_ru 👥 @IFC_club

Это нельзя не отрепостить) Спасибо Анастасии Кирюшиной за любовь к нашему каналу. Это взаимно, хотя стиль и контент разный. И некоторые цитаты я бы сам уточнил (всё-таки некоторым уже год и более), но мне больше интересен факт выбора именно этих цитат.

👽 А вот и карточки по мотива статьи "Тренд на IFC" ➡️ ССЫЛКА НА СТАТЬЮ ⬅️ ❤️ Будь в тренде, залетай на планету информационного менеджмента @letsmanagebim #LETSread

Способы связки чертежей с моделями в IFC. Ранее мы говорили, что для связки модели и чертежей необходимо обеспечить целостность данных в ИМ ОКС. Стремления закрепить в Градкодексе цифровую информационную модель только усилит эту необходимость. И раз уж решили идти по этому пути, то сразу надо подумать наперед о том, как: 1️⃣ обеспечить единовременную выгрузку модели и листов чертежей из САПР; 2️⃣ связать 2D-объекты на чертежах с элементами модели; 3️⃣ связать табличные данные (ведомости и спецификации) с элементами модели; 4️⃣ обеспечить возможность просмотра видов (разрезов, сечений) в пространстве модели вместе с аннотациями и штриховками чертежа. 🔍 Способ 1. Связь IFC и SVG По этому пути двигается Bonsai (ex. BlenderBIM). Виды и аннотации создаются в редакторе, сохраняются в IFC. Сам лист чертежа оформляется и экспортируется в популярный векторный формат SVG с XML-разметкой, где 2D-объекты имеют IfcGUID для связи с элементами модели. И тут каждый SVG-файл - это отдельный лист чертежа. Из минусов: не решена проблемы 1 и 4. 🔍 Способ 2. Связь IFC и XPS Формат XPS создавался как замена PDF, но с XML-разметкой, и в этом его главный плюс. Спецификация формата зарегистрирована как открытый международный стандарт. В отличие от SVG имеет постраничную структуру, как и PDF, и может содержать в одном файле множество листов чертежей. Связь между моделью и чертежом также реализуется с помощью IfcGUID. Старый формат DWFx от Autodesk был реализован на базе XPS. Выгрузка чертежей в XPS есть у Renga, правда IfcGUIDов мне в нем найти не удалось. У первых двух способов важно, чтобы САПР сохранял виды/разрезы в IFC. Не каждое ПО это умеет. Но почти каждое умеет работать с отчетами в BCF, а значит: 🔍 Способ 3. Связь IFC и BCF Идея принадлежит Игорю Шерстенникову: настраиваются нужные виды с координатами камеры и ракурсом и выгружаются в BCF, который может содержать скриншот чертежа. Понадобится только автоматически наложить аннотации на каждом виде и смотреть их в пространстве модели. Но тут возникают доп вопросы, как будут созданы аннотации в IFC? Подход сейчас проходит апробацию и есть первые результаты. Этот способ подразумевает уход от оформления листов, а это рождает описанные ранее проблемы. Конечно, есть еще вариант полностью отказаться от чертежей, но пока тут много подводных камней. 👥 @IFC_ru 👥 @IFC_club