В случае MESH форматов, таких как CPIXML, геометрическая семантика выносится отдельно, а консистентность поддерживается через валидацию данных и пересчёт параметров на этапе обработки, что позволяет использовать упрощённые форматы для расчётов, не полагаясь на сложное геометрическое ядро
@qandakспасибо. У элементов проекта геометрию можно описать через параметры или через полигоны. Если геометрия описана параметрически, то мы получаем сущность со словарём ключ-значения, в котором определённый процент параметров, описывает геометрию сущности-элемента. Но чтобы посчитать или визуализировать такую геометрию - нам необходимо геометрическое ядро, которое для расчётов в большинстве случаев не будет считаться через формулы, радиусы, углы - а с большей вероятностью геометрии будут тесселироваться, чтобы по полигонам посчитать объёмные характеристики.
Второй вариант иметь вместо параметров геометрии и словаря ключ-значения для геометрического ядра - тесселированнаю геометрию в MESH формате. И вместо десятка параметров геометрии, у нас будут наборы полигонов или одно значение геометрии в XML формате. MESH формат нарушает принцип SSoT, так как геометрия и метаданные существуют отдельно. Параметры, такие как площадь или объём, пересчитываются из геометрии и сравниваются с метаданными. Например, в проектах Strabag и Züblin - используется тесселированная геометрия после экспорта из CAD, позволяя вычислять около 150и различных характеристик геометрии, фактически перенеся CAD возможности по подсчёту объёмных параметров в формат OBJ - CPIXML.
Олег спасибо, вы предлагаете пользователю доверится вендору, а вендорам слушать организацию, которая управляется Autodesk в своих интересах. Как можно положиться полностью на вендора - если существует доля вероятности, что он сам намеренно или ненамеренно не создаст правильный маппинг. То есть в любом случае вы вынуждены будете проверять данные, как бы вы не доверяли вендорам и в итоге в тех параметрах где будут несовпадения вы будете заниматься маппингом.
"двумерную таблицу куда просто высыпали данные (причем даже не все а ~5%)" - почему 5% - мы как раз выгружаем все 1200 категорий из Revit бесплатно и полностью автономно - datadrivenconstruction.io. Можете проверить с выгрузкой в IFC - больше информации чем получаем мы, кажется будет сложно достичь.
Олег спасибо. BuildingSMART управляется Autodesk c 1994 года. Проблема Autodesk в том, что они не могут сами экспортировать формат IFC, а SVF2 - это формат, близкий к USD, которым удобно заменить IFC, отказавшись от услуг ODA. Это два формата - IFC с BREP и USD с «мертвой геометрией» MESH. Вопрос о том, какой формат будет удобен для работы вне САПР, вероятно, будут решать сами пользователи.
Возможно, в работе с данными не будет классической иерархии классов, будет лишь набор элементов со свойствами - в этом и заключается суть гранулярного перехода, о котором Autodesk говорит с прошлого года. В этом же смысл системы Entity-component-system, которая вшита в USD. Мы можем прикреплять к элементам USD любые параметры. Есть элемент, и у него есть атрибуты, которые могут включать классические атрибуты класса и группы. Тип и другие категориальные атрибуты могут быть записаны через любой параметр или набор параметров, не обязательно тех, что по умолчанию в Revit. Если мы ждём элемент во внешнюю систему, то сначала мы определяем параметры, которые должны быть у элементов через требования. Если этих параметров нет в данных полученных из модели, то элемент не возможно использовать.
Если Autodesk заявляет о реализации работы с USD, зачем пользователю понадобится IFC, выгруженный через ODA IFC SDK, если можно будет выгрузить те же данные - геометрию и свойства атрибутов через USD.
Аналогичный идентичный USD формат CPIXML используется на всех этапах 4D-7D строительства в центральной Европе и уже успешно заменил IFC в этих вопросах.
Олег спасибо. Полностью согласен - но это не отменяте того факта что Автодеск пытается засунуть USD в IFC и уже инвестировал в поддержку USD много средств. На генеральной ассамблеи buildingSMART в этом году 4 команды презентавали обсуждение USD в IFC5.
В целом пожалуйста напшите - какие приведённые факты вам не нравятся больше всего или где вам не хватает ссылок?
Спасибо, субъективно - для геометрии достаточно MESH формата - GLTF, DAE, OBJ, а для метаинформации SQLite, CSV, XLSX, PARQUET. Автодеск хочет продать очередную мешанину, но если компании смогут сами добывать нужные им форматы - то необходимости в USD и IFC в принципе быть не должною
32639274 спасибо, по сути всё верно — переход к более плоским и модульным форматам как раз то, что и нужно отрасли. Модульность с разделением геометрии, свойств и временных данных - это просто та форма, которая удобна и для аналитики и для тех кто работает с геометрией, особенно если добавить версионность как в Git. Строители точно могут инвестировать в это, потому что экономия на интеграции будет колоссальной. Но вопрос нужно ли создавать новый формат - когда и для геометрии и для метаинформации уже существует множество открытых и популярных форматов
Роман спасибо, полностью согласен. Возможность редактирования и внесения информации уже после создания проекта в CAD решениях - будет дополняться такими решениями как Unreal Eginge, Blender, Unity и Omniverse. И во всех этих инструментах уже можно работать с файлами в формате USD, вопрос только в том когда CAD вендоры представят официальные экспорт из своих программ в данный формат. На данный момент выгрузить USD можно через дополнительные плагины.
Спасибо. Да, всё правильно - но например нужна модель для тысячи различный бизнес кейсов, которые необходимо заполнять также геометрическими данными. В традиционном примере - мне нужно каждый раз открывать модель, и группировать элементы - чтобы получить нужную геометрию и потом её экспортировать.
В случае же если мы сразу выгружаем геометрию, мы можем легко и быстро группировать элементы уже вне CAD (BIM) продукта. Например в Excel (в этом примере заметна разница в группировке и получении геометрии для отдельных групп): https://www.youtube.com/watch?v=kD5Dzek2750
Основное преимущество в этом примере - что не нужно открывать Revit и использовать плагины. В примере используется standalone конвертор, который без использования интернета или необходимости запуска CAD (BIM) программ конвертирует данные в открытые форматы геометрии DAE, GLTF, OBJ
Из CAD (BIM) формато Revit и IFC при помощи конверторов получаются открытые файлы - DAE (Collada) и XLSX (Excel). И уже эти данные используются в UE и Unity
Arrrriva спасибо. Если база данных в CAD (BIM) программе не отличается от базы данных других систем, других специалистов - почему в других отраслях экономики, которые в автоматизации уже ушли далеко вперёд, не существует концепта БИМ. По ссылкам выше, которые я указал в комментарии вы можете проследить логику возникновения BIM, который официально началась с Whitepapre Autodesk в 2003 году после продукта Ревит.
Как конкртено автоматизировать описано подробно в книге "DataDrivenConstruction". В будущем она будет доступна бесплатно в PDF вариант. Буду рад вашему мнению по поводу содержания книги: https://habr.com/ru/articles/801065/
"По-моему личному мнению чем меньше терминологии и больше простоты тем лучше пойдёт процесс цифровизации" - всё правильно поэтому первый шаг в упрощении автоматизации это избавление от аббревиатуры БИМ
Дмитрий спасибо. ChatGPT не про черчение и геомтерию. ChatGPT помогает автоматизировать ETL процессы, т.е. получение документации: таблиц, докумнтов, графиков, витрин и дэшбордов из модели CAD (BIM). ChatGPT и подобные инструменты позволяют не быстрее проектировать, что значит наполнять модель проекта сущностями, атрибутами и их значениями, а они позволяют быстрее проверять аттрибуты сущностей, значений и выгружать в нужные пользователю или менеджеру системы или переводить их в необходимые документы.
@Arrrriva спасибо за комментарий. Здание - это данные и процессы (бизне процессы) и конечно ИИ не сможет полностью заменить человек. ИИ создан для того чтобы быстро создавать черновики решений по автоматизации - на что раньше уходила львинаая доля время.
И конечно "нельзя говорить, что что-то заменит BIM, потому что BIM" потому что БИМа не существует. BIM всего лишь маркетинговая идея поставщиков САПР. Метод BIM существует только там, где есть закрытые данные из баз данных CAD-программ.
Если мы получаем открытые данные из баз CAD-программ, мы сможем использовать все те же инструменты, с которыми работают специалисты в других отраслях, и нам не понадобятся маркетинговые ярлыки, связанные с BIM. Открытые данные и методы ETL полностью заменяют маркетинговые BIM-технологии, которые были придуманы поставщиками САПР за последние 20 лет.
В традиционной инженирии пока нет доступа к данным из баз данных CAD программ, чтобы начать идти по "граблям инженерии программной". Сегодня инженерам в строиельной отрасли приходится оперировать только теми данными, которые предоставляют CAD вендоры - это форматы, в которых аттрибутивная и геометрическая информация сущностей собраны в одном формате. Сложно начать переходить в model driven architecture - если данные находятся в проприентарных закрытых форматах.
Денис, спасибо большое. САПР это база данных в которой мы оперируем сущностями с аттрибутивными свойствами, где в САПР помимо привычных атрибутов добавляются также геометрические аттрибуты.
На уровне ETL-процедур: чем база данных САПР программы (инженерной модели), отличается от баз данных используемых в операционном учёте бизнеса? Или какие ERP системы вы имеете ввиду?
В случае MESH форматов, таких как CPIXML, геометрическая семантика выносится отдельно, а консистентность поддерживается через валидацию данных и пересчёт параметров на этапе обработки, что позволяет использовать упрощённые форматы для расчётов, не полагаясь на сложное геометрическое ядро
@qandakспасибо. У элементов проекта геометрию можно описать через параметры или через полигоны. Если геометрия описана параметрически, то мы получаем сущность со словарём ключ-значения, в котором определённый процент параметров, описывает геометрию сущности-элемента. Но чтобы посчитать или визуализировать такую геометрию - нам необходимо геометрическое ядро, которое для расчётов в большинстве случаев не будет считаться через формулы, радиусы, углы - а с большей вероятностью геометрии будут тесселироваться, чтобы по полигонам посчитать объёмные характеристики.
Второй вариант иметь вместо параметров геометрии и словаря ключ-значения для геометрического ядра - тесселированнаю геометрию в MESH формате. И вместо десятка параметров геометрии, у нас будут наборы полигонов или одно значение геометрии в XML формате. MESH формат нарушает принцип SSoT, так как геометрия и метаданные существуют отдельно. Параметры, такие как площадь или объём, пересчитываются из геометрии и сравниваются с метаданными. Например, в проектах Strabag и Züblin - используется тесселированная геометрия после экспорта из CAD, позволяя вычислять около 150и различных характеристик геометрии, фактически перенеся CAD возможности по подсчёту объёмных параметров в формат OBJ - CPIXML.
Наверно один из самых популярных - ifcOWL. Им занимается buildingSMART, который занимается стандартизацией формата IFC - https://github.com/buildingsmart-community/ifcOWL
Олег спасибо, вы предлагаете пользователю доверится вендору, а вендорам слушать организацию, которая управляется Autodesk в своих интересах. Как можно положиться полностью на вендора - если существует доля вероятности, что он сам намеренно или ненамеренно не создаст правильный маппинг. То есть в любом случае вы вынуждены будете проверять данные, как бы вы не доверяли вендорам и в итоге в тех параметрах где будут несовпадения вы будете заниматься маппингом.
"двумерную таблицу куда просто высыпали данные (причем даже не все а ~5%)" - почему 5% - мы как раз выгружаем все 1200 категорий из Revit бесплатно и полностью автономно - datadrivenconstruction.io. Можете проверить с выгрузкой в IFC - больше информации чем получаем мы, кажется будет сложно достичь.
Олег спасибо. BuildingSMART управляется Autodesk c 1994 года. Проблема Autodesk в том, что они не могут сами экспортировать формат IFC, а SVF2 - это формат, близкий к USD, которым удобно заменить IFC, отказавшись от услуг ODA. Это два формата - IFC с BREP и USD с «мертвой геометрией» MESH. Вопрос о том, какой формат будет удобен для работы вне САПР, вероятно, будут решать сами пользователи.
Возможно, в работе с данными не будет классической иерархии классов, будет лишь набор элементов со свойствами - в этом и заключается суть гранулярного перехода, о котором Autodesk говорит с прошлого года. В этом же смысл системы Entity-component-system, которая вшита в USD. Мы можем прикреплять к элементам USD любые параметры. Есть элемент, и у него есть атрибуты, которые могут включать классические атрибуты класса и группы. Тип и другие категориальные атрибуты могут быть записаны через любой параметр или набор параметров, не обязательно тех, что по умолчанию в Revit. Если мы ждём элемент во внешнюю систему, то сначала мы определяем параметры, которые должны быть у элементов через требования. Если этих параметров нет в данных полученных из модели, то элемент не возможно использовать.
Если Autodesk заявляет о реализации работы с USD, зачем пользователю понадобится IFC, выгруженный через ODA IFC SDK, если можно будет выгрузить те же данные - геометрию и свойства атрибутов через USD.
Аналогичный идентичный USD формат CPIXML используется на всех этапах 4D-7D строительства в центральной Европе и уже успешно заменил IFC в этих вопросах.
Олег спасибо. Полностью согласен - но это не отменяте того факта что Автодеск пытается засунуть USD в IFC и уже инвестировал в поддержку USD много средств. На генеральной ассамблеи buildingSMART в этом году 4 команды презентавали обсуждение USD в IFC5.
В целом пожалуйста напшите - какие приведённые факты вам не нравятся больше всего или где вам не хватает ссылок?
Спасибо, субъективно - для геометрии достаточно MESH формата - GLTF, DAE, OBJ, а для метаинформации SQLite, CSV, XLSX, PARQUET. Автодеск хочет продать очередную мешанину, но если компании смогут сами добывать нужные им форматы - то необходимости в USD и IFC в принципе быть не должною
32639274 спасибо, по сути всё верно — переход к более плоским и модульным форматам как раз то, что и нужно отрасли. Модульность с разделением геометрии, свойств и временных данных - это просто та форма, которая удобна и для аналитики и для тех кто работает с геометрией, особенно если добавить версионность как в Git. Строители точно могут инвестировать в это, потому что экономия на интеграции будет колоссальной. Но вопрос нужно ли создавать новый формат - когда и для геометрии и для метаинформации уже существует множество открытых и популярных форматов
Роман спасибо, полностью согласен. Возможность редактирования и внесения информации уже после создания проекта в CAD решениях - будет дополняться такими решениями как Unreal Eginge, Blender, Unity и Omniverse. И во всех этих инструментах уже можно работать с файлами в формате USD, вопрос только в том когда CAD вендоры представят официальные экспорт из своих программ в данный формат. На данный момент выгрузить USD можно через дополнительные плагины.
Спасибо, нет, Autodesk купила AutoCAD (InterCAD) у Mike Riddle. В этой статье об этом подробнее https://habr.com/ru/articles/814449/
Gurlick спасибо! Полностью согласен, но CAD вендоры не заинтересованы в полной интероперабельности
Вы имеете ввиду видео про историю возникновения BIM, IFC, openBIM и Autodesk:
https://youtu.be/S-TNdUgfHxk?si=f9z48lCQnKqIidIb
Спасибо. Да, всё правильно - но например нужна модель для тысячи различный бизнес кейсов, которые необходимо заполнять также геометрическими данными. В традиционном примере - мне нужно каждый раз открывать модель, и группировать элементы - чтобы получить нужную геометрию и потом её экспортировать.
В случае же если мы сразу выгружаем геометрию, мы можем легко и быстро группировать элементы уже вне CAD (BIM) продукта. Например в Excel (в этом примере заметна разница в группировке и получении геометрии для отдельных групп):
https://www.youtube.com/watch?v=kD5Dzek2750
Основное преимущество в этом примере - что не нужно открывать Revit и использовать плагины. В примере используется standalone конвертор, который без использования интернета или необходимости запуска CAD (BIM) программ конвертирует данные в открытые форматы геометрии DAE, GLTF, OBJ
Из CAD (BIM) формато Revit и IFC при помощи конверторов получаются открытые файлы - DAE (Collada) и XLSX (Excel). И уже эти данные используются в UE и Unity
Arrrriva спасибо. Если база данных в CAD (BIM) программе не отличается от базы данных других систем, других специалистов - почему в других отраслях экономики, которые в автоматизации уже ушли далеко вперёд, не существует концепта БИМ. По ссылкам выше, которые я указал в комментарии вы можете проследить логику возникновения BIM, который официально началась с Whitepapre Autodesk в 2003 году после продукта Ревит.
Как конкртено автоматизировать описано подробно в книге "DataDrivenConstruction". В будущем она будет доступна бесплатно в PDF вариант. Буду рад вашему мнению по поводу содержания книги:
https://habr.com/ru/articles/801065/
"По-моему личному мнению чем меньше терминологии и больше простоты тем лучше пойдёт процесс цифровизации" - всё правильно поэтому первый шаг в упрощении автоматизации это избавление от аббревиатуры БИМ
Дмитрий спасибо. ChatGPT не про черчение и геомтерию. ChatGPT помогает автоматизировать ETL процессы, т.е. получение документации: таблиц, докумнтов, графиков, витрин и дэшбордов из модели CAD (BIM). ChatGPT и подобные инструменты позволяют не быстрее проектировать, что значит наполнять модель проекта сущностями, атрибутами и их значениями, а они позволяют быстрее проверять аттрибуты сущностей, значений и выгружать в нужные пользователю или менеджеру системы или переводить их в необходимые документы.
@Arrrriva спасибо за комментарий. Здание - это данные и процессы (бизне процессы) и конечно ИИ не сможет полностью заменить человек. ИИ создан для того чтобы быстро создавать черновики решений по автоматизации - на что раньше уходила львинаая доля время.
И конечно "нельзя говорить, что что-то заменит BIM, потому что BIM" потому что БИМа не существует. BIM всего лишь маркетинговая идея поставщиков САПР. Метод BIM существует только там, где есть закрытые данные из баз данных CAD-программ.
Если мы получаем открытые данные из баз CAD-программ, мы сможем использовать все те же инструменты, с которыми работают специалисты в других отраслях, и нам не понадобятся маркетинговые ярлыки, связанные с BIM. Открытые данные и методы ETL полностью заменяют маркетинговые BIM-технологии, которые были придуманы поставщиками САПР за последние 20 лет.
Подробная карта истории возникновения БИМ:
https://miro.com/app/board/o9J_laML2cs=/
Видео по истории БИМ, возникновению IFC, openBIM, builgingSMART - и популярных CAD продуктов:
https://youtu.be/S-TNdUgfHxk?si=lj38wOpoqA-v2fcW
В традиционной инженирии пока нет доступа к данным из баз данных CAD программ, чтобы начать идти по "граблям инженерии программной". Сегодня инженерам в строиельной отрасли приходится оперировать только теми данными, которые предоставляют CAD вендоры - это форматы, в которых аттрибутивная и геометрическая информация сущностей собраны в одном формате. Сложно начать переходить в model driven architecture - если данные находятся в проприентарных закрытых форматах.
Денис, спасибо большое. САПР это база данных в которой мы оперируем сущностями с аттрибутивными свойствами, где в САПР помимо привычных атрибутов добавляются также геометрические аттрибуты.
На уровне ETL-процедур: чем база данных САПР программы (инженерной модели), отличается от баз данных используемых в операционном учёте бизнеса? Или какие ERP системы вы имеете ввиду?