Тестируем выгрузку стен из Revit
Зачастую в проектах можно встретить два класса стен: IfcWall и IfcWallStandardCase. Обычно пользователь не назначает второй класс. Но он появляется "сам собой". Это связано с особенностями выгрузки из Revit в схему IFC2x3. Разберемся с этим.
Что говорит стандарт:
🔹 IfcWallStandardCase - класс для стен с набором слоев материала, представленных выдавливанием (SweptSolid) с постоянной толщиной вдоль траектории.
🔹 IfcWall - класс для стен с переменной толщиной, сложными сечениями или геометрией, которые не могут быть просто выдавлены.
Начиная с IFC4 сущность IfcWallStandardCase убрали, и всем стенам назначается IfcWall.
Как с этим справляется Revit?
Наш тест показал, что Revit 2021 и 2024 выгружает в IFC2x3 CoordanationView2.0 с особенностями и ошибками геометрии в обеих версиях ревита и назначением классов IfcWall только для стен, имеющих нестандартную геометрию (с врезками плит, с наклоном и т.д) .
При этом выгрузка в IFC4 ReferenceView постепенно улучшается. 24-ый ревит справился с выгрузкой без ошибок, при этом 21 версия имеет проблемы с геометрией наклонных стен.
Ранее мы писали мнение о IFC 2x3.
Наш вердикт:
Выгружаем стены в IFC4 и выше, используем новый ревит со свежим экспортером.
👥 @IFC_ru
👥 @IFC_club
Зачастую в проектах можно встретить два класса стен: IfcWall и IfcWallStandardCase. Обычно пользователь не назначает второй класс. Но он появляется "сам собой". Это связано с особенностями выгрузки из Revit в схему IFC2x3. Разберемся с этим.
Что говорит стандарт:
Начиная с IFC4 сущность IfcWallStandardCase убрали, и всем стенам назначается IfcWall.
Как с этим справляется Revit?
Наш тест показал, что Revit 2021 и 2024 выгружает в IFC2x3 CoordanationView2.0 с особенностями и ошибками геометрии в обеих версиях ревита и назначением классов IfcWall только для стен, имеющих нестандартную геометрию (с врезками плит, с наклоном и т.д) .
При этом выгрузка в IFC4 ReferenceView постепенно улучшается. 24-ый ревит справился с выгрузкой без ошибок, при этом 21 версия имеет проблемы с геометрией наклонных стен.
Ранее мы писали мнение о IFC 2x3.
Наш вердикт:
Выгружаем стены в IFC4 и выше, используем новый ревит со свежим экспортером.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Обзор библиотек для просмотра IFC в веб-приложениях
Если вы планируете создавать веб-приложения для работы с моделями, важно не ошибиться с подходящей библиотекой для отображения IFC-файлов.
Коллеги из MARKS DIGITAL сделали подробный разбор популярных решений:
🔹 Ifc.js (в настоящий момент развивается как That Open Company);
🔹 Xbim;
🔹 Xeokit.
Каждая библиотека имеет свои особенности, выбор зависит от задач проекта.
Подробнее в статье: читать
👥 @IFC_ru
👥 @IFC_club
Если вы планируете создавать веб-приложения для работы с моделями, важно не ошибиться с подходящей библиотекой для отображения IFC-файлов.
Коллеги из MARKS DIGITAL сделали подробный разбор популярных решений:
Каждая библиотека имеет свои особенности, выбор зависит от задач проекта.
Подробнее в статье: читать
Please open Telegram to view this post
VIEW IN TELEGRAM
Машинно-интерпретируемые требования: иллюзия или реальность?
Рассмотрим схему:
1. Определили цифровые требования в IDS.
2. Создали модель в IFC.
3. Сформировали отчет об ошибках в BCF.
4. Отправили данные через openCDE.
Мы часто слышим о машинно-интерпретируемых требованиях, открытых стандартах и цифровой трансформации. Но что, если это лишь верхушка айсберга? Что, если за красивыми слайдами скрывается проблема, которую предпочитают игнорировать?
На этой картинке нас смущает пункт 3 и отсутствие еще одного важного шага между 2 и 3.
🔍 Отчет в BCF - это не проверка, а лишь отчет о проверке.
Это не check, а report. И в этом кроется ключевая ошибка. Где же сам механизм проверки? Где открытые алгоритмы, которые должны лежать в основе этой системы?
Что мы имеем на текущий момент:
🛑 IDS-стандарт и его дальнейшее развитие призвано формализовать требования к информации в машинном виде.
При этом алгоритмы проверки файла на соответствие IDS находится вне файла требований, а на стороне вьюверов и чекеров.
Вопрос "подкапотной обработки" модели на соответствие требованиям решают OpenSource-проекты, наиболее известный из них - IfcOpenShell.
🛑 В России формируется реестр требований, который к 2026 году планируют перевести в машинно-интерпретируемую форму, использовав для этого разметку на базе КСИ.
При этом мы не видим ни активного движения в сторону апробации формируемых требований, ни верификационных примеров, ни открытых алгоритмов, которые бы помогли другим разработчикам ЕДИНООБРАЗНО интерпретировать и проводить проверку.
Это значит, что разработка алгоритмов проверки - это отдельная, большая задача. И она требует не только технической экспертизы, но и гарантий правильности их работы.
🔍 Реестр цифровых нормативных требований - это только начало.
Следующий шаг - это создание алгоритмов проверки. Ведь мы собираемся передать машине функции, которые раньше выполнял человек. А значит, должны быть на 100% уверены в корректности этих алгоритмов.
🔍 Представьте масштаб работы:
Создателям реестра предстоит не только описать требования, но и разработать, протестировать и внедрить алгоритмы проверки. Это приличный пласт работы, требующий больших усилий.
🔍 Подытожим:
Без открытых алгоритмов проверки вся система машинно-интерпретируемых требований останется неполной, а значит - нерабочей.
✈️ Ну и вопрос "на засыпку", готовы ли мы к такому уровню цифровизации? Или нам еще рано говорить о полной автоматизации проверок?
📢 @IFC_ru
👥 @IFC_club
Рассмотрим схему:
1. Определили цифровые требования в IDS.
2. Создали модель в IFC.
3. Сформировали отчет об ошибках в BCF.
4. Отправили данные через openCDE.
Мы часто слышим о машинно-интерпретируемых требованиях, открытых стандартах и цифровой трансформации. Но что, если это лишь верхушка айсберга? Что, если за красивыми слайдами скрывается проблема, которую предпочитают игнорировать?
На этой картинке нас смущает пункт 3 и отсутствие еще одного важного шага между 2 и 3.
Это не check, а report. И в этом кроется ключевая ошибка. Где же сам механизм проверки? Где открытые алгоритмы, которые должны лежать в основе этой системы?
Что мы имеем на текущий момент:
При этом алгоритмы проверки файла на соответствие IDS находится вне файла требований, а на стороне вьюверов и чекеров.
Вопрос "подкапотной обработки" модели на соответствие требованиям решают OpenSource-проекты, наиболее известный из них - IfcOpenShell.
При этом мы не видим ни активного движения в сторону апробации формируемых требований, ни верификационных примеров, ни открытых алгоритмов, которые бы помогли другим разработчикам ЕДИНООБРАЗНО интерпретировать и проводить проверку.
Это значит, что разработка алгоритмов проверки - это отдельная, большая задача. И она требует не только технической экспертизы, но и гарантий правильности их работы.
Следующий шаг - это создание алгоритмов проверки. Ведь мы собираемся передать машине функции, которые раньше выполнял человек. А значит, должны быть на 100% уверены в корректности этих алгоритмов.
Создателям реестра предстоит не только описать требования, но и разработать, протестировать и внедрить алгоритмы проверки. Это приличный пласт работы, требующий больших усилий.
Без открытых алгоритмов проверки вся система машинно-интерпретируемых требований останется неполной, а значит - нерабочей.
Please open Telegram to view this post
VIEW IN TELEGRAM
Всё про IFC pinned «СОДЕРЖАНИЕ 2025 (обновляется) 1. Проблемы излишней стандартизации имен файлов моделей 2. "Формат RVT - это де-факто стандарт отрасли" 3. Bonsai - еще не САПР, но больше, чем САПР 4. Как посмотреть структуру IFC-файла 5. DeepSeek и IFC. Пример запроса 6. Как…»
This media is not supported in your browser
VIEW IN TELEGRAM
Альтернативная классификация
Не хватает классов IFC?
🔍 Использование инструментов That Open Engine и JavaScript (для красоты) позволяет добавлять, редактировать и сохранять дополнительную классификацию к элементам, будь то КСИ, МССК, Uniformat, OmniClass или любую другую.
Классификационных систем в одном IFC-файле может быть несколько, в зависимости от задач.
Для кода и наименования классификатора предназначены специальные сущности IfcClassificationReference и IfcClassification. Это важно, чтобы классификатор всегда находился в одном месте, а не в произвольном параметре вроде "код по КСИ".
✈️ Напомним, что в редакторе IDS от ИСП РАН можно создавать требования с использованием альтернативной классификации (КСИ, РЖД, МССК).
👥 @IFC_ru
👥 @IFC_club
Не хватает классов IFC?
Классификационных систем в одном IFC-файле может быть несколько, в зависимости от задач.
Для кода и наименования классификатора предназначены специальные сущности IfcClassificationReference и IfcClassification. Это важно, чтобы классификатор всегда находился в одном месте, а не в произвольном параметре вроде "код по КСИ".
Please open Telegram to view this post
VIEW IN TELEGRAM
Провели встречу с замечательным человеком, BIM-лидером отрасли в части инфраструктуры Аллой Землянской (Tangl).
Обсудили перспективы открытых стандартов передачи данных в отечественных ПО.
🔹 В части цифровых требований пришли к общему мнению, что это молодое направление еще предстоит освоить как вендорам, так и заказчикам. И начинать здесь надо с малого, с IDS :) то есть с цифровизации требований заказчика.
IDS пока не может формализовать сложные проверки на техрегламенты, но на данном этапе развития технологии этого и не требуется, потому что перепрыгнуть через кучу подводных камней и перейти к полной автоматизации нормативных проверок вряд ли удастся в ближайшей перспективе. Стандартизация должна предшествовать автоматизации.
🔹 Также поговорили о передаче отчетов о коллизиях в BCF. Востребованность формата пока по большей части ограничивается госсектором и органами экспертиз. Но при обмене замечаниями через BCF-сервер, популярность его будет только расти. И такие разработки в России уже ведутся.
🔹 И затронули перспективу перехода к IFC4x3, как более проработанному и развитому в части описания инфраструктурных объектов.
👥 @IFC_ru
👥 @IFC_club
Обсудили перспективы открытых стандартов передачи данных в отечественных ПО.
IDS пока не может формализовать сложные проверки на техрегламенты, но на данном этапе развития технологии этого и не требуется, потому что перепрыгнуть через кучу подводных камней и перейти к полной автоматизации нормативных проверок вряд ли удастся в ближайшей перспективе. Стандартизация должна предшествовать автоматизации.
Please open Telegram to view this post
VIEW IN TELEGRAM
Ежемесячный подкаст "BIM-среда" в IFC Клубе!
В группе мы часто репостим классные кейсы с канала MARKS DIGITAL. Коллеги хорошо продвинулись в использовании разных ПО. В эту среду автор канала у нас в гостях!
🗓️ Среда, 2 апреля, в 16-00 МСК
🔊 Тема: "Без права на ошибку: Транспортная инфраструктура в IFC"
Гость:
👤 Филипп Сергеев, Руководитель MARKS DIGITAL, заместитель генерального директора по цифровым технологиям MARKS GROUP
Поговорим о:
🛑 особенностях проектирования объектов инфраструктуры;
🛑 опыте прохождения экспертиз с моделями в IFC 👀 ;
🛑 экспорте в IFC из Rhino;
🛑 применении Bonsai / BlenderBIM для решения нетривиальных задач по доработке IFC-файлов ⚡️ ;
🛑 использовании BCF для обмена замечаниями;
🛑 проверках модели по IDS-требованиям без bonsai;
🛑 и много другом!
Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.
👥 @IFC_ru
👥 @IFC_club
В группе мы часто репостим классные кейсы с канала MARKS DIGITAL. Коллеги хорошо продвинулись в использовании разных ПО. В эту среду автор канала у нас в гостях!
Гость:
Поговорим о:
Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.
Please open Telegram to view this post
VIEW IN TELEGRAM
Составные_части_ЦИМ_проект_Приказа_Минстроя_РФ.ids
7.4 KB
Проект приказа Минстроя о составе ЦИМ в IDS!
На публичное обсуждение размещен проект приказа Минстроя России об утверждении состава ЦИМ на этапе проектирования.
И многие уже успели его обсудить. Но мы решили на этом не останавливаться и сделали по этому проекту IDS-требования (по таблице 1).
Помимо того, что проект приказа требует изменений в формулировках, также нужны уточнения в самих таблицах.
Так, для элементов инженерных систем введены слишком обобщенные понятия (например, «Оборудование»). В результате не совсем понятно, что конкретно в них входит.
С точки зрения целей применимости ЦИМ на этапе проектирования к проекту приказа есть вопросы, но в техническом плане он вполне выполним (после ряда доработок).
👥 @IFC_ru
👥 @IFC_club
На публичное обсуждение размещен проект приказа Минстроя России об утверждении состава ЦИМ на этапе проектирования.
И многие уже успели его обсудить. Но мы решили на этом не останавливаться и сделали по этому проекту IDS-требования (по таблице 1).
Помимо того, что проект приказа требует изменений в формулировках, также нужны уточнения в самих таблицах.
Так, для элементов инженерных систем введены слишком обобщенные понятия (например, «Оборудование»). В результате не совсем понятно, что конкретно в них входит.
С точки зрения целей применимости ЦИМ на этапе проектирования к проекту приказа есть вопросы, но в техническом плане он вполне выполним (после ряда доработок).
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
RUTUBE
#16= Без права на ошибку: Транспортная инфраструктура в IFC (Филипп Сергеев, 02.04.2025)
Ежемесячный подкаст "BIM-среда" в IFC Клубе! (https://www.tgoop.com/IFC_club)
🗓️ Среда, 2 апреля, 16-00 МСК
🔊 Тема: "Без права на ошибку: Транспортная инфраструктура в IFC"
Гость:
👤 Филипп Сергеев, Руководитель MARKS DIGITAL, заместитель генерального директора…
🗓️ Среда, 2 апреля, 16-00 МСК
🔊 Тема: "Без права на ошибку: Транспортная инфраструктура в IFC"
Гость:
👤 Филипп Сергеев, Руководитель MARKS DIGITAL, заместитель генерального директора…
Начинаем новую рубрику:
Проверь себя в🌐 IFC
🕙 Один вопрос каждую пятницу в 10:00
Проверь себя в
Please open Telegram to view this post
VIEW IN TELEGRAM
№1. Сколько проектов (IfcProject) может содержать файл IFC?
Anonymous Quiz
17%
Не более 1
45%
Только 1
3%
Не менее 1
19%
Сколько угодно
15%
Не знаю
Сегодня завершился десятый (!) курс по технологиям информационного моделирования.
Спасибо всем, кто был с нами: «Росатому» и другим организациям за неудобные вопросы, споры и за то, что делились своим опытом. Для нас курс стал еще одной ступенькой в развитии.
Мы старались сделать курс максимально честным и детальным: разобрали BIM-подходы в мировом контексте, в российской практике, в экспертизе и даже в узких отраслевых нюансах. От Градкодекса до коллизий в IFC.
С 2021 года курс прилично «прокачался»:
🔹 добавили больше материала про работу с IFC и создание цифровых требований;
🔹 сместились акценты в сторону работы с заказчиком и правильному составлению ТЗ на модель.
Особая благодарность Ольге Кутузовой (@Kutuzova_O, NSR-Specification) и Николаю Самопалу (@NS_BIM, Wizardsoft) - на ваших лекциях мы тоже учимся.
👥 @IFC_ru
👥 @IFC_club
Спасибо всем, кто был с нами: «Росатому» и другим организациям за неудобные вопросы, споры и за то, что делились своим опытом. Для нас курс стал еще одной ступенькой в развитии.
Мы старались сделать курс максимально честным и детальным: разобрали BIM-подходы в мировом контексте, в российской практике, в экспертизе и даже в узких отраслевых нюансах. От Градкодекса до коллизий в IFC.
С 2021 года курс прилично «прокачался»:
Особая благодарность Ольге Кутузовой (@Kutuzova_O, NSR-Specification) и Николаю Самопалу (@NS_BIM, Wizardsoft) - на ваших лекциях мы тоже учимся.
Please open Telegram to view this post
VIEW IN TELEGRAM