Что такое ifc формат
Формат IFC
Если коротко, то формат Industry Foundation Classes (IFC) предназначен для описания данных об архитектуре, проектировании и строительстве и был создан по инициативе Autodesk.
Сразу надо отметить, что IFC не является форматом обмена данными для дальнейшего редактирования. Т.е модель в формате IFC не подходит для продолжения работы с ней после импорта в любую BIM программу. Для чего же можно его использовать? Например, если вашему заказчику понадобится весь проект или его раздел в формате IFC.
Richard Junge взяв за основу STEP, поставил задачу разработать формат, который станет независимым от производителей САПР. Его идея заключалась в том, чтобы весь процесс от проекта до строительства и управления зданием упростить и ускорить. В отличие от традиционного обмена 2D-линиями и 3D-данными объема, IFC должен был предоставить пользователю кросс-программную «интеллектуальную» модель данных. Например, инженер-строитель мог бы изменить или расширить модель данных с учетом статических требований и вернуть изменения архитектору без потерь. Планировщик строительных услуг также мог бы использовать эту информацию для планирования маршрута. Также должны были бы учитываться все изменения модели, т.е. документироваться. Patrick MacLeamy, американский архитектор и председатель BuildingSMART, перенес тему в Соединённые Штаты. Дальнейшая разработка формата IFC осуществлялась Autodesk и в 1994 году Autodesk зарегистрировала формат IFC на своё имя.
Борьба за рынок CAD продолжается по всему миру. Сегодня всё BIM можно разделить на два типа: ClosedBIM – использование в проектировании программы одного производителя, OpenBIM – работа с открытым форматом данных, который должен автоматически читаться другими программами.
Ярким представителем ClosedBIM сегодня является Revit. Он безвозвратно изменил представление пользователей CAD-программ об интерфейсе, простоте использования и быстроте проектирования. Его прародитель, софт Pro/Engineer в середине 90-х был глобальным лидером на западном рынке конструкторского проектирования машиностроительной промышленности. Цель его состояла в том, чтобы создать систему, которая была бы достаточно гибкой, чтобы побудить инженера легко рассматривать различные конструкции, а затраты на внесение изменений в проект должны быть минимальны. Начав в 1996 году команда разработчиков Revit, используя твердотельное параметрическое моделирование с концепцией единой модели данных для всего проекта, создала радикально новый подход к программному обеспечению для строительства. В 2002 году стартап Revit купила компания Autodesk. К сожалению, и, как ни странно, формат IFC трудно стыкуется c программами от Autodesk.
Европейские производители САПР после опубликования формата IFC пытаются его использовать. Например, Graphisoft утверждает, что программа ArchiCAD идеально подходит для работы с этим форматом и говорит о “99 процентной” работе с IFC данными. Правительства многих европейских стран уже давно сделали использование формата IFC обязательным для проектов строительства с государственной помощью. Главным по ОpenBIM в Европе является Nemetschek Group с двумя подразделениями Allplan и Archicad.
Какую роль играет наше государство в вопросах контроля и установления правил по обменным форматам? Оно следует примеру европейцев и похоже, заинтересовано в развитии OpenBIM. Министерство строительства и жилищно-коммунального хозяйства РФ и ФАУ «Федеральный центр нормирования, стандартизации и оценки соответствия в строительстве» в 2017 г разработало методические указания по обеспечению интероперабельности при информационном моделировании объектов строительства.
В данном документе указано, что IFC разработан как формат, который используется как промежуточный при обмене данными между другими форматами программных средств. Он структурирован для передачи данных, а не для поддержки функциональности. Например, он не поддерживает параметрическую геометрию, содержит данные о размерах, но не содержит информации, какие геометрические объекты контролируют эти размеры. Эффективно импорт IFC создает статические объекты, которые больше не редактируются. После импорта статической информационной модели без тщательной проверки каждого элемента нельзя быть уверенным в полной репликации всего объема данных. Посте того, как были внесены изменения в информационную модель с помощью программного обеспечения, экспорт обратно в IFC также проблематичен. Если была изменена только часть здания, остается вопрос ее интеграции в исходную модель IFC. Если все здание будет экспортировано обратно, заменив оригинальную модель IFC, то появится задержка во времени, которая означает различия в содержании данных, или проблемы, возникающие, если модель IFC должна использоваться и в других программных комплексах в процессе проектирования.
Статической модели IFC оказывается достаточно для выполнения анализа с помощью аналитического программного обеспечения. Однако если вы хотите изменить модель на основе результатов анализа, то IFC не позволит этого сделать. Так, на сайте Archicad отмечается, что при импорте IFC-модели некоторые элементы, определенные как IfcWall, IfcSlab и т.д., импортируются как объекты, а не как стены, перекрытия и т.д. Причина заключается в их упрощенном геометрическом BREP-представлении, задающем «наружную поверхность» или «контурное представление». Это означает, что кроме геометрической формы элемент не включает никакой другой информации, например, нет его привязки к осевым линиям. Таким образом, при проектировании конструкций со сложной геометрией в случае обмена данными по стандарту IFC приходится сталкиваться с потерей информации.
Стандарт формата IFC регулярно обновляется, регулярно обновляются программные средства, изменяются их функциональность. Некоторые классы удаляются, другие изменяются и добавляются новые. Нет гарантии, что все сохраненные файлы всегда будут корректно читаться программными средствами в будущем.
Существует ряд инициатив по созданию стандартов компонентов BIM, таких как Национальная библиотека BIM в Великобритании NBS (UK NBS National BIM Library). Но в NBS Великобритании пришлось использовать файлы проприетарного формата из-за отсутствия необходимой функциональности файлов IFC. Тем не менее, возможно появится способ для создания файловой схемы компонента IFC.
Альтернативой использованию формата IFC для обмена данными является использование специальных инструментов программного обеспечения для обмена данными:
– программные решения одного производителя САПР на основе внутренних форматов и прямых API-интерфейсов (интерфейс прикладного программирования);
– программные решения различных производителей САПР на основе проприетарных форматов и прямых API-интерфейсов.
Многие специалисты BIM считают, что формат обмена IFC не соответствует в полной мере их требованиям к обмену данными. Обсуждение данного вопроса и совместной работы постоянно ведется основными BIM-вендорами, такими как, Trimble, Graphisoft, Hexagon, Nanosoft, Aveva, Renga, Dassault Systemes, Allplan, Cadmatic, CSoft Development и пр. В основном ими приветствуется концепция OpenBIM. Причин тому много. И то, что нет такой ClosedBIM (или SuperBIM) которая бы в полной мере обеспечивала все разделы проектной документации, расчет и дальнейшую эксплуатацию. И то, что чем больше проект, тем больше независимых участников. Многие производители САПР понимают, что увеличения использования их софта можно добиться, если предлагать помощь своим клиентам в интеграции и сами разрабатывают какие-либо решения. Именно европейские вендоры активно развивают конвертеры, адаптеры и сервисы с сохранением всей геометрией и атрибутивной информацией. Например, eShare – веб-портал для визуализации, обмена и интеграции проектных, строительных и эксплуатационных данных о промышленном объекте на основе BIM модели компании Cadmatic, Bimplus – открытая платформа для совместной работы над проектами на основе BIM-модели для строительной отрасли компании Allplan.
Заказчики строительства, производители строительных материалов и инженерного оборудования используют решения различных САПР и заинтересованы в том, чтобы все САПР в полном объеме интегрировались друг с другом. Или хотя бы быстрее появлялись цепочки использования программных решений.
Различие интересов участников такого сложного процесса как строительство от инвестора и проектировщика до управляющей и эксплуатирующей компании слишком велико. Это и вопросы интеллектуальной собственности, и финансовых результатов, и различного рода ответственности. Хотя, казалось бы, что от автоматизации процессов и прозрачности должны выиграть все. Как будет развиваться данный аспект BIM трудно предсказывать. Возможно наступит время, когда информация по проекту не будет задерживаться у отдельных компаний, а будет передаваться автоматизировано и прозрачно в единую модель проекта.
Интероперабельность имеет решающее значение для успеха BIM. Разработка открытых стандартов данных и «незарегистрированного» доступа к данным BIM является внеочередным приоритетом для отрасли, если мы хотим избежать недостатков и повторения нерешенных проблем повторного ввода данных. Интероперабельность вместе с IFC позволит повторно использовать проектные данные, которые уже разработаны и, таким образом, обеспечить согласованность между каждой из моделей для различных представлений одного и того же здания. Последовательные, точные и доступные данные для всей проектной группы внесут значительный вклад в смягчение последствий задержек и дополнительных расходов, по словам.
Есть и другие приложения, такие как Bentley Architecture и Autodesk Architectural Desktop, которые разработали свои модели данных здания на основе своих оригинальных платформ в CAD: MicroStation и Auto CAD соответственно.
Все эти приложения имеют свои внутренние структуры данных в «формате заказчика». Это означает, что они не могут обмениваться информацией друг с другом, если для того нет переводчика.
IFC был разработан для того чтобы создать большую группу непротиворечивых данных, способных представлять собой модель данных здания, позволяя, тем самым, обмен информацией между различными производителями программного обеспечения в отрасли архитектурного и технического проектирования и строительства. IFC проявляется в этом контексте в качестве модели данных перевода, в формате, который «никому не принадлежит», доступном для определения объектов в сфере архитектурного и технического проектирования и строительства. Тем не менее, это не стандартизирует структуры данных в программных приложениях, и ограничивается только стандартизациями совместно используемой информации.
buildingSMART определяет IFC как схему данных, которая позволяет хранение данных и обмен информацией между различными приложениями BIM.
Схема IFC является расширяемой и располагает информацией, охватывающей множество дисциплин, которые вносят вклад в здание в течение его жизненного цикла с момента разработки концепции, проектирования, строительства, до реконструкции или сноса.
IFC зарегистрирован Международный организацией по стандартизации (ИСО) как ISO-PAS-16739 (2005) и принят в качестве официальной нормы.
IFC – это схема спецификаций, которая обеспечивает способы определения и понимания информации, отношений и конкретных свойств объектов здания, а также то, что они находятся в модели BIM.
IFC, с технической точки зрения, определен с помощью спецификации нормы ISO 10303-11 для моделирования и обмена данными, также именуемой Стандартом для обмена данными по изделию STEP. ISO начала разработку спецификации (формата данных) STEP в 1984 г. с целью определения стандартов для общего представления и обмена информацией, а также стандарт STEP используется во многих сферах, таких как машиностроение и проектирование. Специалисты, которые первоначально были вовлечены в разработку стандарта STEP, создали МАИ (Международный альянс по интероперабельности) для разработки конкретных стандартов отрасли архитектурного и технического проектирования и строительства.
IFC использует ресурсы на основе стандарта STEP и такой же язык моделирования, который называется EXPRESS.
Из всех технологий преобразования ISO 10303 21 (2002) является одной из наиболее значимых в условиях интероперабельности, которая эффективно определяет формат файла IFC. Текущая разработка модели IFC находится в ведении buildingSMART.
IFC разрабатывается с 1997 года, когда еще была выпущена версия 1.0, и в наши дни после последовательных и систематических обновлений IFC был выпущен под версией 4×2 Addendum 2 в начале 2015 года. Версии проходят через модификации и разработки для того, чтобы лучше представить сущности и отношения в здании и в его жизненном цикле.
Поскольку это нейтральный и открытый формат данных, компании-разработчики программного обеспечения могут разрабатывать способы экспортирования данных IFC. Для того чтобы это осуществить, приложение должно быть «IFC-совместимым», процесс сертификации должен производиться путем создания технологии SMART. В наши дни существуют около 204 программ, сертифицированных в качестве «IFC-совместимых».
Обзор архитектуры IFC
Для того чтобы понять суть IFC в целом используется концептуальная схема Рисунка 1. Для упрощенного описания данной структуры пересматривались и резюмировались концепции в работах Истмана и др. (2008 г.), Хемлани (2004 г.), а также информация справочного сайта buildinSMART по IFC (2012b).
Рисунок 1: Общая схема IFC версии 2х3
Источник: Взято из buildingSMART
В данной структуре представлены четыре слоя, которые будут описаны последовательно сверху вниз:
Слой ресурсов > Основной слой > Слой совместимости: Общие элементы > Слой доменов
Слой ресурсов
Данный слой является основой, состоящей из сущностей, которые, как правило, используются в объектах отрасли архитектурного и технического проектирования и строительства, таких как геометрия, топология, материалы, системы измерений, ответственные посредники, представление, расходы, и т.д.
Основной слой
Все сущности данного слоя исходят из корневого каталога IFC и содержат в себе абстрактные сущности, на которые ссылаются более высокие слои в иерархии. Основной слой подразделяется на четыре дополнительных подслоя: Контроль, Продукт, Процесс и Основа.
Подслой Основа представляет собой базовую структуру, которая является отношением и общими основными понятиями для всех дополнительных специализаций в конкретных моделях, в которых основные понятия определяются как группа, процесс, продукт и отношения.
Дополнительная схема продукта определяет абстрактные строительные компоненты, такие как пространственные, локальные, строительные, элементные. Дополнительная схема процесса получает представление о преобразовании процессов в логической последовательности планирования работы и программирования, а также необходимых задач для своих выводов. Дополнительная схема контроля работает с понятиями, которые относятся к контролю процесса.
Общие элементы или слой совместимости
В этом слое находятся категории сущностей, которые представляют собой физические элементы здания.
Он используется для обмена специальностей и приложений обслуживания, и располагает физическими элементами здания. Он имеет определения сущностей, таких как балки, колонны, стены, двери и прочие физически элементы здания, так же как и свойства по управлению потоком, акустические свойства наряду с некоторыми другими.
Слой доменов
Это наивысший слой, который имеет дело с сущностями конкретных дисциплин, таких как Архитектура, Структура, Оборудование наряду с некоторыми другими.
Как определяются сущности IFC?
Для демонстрации этого понятия, приведем пример. Будут использованы две основные сущности «стена» и «пространство», и появится возможность увидеть, как каждая из них представлена по отдельности, и как представлено отношение между ними, как показано на Рисунке 2.
На Рисунке 2 прямоугольники представляют собой определения сущностей, показывающих некоторые из своих атрибутов: небольшие кружки представляют собой примеры сущностей «стены» и «пространства», а также ромбы представляют собой отношения между сущностями.
Рисунок 2: Сущность «стена» и сущность «пространство» в модели IFC и их отношения
Иерархия сущностей определяет сущность «стена» и прочие физические сущности, такие как плиты, балки, колонны.
Практически это означает, что сущность «стена» (ifcWall) задается как подтип сущности «элементы здания» (ifcBuildingElement), который является подтипом сущности «элемент» (ifcElement) и так далее до сущности «корневой каталог» (ifcRoot).
Атрибуты связаны с каждым типом сущности, и сущность «стена» наследует атрибуты всех сущностей выше, или «родительских сущностей», известных как «супертипы».
В этом случае все сущности на превосходящем уровне являются абстрактными; это означает, что это невозможно для создания примера сущности такого типа. Вот почему такие сущности находятся на Основном слое. Однако сущность «стена» не является абстрактной, что означает, что на нее нельзя сослаться для создания объектов «стены», которые существуют в модели здания. По большей части атрибуты стены, такие как ее тип, форма, локализация, количество, соединительные детали, проемы, и т.д. первоначально определяются их «супертипами».
Сущность «пространство» (ifcSpace) определяется как подтип «пространственный конструктивный элемент» ifcSpatialStructureElement), который является подтипом сущности «продукт» (ifcProduct), который также существует в иерархии сущности «стена».
В случае с сущностью «пространство», все сущности ее супертипа являются абстрактными, и сущность «пространство» наследует все свойства супертипов. Однако так же как и сущность «стена», сущность «пространство» не является абстрактной, и на нее можно сослаться для создания различных пространств здания.
Различные типы отношений могут быть связаны с сущностями, используемыми в примере. Отношение «агрегация» применимо для примеров сущности «пространство» для того, чтобы сгруппировать их в панели здания, а отношение «инкапсуляция» применимо для сущности «мебель» для того, чтобы расположить ее в определенном пространстве.
Если сущность «стена» должна быть связана с сущностью «пространство», будет применяться отношение «инкапсуляция» (ifcRelContainedSpatialStructure).
Поскольку формат IFC позволяет создавать все эти типы отношений, ответственность за гарантию того, что такие отношения созданы надлежащим образом, несет автор приложения, которому придется экспортировать модель в формат ifc.
Так как формат IFC весьма гибок и не задает форму ассоциации, стена должна быть связана с пространством, но также может быть связана с панелью.
В то же самое время, приложение, которому необходимо найти стену, связанную с пространством, возможно, не найдет ее, если такая ассоциация не создана явным образом. Таким образом, способ, которым создается файл IFC для экспортирования посредством приложения, является очень важным, и это является решающим фактором успеха интероперабельности среди приложений, использующих IFC.
Сложность языка IFC
Язык IFC весьма обширен и сложен. Текущая версия 2×4 RC4, buildingSMART (2012d) включает в себя:
Сложность языка усугубляется возможностью существующих альтернативных форм моделирования для одного и того же объекта: например, структурный блок может быть смоделирован как с помощью представления, ограниченного четырьмя планами, так и посредством сжатия поверхности и вектора. Каждый из этих объектов имеет различные семантические значения, и, хотя они могут иметь такой же вид в объемном изображении, они будут рассматриваться по-разному в структурном методе анализа.
В тех случаях, в которых ifc не имеет конкретного объекта, язык содержит в себе механизм моделирования, называемый IfcProxy, который работает в качестве механизма для его расширения.
Если не принимать во внимание сложность языка, модели IFC, как правило, имеют большие размеры файлов. Например, здание с 19-ю панелями, полная модель которого составляет около 360 Mб.
Что такое ifc формат
Международный союз International Alliance for Interoperability (IAI) установил международные стандарты для широко распространенных в строительной промышленности архитектурных и строительных объектов. В частности, союз International Alliance for Interoperability разработал модель данных Industry Foundation Classes (IFC) для определения графических данных CAD как реальных объектов 3D. Формат файлов IFC обеспечивает взаимозаменяемость IFC-совместимых программных приложений и снижение объемов информации при передаче файлов.
Сохраненные в AutoCAD MEP чертежи могут экспортироваться в формат IFC, а затем импортироваться в другие IFC-совместимые приложения. При экспорте чертежей в формат IFC размеры и все архитектурные объекты 3D, включая объекты инженерных систем, сохраняются.
Перед экспортом файла чертежа MEP в формат IFC необходимо установить соответствие объектов MEP соответствующей классификации IFC. Этот шаг позволяет разработанным в AutoCAD MEP объектам MEP правильно отображаться в IFC-совместимых приложениях.
Классификация IFC может быть назначена следующим объектам MEP:
Файл чертежа IfcShareBldgElements (MEP) DWG включает классификации IFC для данных объектов MEP. Этот файл находится в папке \ProgramData\Autodesk\MEP 2011\rus\Styles. В AutoCAD MEP поддерживается следующие классы объектов IFC:
Для назначения классификации IFC объектам MEP перед их экспортом в файл IFC необходимо выполнить следующие действия:
Для задания классификации IFC в AutoCAD MEP
Для преобразования объектов MEP в IFC
Выбранное появится рядом с «IFCObjectClassification» на вкладке «Расширенные данные» в палитре свойств. Повторите эти шаги для всех объектов MEP на чертеже.
Экспорт и импорт файлов IFC
После операции экспорта можно открывать новый файл IFC с помощью сторонних средств просмотра файлов IFC. Классификация IFC отображается для каждого ранее определенного объекта.
Файлы IFC импортируются как чертежи, на которые имеется внешняя ссылка. Правильность сохранения объектов MEP может быть проверена.
IFC формат. Импорт/экспорт в Renga, Revit, ARCHICAD
IFC (Industry Foundation Classes) — формат с открытой спецификацией. Его признают стандартом обмена данными между различным ПО для информационного моделирования. Даже в недавно принятых нормативных документах говорится об этом:
6.5.2 В качестве форматов выдачи цифровых моделей объектов строительства следует использовать форматы с открытой спецификацией.
Примечания
1 Для передачи ЦИМ рекомендуется использовать формат с открытой спецификацией IFC версии 2×3 и выше.
Я не считал его работоспособным форматом когда проектировал в Revit. Так продолжалось довольно долго, вплоть до тех пор, пока я не попробовал экспорт\импорт IFC в Renga Architecture. Не скажу, что я был поражен, но удивлен точно был.
Предистория вопроса
А предистория совершенно простая. Как и любой ревитчик, любопытства ради, я экспортировал свою модель из Revit и импортировал ее обратно.
На этом эксперимент закончился. После импорта в Revit’е модель была совершенно не пригодна для дальнейшей работы.
И я подумал, что уж если Revit открывает IFC-модель, как не родное дитя, хотя секунду назад он сам же её и произвёл, то ни о каком кросс-платформенном взаимодействии не может быть и речи.
А как реально обстоят дела
Конечно, я не могу сказать, что на самом деле любое другое ПО открывает IFC-файлы как свои собственные. Но однозначно, любое другое ПО пытается преобразовывать объекты IFC в нативные, для возможности дальнейшего редактирования.
Некоторым это удается вполне сносно! К примеру, ARCHICAD открывает IFC из Revit лучше, чем этот же файл открывает Revit. Вообще, я считаю, что ARCHICAD в этом деле ушел намного дальше остальных, учитывая все возможные настройки экспорта и импорта, которые он дает и количество предустановленных трансляторов. К сожалению, я не знаю его также хорошо, как я заню Revit и Renga. Соответственно не могу утверждать, что у него нет никаких проблем с трансляцией IFC-формата. Да и блог мой посвящен совсем другой программе.
Возможность настройки в Renga и Revit
Прежде чем делать тесты сравним возможность настройки экспорта в Renga и Revit.
В Renga нет никаких настроек, экспорт осуществляется «как есть» по нажатию одной клавиши. Я не сталкивался с необходимостью дополнительной настройки. А учитывая, что пользователи чаще всего не разбираются в структуре этого формата, экспорт одним нажатием — это идеальный вариант. На начало 2019 года Renga поддерживает только версию IFC2x3. Есть вероятность, что в 2019 году разработчики добавят поддержку IFC4. Единственная возможность что-либо настроить есть из окна управления Пользовательскими свойствами. Для них можно указать, будут ли они передаваться в IFC при экспорте или нет.
В Revit есть возможность применить некоторые настройки. В первую очередь это выбор версии транслятора. Он поддерживает несколько вариантов IFC2x3, а также IFC4. В остальном ничего значительного прочие настройки не дают. Но факт остается фактом, у пользователя есть возможность снять и поставить различные галочки.
От теории к практике
Рассмотрим пример простейшего домика. Сценарий такой:
Результат в Revit
Сначала в нем, так как многие судят IFC формат по опыту работы именно в этой программе.
Оригинал в Revit
Экспорт IFC из Revit и импорт обратно
По картинкам в принципе все понятно, но я опишу ситуацию.
Видим, что свой собственный IFC Revit открыл как зря, даже без намека на дальнейшую работу с файлом. Хотя намек все же есть 🙂 Одна стена — та, что без проемов, доступна для редактирования.
Импорт IFC из Renga Architecture в Revit
IFC из Renga он открыл просто плохо. Не смотря на то, что выглядит она более менее нормально, но Revit потерял коробку окон и переместил покрытие. Возможно эти огрехи можно как-то учесть при импорте, но я разбираться дальше не стал.
Импорт IFC из ARCHICAD в Revit
У ARCHICAD’а есть специальная настройка для экспорта в Revit, ею я и воспользовался. Что интересно, его файл Revit открыл почти как свой (также плохо), даже выглядят они похоже. Но разница все же есть, сопряжения стен у архикадовской версии выглядят лучше! Но редактировать все равно ничего толком нельзя.
Отдельно отмечу, что полноценно редактируемых элементов в Revit получить не удалось ни из одного ПО, за исключением вышеупомянутой стены.
Результаты в Renga
Оригинал в Renga Architecture
Импорт IFC из Renga Architecture в Renga Architecture
Видно, что Renga открыла свой собственный файл вполне себе замечательно. Все редактируемо и все параметрическое, за исключением Дверей. На счет Дверей еще расскажу в Итогах.
Импорт IFC из Revit в Renga Architecture
Чудеса мы еще увидим, но не здесь. В принципе, открылась похожим образом, как и в самом Revit. Та же самая стена без проемов у нас редактируемая. Все остальные объекты — нет
Импорт IFC из ARCHICAD в Renga Architecture
На мой взгляд модель открылась отлично, все редактируется кроме дверей. Окна потеряли прозрачность, но они параметрические, поэтому им можно изменить стиль на родной стиль Ренги и работать! Кстати, при экспорте из ARCHICAD использовал транслятор для Tekla Structures.
А вот и пример редактирования импортированной модели созданной в ARCHICAD!
Результаты в ARCHICAD
Тут я прошу прощенья 🙂 Не стал разбираться с импортом в ARCHICAD, но свои догадки приведу. Скорее всего модель из Renga можно успешно импортировать используя транслятор для Tekla Structures, дальше будет пример. А вот IFC из Revit ничего не поможет 🙁
Файлы для скачивания:
Ну и для чистоты эксперемента, прикладываю файлы.
Дальше — больше
Мы рассмотрели пример маленького и не серьезного домика. Конечно никто не станет выстраивать взаимодействие на таком проекте. Так насколько это применимо для более сложных проектов?
Вот пример того, как Renga открывает свой собственный IFC
Основная часть объектов редактируемая. Часть окон параметрические, а значит полностью редактируемые. Часть окон не параметрические, но Ренга создала для них соответствующий стиль. Двери как и раньше открылись как тела.
И как его открывает ARCHICAD
По гифке с архикадом видно, что в модели пропали параметрические окна. Это произошло потому что я использовал транслятор для Tekla Structures и при открытии архикад импортировал только конструктивные элементы здания и проигнорировал окна. Еще раз скажу, я не стал сильно разбираться в том, как настроить транслятор импорта.
Ну и конечно, вот ссылка на скачивание IFC-модели многоэтажки. Не верьте мне, а проверьте все самостоятельно.
Кратко об итогах
В ARCHICAD с импортом и экспортом IFC все супер гуд! Предустановленные трансляторы помогут вам наладить работу с самым популярным ПО. А еще есть возможность все настроить самому как надо. Поэтому принимать архитектуру из ARCHICAD можно, и делать на ее основе конструктив и инженерку в Renga.
В Renga работа с IFC очень хорошая. Большая часть объектов импортируется и экспортируется параметрически — а значит есть возможность редактирования. В текущей версии 3.0 не поддерживаются параметрические двери в IFC. Но у меня есть информация, что импорт и экспорт параметрических дверей будет реализован уже в следующем релизе! Значит взаимодействие станет еще лучше. Как только это будет реализовано я обязательно сделаю обновленный обзор и прикреплю файлы новой версии.
Эхх Revit.. Вы и сами все видели. Мне искренне нравится многие технические моменты, которые в нем реализованы. И, не смотря на многие неудобства и работу с семействами, BIM-технологии я осваивал именно на нем. Но вот из-за подобных подстав я и решил, что нам нужен более современный инструмент.
Tekla Structures. Хоть она не фигурировала в этом обзоре и моих тестах, но я выскажу пару догадок. Судя по тому, что для импорта и экспорта из ARCHICAD в Renga я использовал именно транслятор для Tekla, то возможно они используют схожие алгоритмы построения. А значит взаимодействие между ними можно выстроить без проблем.
P.S. Лень
Я часто сталкивался с такими случаями, когда народ хотел проверить возможности Renga, но им было лень разбираться. Поэтому они просто перегоняли модель из Revit в IFC, открывали ее в Renga, ну и дальше вы понимаете результат. Конечно ничего удовлетворительного из такого способа не могло произойти. Ну и конечно, люди смотрели на изуродованную модель и думали, что Renga ничего не умеет.
Суть последней истории в том, что не нужно лениться. Судить о возможностях продукта можно только если вы сделали в нем проект, пообщались с людьми, которые умеют в продукте работать. Поэтому вперед! Ссылки ниже для вас!