EntityRelation модель гораздо более информативная и когда она уже есть в виде IFC (за что спасибо мировому сообществу), много лет развивается, объемна и продумана то делать от нее шаги в сторону просто свалки объектов с кучей цифр - это деградация. Попытке свернуть от IFC в сторону точно не стоить радоваться и петь немотивированные диферамбы. Автодеск тут решает свои проблемы, а пользователь окажется в большом проигрыше.
Семантика которую стандарт обязывает соблюдать - она обязательна для всех вендоров и это хорошо! Ее отсутствие приведет к тому что у вас сначала одни и те-же свойства будут у разных вендоров разными, а потом и объекты станут разными. Вроде и файл по "стандарту" и данные в файле есть а пользоваться ими никто кроме вашего вендора не будет пока вы сами снаружи мэпинг не устроите. А по правде эту проблему должен решать как раз вендор - согласую свою внутреннюю модель со стандартом, и максимально возможно следуя общей семантике. То что не согласуется в его модели он и сейчас может положить в IFC например в виде пользовательских свойств которые будут специфичны только для этого вендора, но вся основная стандартизованная и типизированная семантика которую могут понимать все должна лежать общим и понятным для всех способом. И стандарт должен служить тому чтобы такие согласованные и понятные всем данные составляли большую часть.
Нужно чтобы люди понимали что делая шаги от IFC с его продуманной типизацией к куцему USD (или любому XML с не стандартизованной схемой) они уходят от семантически корректного стандарта данных в угоду удобству вендора, в итоге повышая риски потери контроля над своими данными.
Сравнивать IFC и USD все равно что сравнивать иерархию стандартизованных типизированных объектов для нескольких предметных областей сразу с одной стороны и одну огромную двумерную таблицу куда просто высыпали данные (причем даже не все а ~5%) - причем даже для этой маленькой части данных такая таблица будет у каждого вендора своя, строки свои, столбцы свои - такие данные не содержат обязательной семантики, которая остается у вендора или внутри его закрытых проприетарных программ или, в лучшем случае, документации этого вендора.
Очевидно что многим вендорам уход от IFC это хорошо, но не пользователям, которых эта статья как Сусанин утягивает от IFC в болото фальшивыми аргументами.
Все полезное нужно впитывать только если у вас его нет или если у конкурента оно лучше. Билдингсмарт должен обсуждать и USD и gltf и это замечательно и правильно, все новое знать нужно и впитывать если там есть что-то лучшее, но ваш тезис в заголовке говорит что этот формат - следующий шаг по пути прогресса после IFC - а по фактам, это наоборот упрощение и сужение. Ссылок более чем достаточно - но нужно же их обдумывать и смотреть кому что выгодно, а не просто искать слова в подтверждение своего тезиса.
Например пункт 8 - описан как будто gltf предложен как стандарт для геометрии в будущем ifc. Где? Посмотрите на оригинал на вашем же скриншоте - там написано что нужно использовать устоявшиеся стандарты при разработке ifc - например gltf для триангулированной геометрии. Маленький кусочек касающийся только триангулированной геометрии в репозитории 4 летней давности после которого в ifc триангулированная геометрия как раз и была хорошо переработана. И это почему-то приводится как аргумент для смены формата в строну USD? В ifc вся геометрия (а не только триангулированная) - это наверно порядка 5% процентов от всего стандарта. Работы, ресурсы, свойства, стоимости, сложная семантика связей. Как можно сравнивать эти форматы?
Например пункт 7 - "CAD вендоры не используют IFC для интероперабельности" - ну таки да - не хотят терять контроль над данными поэтому всеми силами динамят процесс - это реально им дорого стоит, кто тут будет спорить?! Но для нас-то разве это аргумент для того чтобы согласиться на ущербный USD в котором только цифры а семантики нет и при этом еще провозгласить его следующим шагом открытых данных?
Формат USD наверно действительно облегчит жизнь вендорам, но главное чтобы он не создал иллюзию для пользователя что данные открыты и вам доступны - потому что по сути - нет - вам туда положат готовое триангулированное представление (что и в любой другой 3д формат) а не исходные данные из которых его можно сделать. И чтобы что-то сделать по другому вам все равно придется использовать исходный проприетарный формат этого вендора и его софт и сидеть на модных сейчас подписках этого вендора всю оставшуюся жизнь. И где же здесь открытость данных?
Для меня логическая нестыковка в статье в том что приводится стартовый тезис, а потом приводятся 14 аргументов которые многие абсолютно достоверны (те что я знаком), но мне не понятно почему их считают аргументами для исходного тезиса. Типа в билете одна теорема, вам ее формулируют, но доказательство приводят для другой теоремы - я такую находчивость не люблю.
IFC конечно не идеал, но он шел вперед в сторону полноты и открытости данных и совершенно без аргументов называть его "старым" и делать шаг от него к USD - это для меня не прогресс - по моему это те самые два назад, про которые Ильич писал.
Фигня. Какая смена парадигмы?! Autodesk как любой монополист пытается прикрыть все возможные варианты которые могут сделать данные максимально открытыми для всех. Вместо сложного, объемного и продуманного формата IFC предложить куцый USD куда просто насыпать цифр, а семантику данных оставит себе в софте и вы по прежнему с этого софта ни шагу в сторону не сделаете. Логично что для Автодеск IFC как кость в горле и он очень даже не против прикрыть его за то что тот сложную семантику описывает.
Такие красивые статьи с картинками Автодеску наверно как бальзам на душу - потому что если невнимательно читать и подмены понятий не замечать, то можно и вправду подумать что USD это что-то лучшее или какая-то замена, а по правде это даже близко к IFC не стояло. Я надеюсь что не все читатели - Буратины и разницу поймут, потому что статья по многим вещам интересная и информативная по отдельным пунктам, но методами воздействия и отсутствием логики доказательства исходного тезиса во многих местах мне очень наши тв каналы напоминает.
EntityRelation модель гораздо более информативная и когда она уже есть в виде IFC (за что спасибо мировому сообществу), много лет развивается, объемна и продумана то делать от нее шаги в сторону просто свалки объектов с кучей цифр - это деградация. Попытке свернуть от IFC в сторону точно не стоить радоваться и петь немотивированные диферамбы. Автодеск тут решает свои проблемы, а пользователь окажется в большом проигрыше.
Семантика которую стандарт обязывает соблюдать - она обязательна для всех вендоров и это хорошо! Ее отсутствие приведет к тому что у вас сначала одни и те-же свойства будут у разных вендоров разными, а потом и объекты станут разными. Вроде и файл по "стандарту" и данные в файле есть а пользоваться ими никто кроме вашего вендора не будет пока вы сами снаружи мэпинг не устроите. А по правде эту проблему должен решать как раз вендор - согласую свою внутреннюю модель со стандартом, и максимально возможно следуя общей семантике. То что не согласуется в его модели он и сейчас может положить в IFC например в виде пользовательских свойств которые будут специфичны только для этого вендора, но вся основная стандартизованная и типизированная семантика которую могут понимать все должна лежать общим и понятным для всех способом. И стандарт должен служить тому чтобы такие согласованные и понятные всем данные составляли большую часть.
Нужно чтобы люди понимали что делая шаги от IFC с его продуманной типизацией к куцему USD (или любому XML с не стандартизованной схемой) они уходят от семантически корректного стандарта данных в угоду удобству вендора, в итоге повышая риски потери контроля над своими данными.
Сравнивать IFC и USD все равно что сравнивать иерархию стандартизованных типизированных объектов для нескольких предметных областей сразу с одной стороны и одну огромную двумерную таблицу куда просто высыпали данные (причем даже не все а ~5%) - причем даже для этой маленькой части данных такая таблица будет у каждого вендора своя, строки свои, столбцы свои - такие данные не содержат обязательной семантики, которая остается у вендора или внутри его закрытых проприетарных программ или, в лучшем случае, документации этого вендора.
Очевидно что многим вендорам уход от IFC это хорошо, но не пользователям, которых эта статья как Сусанин утягивает от IFC в болото фальшивыми аргументами.
Все полезное нужно впитывать только если у вас его нет или если у конкурента оно лучше. Билдингсмарт должен обсуждать и USD и gltf и это замечательно и правильно, все новое знать нужно и впитывать если там есть что-то лучшее, но ваш тезис в заголовке говорит что этот формат - следующий шаг по пути прогресса после IFC - а по фактам, это наоборот упрощение и сужение. Ссылок более чем достаточно - но нужно же их обдумывать и смотреть кому что выгодно, а не просто искать слова в подтверждение своего тезиса.
Например пункт 8 - описан как будто gltf предложен как стандарт для геометрии в будущем ifc. Где? Посмотрите на оригинал на вашем же скриншоте - там написано что нужно использовать устоявшиеся стандарты при разработке ifc - например gltf для триангулированной геометрии. Маленький кусочек касающийся только триангулированной геометрии в репозитории 4 летней давности после которого в ifc триангулированная геометрия как раз и была хорошо переработана. И это почему-то приводится как аргумент для смены формата в строну USD? В ifc вся геометрия (а не только триангулированная) - это наверно порядка 5% процентов от всего стандарта. Работы, ресурсы, свойства, стоимости, сложная семантика связей. Как можно сравнивать эти форматы?
Например пункт 7 - "CAD вендоры не используют IFC для интероперабельности" - ну таки да - не хотят терять контроль над данными поэтому всеми силами динамят процесс - это реально им дорого стоит, кто тут будет спорить?! Но для нас-то разве это аргумент для того чтобы согласиться на ущербный USD в котором только цифры а семантики нет и при этом еще провозгласить его следующим шагом открытых данных?
Формат USD наверно действительно облегчит жизнь вендорам, но главное чтобы он не создал иллюзию для пользователя что данные открыты и вам доступны - потому что по сути - нет - вам туда положат готовое триангулированное представление (что и в любой другой 3д формат) а не исходные данные из которых его можно сделать. И чтобы что-то сделать по другому вам все равно придется использовать исходный проприетарный формат этого вендора и его софт и сидеть на модных сейчас подписках этого вендора всю оставшуюся жизнь. И где же здесь открытость данных?
Для меня логическая нестыковка в статье в том что приводится стартовый тезис, а потом приводятся 14 аргументов которые многие абсолютно достоверны (те что я знаком), но мне не понятно почему их считают аргументами для исходного тезиса. Типа в билете одна теорема, вам ее формулируют, но доказательство приводят для другой теоремы - я такую находчивость не люблю.
IFC конечно не идеал, но он шел вперед в сторону полноты и открытости данных и совершенно без аргументов называть его "старым" и делать шаг от него к USD - это для меня не прогресс - по моему это те самые два назад, про которые Ильич писал.
Фигня. Какая смена парадигмы?! Autodesk как любой монополист пытается прикрыть все возможные варианты которые могут сделать данные максимально открытыми для всех. Вместо сложного, объемного и продуманного формата IFC предложить куцый USD куда просто насыпать цифр, а семантику данных оставит себе в софте и вы по прежнему с этого софта ни шагу в сторону не сделаете. Логично что для Автодеск IFC как кость в горле и он очень даже не против прикрыть его за то что тот сложную семантику описывает.
Такие красивые статьи с картинками Автодеску наверно как бальзам на душу - потому что если невнимательно читать и подмены понятий не замечать, то можно и вправду подумать что USD это что-то лучшее или какая-то замена, а по правде это даже близко к IFC не стояло. Я надеюсь что не все читатели - Буратины и разницу поймут, потому что статья по многим вещам интересная и информативная по отдельным пунктам, но методами воздействия и отсутствием логики доказательства исходного тезиса во многих местах мне очень наши тв каналы напоминает.