Мы уже уяснили по итогу предыдущей статьи из цикла, что геометрическое представление объектов при экспорте в IFC напрямую влияет на возможность дальнейшего определение Renga импортируемого через IFC объекта, как "родного". А также определились, что будем делать нестандартное оборудование через стандартный "Элемент" Renga.
А теперь наступило время разобраться, как будет переопределяться IfcBuildingElementProxy (IFC класс элемента) на нужный нам IFC класс оборудования.
3.1. "Волшебное" свойство IfcEntityType, а также маленькое погружение в API Renga
Вначале вспомним, что нам говорит раздел букваря Renga "Настройки экспорта в международный обменный формат IFC":
"Значение свойства «IfcEntityType» может быть задано только из списка значений спецификации IFC, также как и предопределенный тип (предопределенный тип дополняет основной тип объекта и записывается заглавными буквами через точку после указания основного типа (может отсутствовать; или быть задан в значении USERDEFINED – определенный пользователем или NOTDEFINED, т.е. необозначенный в IFC)".
А теперь попробуем погрузимся в эту тему более глубже.....
3.1.1. Используем уже предопределенные в Renga GUID для требуемых свойств
Пытливые умы, конечно, уже обратили внимание, что при экспорте/импорте IFC Renga сама создает требуемые свойства, присваивает их нужным типам объектов и их соответствующим стилям, а также присваивает свойствам объектов в модели нужные/заданные значения. И GUID у этих свойств всегда один и тот же (предопределен):
IfcEntityType = "437fe378-d12f-4487-afbf-126746eac996"
IfcLayer = "66c137bc-e42b-41c7-b86a-9387251ca95b"
IfcName = "8c877126-3d7f-4482-b51f-4584c8711380"
Также пытливые умы, конечно же, обратили внимание на то, что самостоятельно созданное в проекте пользователем свойство IfcEntityType с ЛЮБЫМ GUID и назначенное определенным типам объектов, при дальнейшей выгрузке/загрузке через IFC в Renga ВСЕГДА будет иметь преопределенным GUID, а не тот GUID, который был присвоен ему при создании пользователем.
Для чего нам эта информация, коллеги?
Не надо "плодить" лишние свойства с иными GUID. Иначе при копировании объектов из различных проектов, созданных различными пользователями, можно получить кучу таких свойств.
Как использовать перечисленные выше свойства с предопределенным GUID?
Ответ многие из вас уже знают! И хоть нас сейчас интересует только свойство IfcEntityType, но для работы с созданием пользовательского оборудования сделаем сразу одно доброе дело:
- Вставляем любой стандартный объект Renga в модель (тип не важен) и выгружаем проект в IFC.
- Далее открываем в Renga созданный файл IFC. Копируем данный объект и вставляем его в свой проект, где будем создавать свое оборудование. Свойства IfcEntityType, IfcLayer и IfcName с необходимыми GUID добавились в проект. Теперь дело за малым - добавить эти свойства нужным типам объектов и можно сохранить проект, как шаблон.
3.1.2. В чем кроется подвох при задании значений свойству IfcEntityType из списка значений спецификации IFC или почему значения свойства IfcEntityType не всегда влияют на корректность определения типа объекта в Renga?
Если мы готовим выгрузку проекта в IFC для использования в стороннем софте, то можно и не озадачиваться разбором классов IFC для свойства IfcEntityType.
Но мы же готовим наше "блюдо" для Renga. Поэтому рекомендую вначале ознакомимся со всеми типами объектов Renga и соответствующими им классами IFC в разделе Букваря Renga "Настройки экспорта в международный обменный формат IFC", включая содержание раздела "Переопределение типов объектов и их параметров".
А теперь немного отойдем от основной темы и попробуем ответить на простой вопрос:
В вышеуказанном разделе Букваря есть пример по выгрузке стандартных объектов Renga в иной класс IFC, неиспользуемый в Renga, на примере создания свайного поля (задание свойству IfcEntityType значения IfcPile).
Какой тип объекта будет у данных элементов при открытии полученного файла в Renga?
Часть из вас уже знает ответ. А вот оставшиеся пусть найдут его в ходе следующего эксперимента. Итак:
Имеем проект, в котором присутствует свойство IfcEntityType, добавленное только для балок и колонн.
Вставляем в модель следующие объекты и задаем некоторым из них значение свойству IfcEntityType (см. описание к рисунку):
Выгружаем проект в IFC (настройки сейчас не принципиальны, кроме отключения экспорта геометрического представления без подрезок).
Открываем полученный файл IFC в Renga. И для простоты анализа включаем плагин ModPlus "Последние". Выбираем по очереди объекты (для удобства: справа - налево, так как в списке объектов окна плагина новое выделение показывается вверху, а предыдущее уходит вниз по списку) и видим:
Итог у нас следующий:
- Колонны и балки со значением свойства IfcEntityType, равным IfcPile, пришли обратно в Renga, как IfcObject (об этом распишу далее), хотя значение свойства IfcEntityType у них все также остается равным IfcPile. Причина - в Renga нет такого объекта, как свая.
- Колонны и балки без переопределения типа (класс IFC) распознались в Renga, как свои "родные" объекты.
- Две балки, соединенные между собой под углом, хоть и не были переопределены на иной класс IFC, но не распознались Renga, как стандартные. Причина тут очевидна - из-за подрезанной геометрии объекты перестали быть "родными" балками для Renga, хотя значение свойства IfcEntityType у них корректное: IfcBeam.
Ответ на поставленный ранее вопрос - тип объекта будет IfcObject.
А теперь уясним две простые вещи:
1). Для нас сейчас важны не все классы IFC из списка значений спецификации IFC, а только те, которые соответствуют стандартным ("родным") типам объектов Renga.
2). Наличие в проекте у импортированного через IFC объекта свойства IfcEntityType со значением класса IFC, относящегося к стандартному типу объекта Renga, не является гарантией того, что этот объект будет загружен в Renga как стандартный тип.
Одним словом, готовьтесь к тому, что тип IfcObject может передать вам "пламенный привет".
3.1.3. Воспоминания о выгрузке геометрии объектов через Tesselation из предыдущей статьи для закрепления текущего материала
Как вы думаете, какой тогда был тип у объектов "ванна чугунная", "теплообменник" и "вентилятор радиальный №5" при загрузке файла IFC, полученного в Эксперименте №1 (выгрузка с включенной тесселяцией)?
Да, да! Именно IfcObject.
3.1.4. "Безликий" IfcObject ..... расскажи мне, кто дал тебе такое имя?
Вообще-то есть такой обобщенный класс (сущность) IfcObject в спецификации IFC.
А теперь немного заглянем в API Renga. Итак.....
Все типы объектов, которыми оперирует Renga в пространстве модели, указаны в классе Renga::ObjectTypes (константы со значениями GUID, имя константы соответствует имени типа объекта; если будем смотреть на данный класс через рефлексию на C#, то это будут свойства класса). Cмотрим:
Renga::ObjectTypes::IfcObject = {F914251D-D5FA-48B2-B93B-074F442CBF3B}
Одним словом, это тип объекта Renga, который инкапсулирует в себе ЛЮБЫЕ объекты (элементы), которые Renga при открытии (импорте) файла IFC не смогла определить как свои стандартные объекты.
Задача всех статей из данного цикла как раз и заключается в том, чтобы созданное нами оборудование (используем Элемент) не стало в Renga типом IfcObject (мы начали с важности геометрического представления в предыдущей статье, а теперь будем разбираться с типами оборудования).
3.2. Что Renga подразумевает под оборудованием и почему не все мечты сбываются
В начале я специально сделаю акцент на то, что в экспериментах с Renga в предыдущей статье (часть 2) мы уже установили возможность определения программой оборудования с портами при импорте его из файла IFC. Здесь важное слово: оборудование!
В Renga инструменты для создания оборудования подразделены на следующие типы:
- санитарно-техническое оборудование;
- оборудование;
- вентиляционное оборудование.
Отметим, что стили оборудования находятся вместе со стилями санитарно-технического оборудования во вкладке "Трубопроводные системы". Стили вентиляционного оборудования - во вкладке "Воздуховодные системы". По своей сути оборудование - это объекты Renga, которые могут вставляться непосредственно в модель, т.е. не привязаны к размещению их на трассах инженерных сетей.
Слышу голоса коллег "А где же электрические системы? Почему Вы о них не упоминаете?". Там ведь тоже есть объекты, которые непосредственно вставляются в модель, без привязки к трассам. Это щиты, электроустановочные изделия и осветительные приборы.
Правда, они все устанавливаются в родительские объекты (на стены, перекрытия, балки, колонны и т.д.). Но все же.... где о них упоминание?
Ответ: Renga данные объекты при их обратном импорте через IFC не распознает как соответствующие им стандартные объекты. При этом в самих файлах информация о портах есть. Именно из-за этого мы не будем рассматривать далее электрические системы! Знаю, что жалко.... но пока радуемся возможности поработать с другим оборудованием.
Ну остальное и так понятно: любые трубопроводы и воздухопроводы, а также их детали и аксессуары не относятся к оборудованию.
3.3. Выбор нужных классов IFC оборудования для свойства IfcEntityType
Что значит нужных? Это выбор классов IFC оборудования, с которыми РАБОТАЕТ Renga.
Перечислю их из раздела Букваря Renga "Настройки экспорта в международный обменный формат IFC":
- Санитарно-техническое оборудование:
IfcSanitaryTerminal - биде, ванна, душевой поддон, мойка, умывальник, унитаз, писсуар;
IfcWasteTerminal - воронка, трап. - Оборудование:
IfcTank - бак;
IfcBoiler - водонагреватель, пластинчатый теплообменник;
IfcPipeFitting - коллектор;
IfcPump - насос;
IfcSpaceHeater - отопительный прибор, полотенцесушитель. - Вентиляция:
IfcFan - вентилятор;
IfcUnitaryEquipment - вентиляционная установка;
IfcAirTerminal - воздухораспределитель, дефлектор, зонт.
Хотите поэкспериментировать и использовать другие классы IFC для оборудования?
Тогда при импорте (открытии) IFC файла в Renga получите обычный IfcObject. И ваш эксперимент, не дойдя до логичного завершения, сразу на этом и закончится!
3.3.1. Отсутствие необходимости в указании подтипа оборудования
Все же помнят из букваря Renga, что при переопределении типа, мы также указываем подтип в свойстве IfcEntityType, которое добавлено непосредственно к стилю соответствующего объекта (в контексте данной статьи, к стилю Элемента)? Вспомнили?
Так вот. На текущем этапе нам это не понадобится! Почему?
Потому что НЕ ПРИНЦИПИАЛЬНО! Так как на результат экспорта/импорта оборудования через IFC в Renga подтип никак не влияет.
Вы можете, при желании, потом указать в итоговой библиотеке своего оборудования нужный вам подтип.
3.3.2. Отсутствие необходимости в применении свойства IfcName, а также любых пользовательских свойств
При корректном определении в Renga созданного нами оборудования, мы будет задавать его название непосредственно именем стиля оборудования (как это обычно и работает). И только на итоговом этапе можно будет добавлять нужные пользовательские свойства созданному оборудованию.
Именно поэтому использование свойства IfcName и любых дополнительных пользовательских свойств на текущем этапе НЕ НУЖНО!
3.4. Влияние наличия/отсутствия портов у объекта при импорте его из IFC
На данном этапе наше "блюдо" с оборудованием для Renga пока еще не готово. Т.е. даже если вы правильно задали нужный тип для Renga в свойстве IfcEntityType у "Элемента", то при выгрузке/загрузке через IFC Renga не распознает объект, как оборудование. Почему?
У оборудования обязательно должны быть порты! Иначе Renga не распознает его.
Добавлением портов мы займемся в следующей статье. А пока подведем итог.
ОБЩИЙ ИТОГ части № 3 (принципы задания нужного класса IFC у оборудования)
- При задании свойства IfcEntityType у Элемента используем только классы IFC для оборудования, которыми оперирует Renga (указаны выше). Подтипы оборудования, которые мы можем задать в стиле Элемента, не принципиальны (добавлять свойство IfcEntityType в стиль Элемента не надо).
- Свойство IfcName использовать нам не нужно, так как требуемое название будет далее определено именем стиля полученного оборудования.
- Нужные нам пользовательские свойства на текущем этапе также не нужно добавлять. Сделаете это потом, когда ваше оборудование начнет корректно определяться самой Renga.
Переходим к следующей части......
