Comments 13
В проектируемых объектах нужны ещё сами элементы, которые будут наполнены информацией, которая будет анализироваться.
Графическая составляющая проектной документации важна как и текстовая.
В геометрию ifc-Модели практически невозможно внести изменения. Только смотреть, анализировать. Хотя уже есть способы добавлять атрибуты к изначальной версии.
Если формат usd даст возможность вносить изменения в геометрию модели - это будет большой шаг вперёд.
DWG, PNG, JPG и прочие примеры - все дают возможность полноценного их редактирования.
Роман спасибо, полностью согласен. Возможность редактирования и внесения информации уже после создания проекта в CAD решениях - будет дополняться такими решениями как Unreal Eginge, Blender, Unity и Omniverse. И во всех этих инструментах уже можно работать с файлами в формате USD, вопрос только в том когда CAD вендоры представят официальные экспорт из своих программ в данный формат. На данный момент выгрузить USD можно через дополнительные плагины.
не очень релевантный пример с JPG и PSD - это вобще не взаимозаменяемые форматы, и если PSD на порядок сложнее потому что позволяет залезть в проект и изменить там чтото по требованиям заказчика без перерисовки всего заново, то строительные форматы на 2 порядка сложнее PSD, даже на 3 - первый это из 2D в 3D, второй это из 3D в 4D (потому что BIM управляет стадиями во времени) и из 4D в 5D это свойства материалов, стандарты, инжениринг - всё то что делает BIM тем что он есть. и вендоры могут сколько угодно скрывать свои форматы потому что они предоставляют возможности по управлению проектами которых нет у разработчиков новых офигенных форматов.
вопрос к новому формату - он сможет делать всё что делал старый? или придётся отказаться от каких-то фишек в пользу простоты? и что тогда будут делать заказчики сложных систем? разрабатывать инструменты для нового формата с нуля которые уже работали в старом?
тут как раз поможет архитектура формата как в слоях - чтобы отделять MESH данные от характеристик объекта для обсчёта, от временнЫх данных для управления стадиями строительства, от данных для пост-строительного обслуживания, понятно что формат должен быть открытый, потому что разработать формат наверное проще чем приложение для работы с ним (хотя в строительстве это очень сложно, очевидно).
вобще идея модульного формата достаточно интересна - может в этом и будет заключаться решение, чтобы можно было загружать не весь файл а его срез, упрощённые подмодели как в SolidWorks, и различные другие данные которые могли бы храниться вобще отдельно, может даже нужен какойто встроенный аналог git который бы следил за версиями с временнЫми ветками.
и строительные компании могли бы поучаствовать финансово в разработке этого формата, потому что они на этом могут очень много заработать... в крупных проетах системы хранения и интеграции данных могут стоить миллионы долларов
32639274 спасибо, по сути всё верно — переход к более плоским и модульным форматам как раз то, что и нужно отрасли. Модульность с разделением геометрии, свойств и временных данных - это просто та форма, которая удобна и для аналитики и для тех кто работает с геометрией, особенно если добавить версионность как в Git. Строители точно могут инвестировать в это, потому что экономия на интеграции будет колоссальной. Но вопрос нужно ли создавать новый формат - когда и для геометрии и для метаинформации уже существует множество открытых и популярных форматов
Фигня. Какая смена парадигмы?! Autodesk как любой монополист пытается прикрыть все возможные варианты которые могут сделать данные максимально открытыми для всех. Вместо сложного, объемного и продуманного формата IFC предложить куцый USD куда просто насыпать цифр, а семантику данных оставит себе в софте и вы по прежнему с этого софта ни шагу в сторону не сделаете. Логично что для Автодеск IFC как кость в горле и он очень даже не против прикрыть его за то что тот сложную семантику описывает.
Такие красивые статьи с картинками Автодеску наверно как бальзам на душу - потому что если невнимательно читать и подмены понятий не замечать, то можно и вправду подумать что USD это что-то лучшее или какая-то замена, а по правде это даже близко к IFC не стояло. Я надеюсь что не все читатели - Буратины и разницу поймут, потому что статья по многим вещам интересная и информативная по отдельным пунктам, но методами воздействия и отсутствием логики доказательства исходного тезиса во многих местах мне очень наши тв каналы напоминает.
Олег спасибо. Полностью согласен - но это не отменяте того факта что Автодеск пытается засунуть USD в IFC и уже инвестировал в поддержку USD много средств. На генеральной ассамблеи buildingSMART в этом году 4 команды презентавали обсуждение USD в IFC5.
В целом пожалуйста напшите - какие приведённые факты вам не нравятся больше всего или где вам не хватает ссылок?
Все полезное нужно впитывать только если у вас его нет или если у конкурента оно лучше. Билдингсмарт должен обсуждать и USD и gltf и это замечательно и правильно, все новое знать нужно и впитывать если там есть что-то лучшее, но ваш тезис в заголовке говорит что этот формат - следующий шаг по пути прогресса после IFC - а по фактам, это наоборот упрощение и сужение. Ссылок более чем достаточно - но нужно же их обдумывать и смотреть кому что выгодно, а не просто искать слова в подтверждение своего тезиса.
Например пункт 8 - описан как будто gltf предложен как стандарт для геометрии в будущем ifc. Где? Посмотрите на оригинал на вашем же скриншоте - там написано что нужно использовать устоявшиеся стандарты при разработке ifc - например gltf для триангулированной геометрии. Маленький кусочек касающийся только триангулированной геометрии в репозитории 4 летней давности после которого в ifc триангулированная геометрия как раз и была хорошо переработана. И это почему-то приводится как аргумент для смены формата в строну USD? В ifc вся геометрия (а не только триангулированная) - это наверно порядка 5% процентов от всего стандарта. Работы, ресурсы, свойства, стоимости, сложная семантика связей. Как можно сравнивать эти форматы?
Например пункт 7 - "CAD вендоры не используют IFC для интероперабельности" - ну таки да - не хотят терять контроль над данными поэтому всеми силами динамят процесс - это реально им дорого стоит, кто тут будет спорить?! Но для нас-то разве это аргумент для того чтобы согласиться на ущербный USD в котором только цифры а семантики нет и при этом еще провозгласить его следующим шагом открытых данных?
Формат USD наверно действительно облегчит жизнь вендорам, но главное чтобы он не создал иллюзию для пользователя что данные открыты и вам доступны - потому что по сути - нет - вам туда положат готовое триангулированное представление (что и в любой другой 3д формат) а не исходные данные из которых его можно сделать. И чтобы что-то сделать по другому вам все равно придется использовать исходный проприетарный формат этого вендора и его софт и сидеть на модных сейчас подписках этого вендора всю оставшуюся жизнь. И где же здесь открытость данных?
Для меня логическая нестыковка в статье в том что приводится стартовый тезис, а потом приводятся 14 аргументов которые многие абсолютно достоверны (те что я знаком), но мне не понятно почему их считают аргументами для исходного тезиса. Типа в билете одна теорема, вам ее формулируют, но доказательство приводят для другой теоремы - я такую находчивость не люблю.
IFC конечно не идеал, но он шел вперед в сторону полноты и открытости данных и совершенно без аргументов называть его "старым" и делать шаг от него к USD - это для меня не прогресс - по моему это те самые два назад, про которые Ильич писал.
Олег спасибо. 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 в этих вопросах.
EntityRelation модель гораздо более информативная и когда она уже есть в виде IFC (за что спасибо мировому сообществу), много лет развивается, объемна и продумана то делать от нее шаги в сторону просто свалки объектов с кучей цифр - это деградация. Попытке свернуть от IFC в сторону точно не стоить радоваться и петь немотивированные диферамбы. Автодеск тут решает свои проблемы, а пользователь окажется в большом проигрыше.
Семантика которую стандарт обязывает соблюдать - она обязательна для всех вендоров и это хорошо! Ее отсутствие приведет к тому что у вас сначала одни и те-же свойства будут у разных вендоров разными, а потом и объекты станут разными. Вроде и файл по "стандарту" и данные в файле есть а пользоваться ими никто кроме вашего вендора не будет пока вы сами снаружи мэпинг не устроите. А по правде эту проблему должен решать как раз вендор - согласую свою внутреннюю модель со стандартом, и максимально возможно следуя общей семантике. То что не согласуется в его модели он и сейчас может положить в IFC например в виде пользовательских свойств которые будут специфичны только для этого вендора, но вся основная стандартизованная и типизированная семантика которую могут понимать все должна лежать общим и понятным для всех способом. И стандарт должен служить тому чтобы такие согласованные и понятные всем данные составляли большую часть.
Нужно чтобы люди понимали что делая шаги от IFC с его продуманной типизацией к куцему USD (или любому XML с не стандартизованной схемой) они уходят от семантически корректного стандарта данных в угоду удобству вендора, в итоге повышая риски потери контроля над своими данными.
Сравнивать IFC и USD все равно что сравнивать иерархию стандартизованных типизированных объектов для нескольких предметных областей сразу с одной стороны и одну огромную двумерную таблицу куда просто высыпали данные (причем даже не все а ~5%) - причем даже для этой маленькой части данных такая таблица будет у каждого вендора своя, строки свои, столбцы свои - такие данные не содержат обязательной семантики, которая остается у вендора или внутри его закрытых проприетарных программ или, в лучшем случае, документации этого вендора.
Очевидно что многим вендорам уход от IFC это хорошо, но не пользователям, которых эта статья как Сусанин утягивает от IFC в болото фальшивыми аргументами.
Олег спасибо, вы предлагаете пользователю доверится вендору, а вендорам слушать организацию, которая управляется Autodesk в своих интересах. Как можно положиться полностью на вендора - если существует доля вероятности, что он сам намеренно или ненамеренно не создаст правильный маппинг. То есть в любом случае вы вынуждены будете проверять данные, как бы вы не доверяли вендорам и в итоге в тех параметрах где будут несовпадения вы будете заниматься маппингом.
"двумерную таблицу куда просто высыпали данные (причем даже не все а ~5%)" - почему 5% - мы как раз выгружаем все 1200 категорий из Revit бесплатно и полностью автономно - datadrivenconstruction.io. Можете проверить с выгрузкой в IFC - больше информации чем получаем мы, кажется будет сложно достичь.
Спасибо за статью, основное что нашёл, это подтверждение выпранного вектора, а именно: "Индустрия готовится к новой эре — эре аналитики данных в строительстве. Ручное перемещение данных между таблицами уходит в прошлое, уступая место автоматизации, анализу потоков данных, аналитике и машинному обучению, которые становятся ключевыми инструментами принятия решений"
Эпоха перемен: IFC уходит в прошлое или почему Autodesk готов отказаться от IFC ради USD в 14 ключевых фактах