Здравствуйте, vdimas, Вы писали:
_>>Ну кроме удобной работы (причём включая весь цикл производства) со специфическими тонкостенными инструментами (не знаю есть ли такой плагин для Inventor — по идее может быть), там собственно наглядно видна 3D параметризация — автор меняет некие параметры примитивов, заложенных в самом начале и корректно перерисовывается весь чертёж. V>Я рядом давал аналогичный ролик по Инвентору. V>Собсно, я себе другого сценария работы и не представляю, иначе — нафига "оно" вообще надо?
Так к Inventor никаких вопросов и не было — я в самом первом сообщение писал, что он относится к САПР среднего уровня.
V>И мне странно уже 10-й раз читать, что Автодеск так не умеет.
Autodesk умеет. AutoCAD не умеет.
V>На пальцах: вот ты разрабатываешь плагин для проектирования цисцерн для жидкостей (рядом ролик как раз про цисцерну). V>В каком-нить низкоуровневом редакторе, навроде Инвентора, ты разработаешь целую сетку параметрических моделей. V>Затем твой плагин предоставит на выбор разные модели цисцерн: стоячие, лежачие, цилиндрические, прямоугольные, торообразные, "квадратные торы" (популярно для пластиковых цисцерн) и т.д. и т.п. V>Т.е. ты можешь задать габаритты этой цисцерны, поместить её в строительный проект в некое помещение (это будет просто объект дизайна), задать высоту подвода "сосков", потом играть параметрами — переключать с цилиндрической на прямоугольную, например. И твои прикладные параметры каждый раз будут связываться через какие-нить формулы уже с параметрами соответствующей выбранной низкоуровневой модели цисцерны. V>Вот какой уровень считается "современным", т.е. куда идёт развитие в современных САПР.
Развитие современных САПР идёт в направление создания законченной и готовой к производству модели автомобиля, самолёта и т.п., а не в размещение цистерны в сарае. )))
V>Скажу так, каждый твой последующий аргумент всё слабее и всё более оно выглядит как будто ты топишь против конкретно Автодеска.
Не, компания Autodesk мне вполне нравится. Мне не нравится неверное позиционирование AutoCAD в иерархии САПР.
Здравствуйте, alex_public, Вы писали:
V>>Это, собсно, азы твердотельного моделирования. V>>Например: _>Ой, а почему же на ролике снова Inventor, а не AutoCAD?
Здравствуйте, alex_public, Вы писали:
V>>Дык, для этого COM АПИ и реализуется. V>>Т.е. именно для VB и C#. _>А почему не для 1C и Perl? У них тоже нет никаких проблем с вызовами COM API.
Это тоже примеры не нейтива, т.е. это мой аргумент, не твой.
А твой аргумент должен был быть в ответ на это:
Под чиста С++ был бы совсем другой АПИ.
_>>>Вообще то matlab — это уж точно не CAD. V>>Это один из самых крутых САПР на сегодня. )) V>>Просто ты его не счупал. _>1. С matlab'ом игрался наверное каждый студент негуманитарной направленности. )))
20 лет назад?
Когда это была просто консольная прога с единственной "графикой", вызываемой для ф-ий plot или более высокоуровневых на её основе? ))
Уже в 96-м году Матлаб стал совсем другим, когда стало возможным строить на ём полноценное GUI.
_>2. В последнее время его активно вытесняет гораздо более мощное и удобное сочетание python+numpy+scipy
Это и есть аналог матлаба 20-тилетней давности.
Т.е. сугубо REPL-среда для экспериментов, но не САПР для инженеров.
Если же ты инженер и тебе надо найти, изучить и понять, а потом рассчитать параметры алгоритмов в областях обработки аудио (аналогового или цифрового), видео, ИИ, обработки финансов и т.д. и т.п., то ты просто берешь Матлаб, запускаешь нужный тулбокс, щелкаешь мышкой, играешь параметрами и на выходе получаешь исходник на сях нужных алгоритмов с нужными параметрами. Или даже напрямую DLL, дотнетную сборку или JAR, которые можно включать в свои проекты.
Это сугубо инженерный подход, а не научный.
Учёный работает с тем, чего еще нет.
Инженер с тем, что уже есть.
В этом принципиальная разница Матлаба по состоянию на 20 лет назад и сейчас — он развивался как помощник инженеру.
Как навигатор по предметным областям, как справочный девайс-агрегат по научным достижениям в уже покрытых им областях, и как удобный конструктор для покрытия еще не покрытых областей, что позволяет развивать этот продукт теоретически бесконечно силами всего сообщества.
Да, Матлаб всё еще остаётся удобной средой и для научных изысканий, бо накопленная база математики никуда не делась.
Но больше уже позиционируется как инженерный САПР, конечно.
_>хотя matlab конечно же будет ещё очень долго жить за счёт накопленного готового кода.
Этот код не просто "накоплен", а быстро продолжает копиться.
К тому же снабжен ср-вами навигации, объяснением, удобным GUI-доступом с автоматизацией всего и вся, т.е. вообще всем тем, что делает САПР САПРом. Сравнивать с ним Питон да хоть с какими угодно библиотеками — это как вещать с обратной стороны Луны.
_>3. И это просто обычный пакет численной математики (что для меня всегда было убого, после знакомства с Maple и Mathematica), а не CAD.
Ты имел ввиду Вольфрам-Математику?
Она рядом с Матлабом и не валялась никогда.
Единственная в ней прикольная функциональность — это ОТДЕЛЬНЫЙ модуль Альфа (сейчас я начну тебя бесконечно гнобить как ты своими отличиями Ревита от Автокада). Модуль Альфа предназначен для школьников-студентов, это модуль символьных вычислений над формулами, его задача — показывать ход решения относительно несложных типовых задач. Чуть что шаг вправо-влево (что в него не вложили) и он уже не может аж ни хре на. ))
Кароч, инженеру это всё как собачке стоп-сигнал.
Ну разве что тихонько восполнить свой склероз со времён школы и объяснить своим детям предмет, типа, не хуже учителя, потешив своё ЧСВ.
В общем, если требуется что-то нетривиальное, то общаешься ты Математикой только через REPL, примерно как с Матлабом более 20-ти лет назад.
Навигации нет, тулбоксов нет, подсчитать банальный фильтр — это надо горы документации перелопатить: http://reference.wolfram.com/language/guide/SignalProcessing.html
и убить кучу часов времени на тонкости АПИ его встроенных ф-ий.
А самое главное — не происходит развития Математики силами сообщества.
Т.е. вот в Матлабе есть "стандартный" социальный алгоритм — постепенно отлаживаются какие-нить инженерные рассчёты сообществом, а затем сверху этого появляется вменяемый GUI + справка по предметной области + позиционирование в навигаторе по предметным областям.
Ничего этого в Математике нет и близко.
Хотя в этом и заключаются отличия систем автоматического проектирования от нихрена не автоматического. ))
_>>>Но даже если бы им и был, то всё равно, как видно в переводе с твоего языка — он нативный. V>>Нативная там только математика. V>>А весь именно САПР (те самые тулбоксы) — это джава и только джава. _>Сказать "Нативная там только математика" про пакет численной математики — это просто шедевр дискуссии, даже для КСВ.
ОМГ
Разумеется, под любым современным САПРом лежат горы матан-а.
Задача САПР в том и состоит, чтобы дать удобные ср-ва крутить-вертеть этим матаном.
"Шедевром дисскуссии" тут может быть, разве что, непонимание, что вообще есть САПР.
_>Ты вот это реально сравниваешь сложность написания целой CAD и мелкого скриптика из десятка строчек, формирующего BOM (csv файл) по готовой модели?
Простейшая одна форма плагина (отображение редакторов св-на GUI окошках в видео) может занять десяток тысяч строчек текста.
А форм десятки в каждом плагине, иногда больше сотни.
Под КАЖДЫЙ уникальный BIM-компонент обычно идёт минимум десяток форм (вкладок св-в).
Вот эти GUI-формы в видео для редактирования сущностей — это всё скриптовое, как и всё, что происходит при изменении вводимых в GUI параметров.
Собсно, 90% полезного кода современных строительных САПР — именно такие.
Иначе сама идеология BIM была бы не реализуема. Задолбаешься ты всё это на плюсах пилить.
Вернее не ты, а нанятые разработчики, потому что грамотных разработчиков С++ и так не хватает, дай бог набрать их для реализации той самой "платформы". А скрипты и управляемый код пусть пишут разработчики с тем самым "низким порогом входа". Иначе, повторюсь, идеи BIM будут банально нереализованы из-за экономической неэффективности. ПО — это ведь не самоцель, а лишь инструмент. ))
Здравствуйте, alex_public, Вы писали:
_>Развитие современных САПР идёт в направление создания законченной и готовой к производству модели автомобиля, самолёта и т.п., а не в размещение цистерны в сарае. )))
99.99% пользователей "современных СПАР" — строительные конторы.
Автомобилестроителей по пальцам рук и ног пересчитать можно.
Самолётостроителей вообще на пальцах одной руки показать.
V>>Скажу так, каждый твой последующий аргумент всё слабее и всё более оно выглядит как будто ты топишь против конкретно Автодеска. _>Не, компания Autodesk мне вполне нравится. Мне не нравится неверное позиционирование AutoCAD в иерархии САПР.
Какая разница, что там тебе нравится, а что нет? ))
Ты рядом на голубом глазу путал Вольфрам Альфу с Математикой и ничего...
А по-факту, просто не понимаешь современной технологической цепочки.
Например, есть Автокад с предустанволенными плагинами — AutoCAD Architecture.
В нём выполняется т.н. "электронное ТЗ" после стадии эскизов.
Т.е. в э том пакете выходят на конкретные основные размеры, углы, направляющие линии и т.д.
Потом этот проект заливается в Revit (что-то типа Инвентора, только для строительства).
В этом Revit проект обрастаем "мясом" поверх ТЗ.
Компоненты для Revit могут быть изготовлены в том числе с помощью Inventor, бо тот является хорошим редактором самостоятельных сложносоставных 3D-объектов.
Еще неплохим вариантом является визуальное редактирование алгоритмов порождения 3D через Grasshopper.
Есть он как плагин для Revit.
Есть и обратное — весь Revit как плагин для Grasshopper. ))
Вернёмся к Автодеску.
Ближе к концу проект опять переезжает в Architecture для финального "вылизывания" через то самое 2D-3D черчение, ну и надобность готовой проектной документации еще никто не отменял.
А суть BIM состоит во всё большей автоматизации синхронизаций м/у различными специализированными системами с целью разделения работы над проектом в большой команде.
Здравствуйте, vdimas, Вы писали:
v> v>> Но целевой прикладной код в 1C нифига не нейтивный, а управляемый. v> DC>Кем управляемая, позвольте спросить? v> Средой исполнения.
В таком случае — любой код на С++ тоже управляемый.
Здравствуйте, DenisCh, Вы писали:
v>> v>> Но целевой прикладной код в 1C нифига не нейтивный, а управляемый. v>> DC>Кем управляемая, позвольте спросить? v>> Средой исполнения. DC>В таком случае — любой код на С++ тоже управляемый.
Здравствуйте, vdimas, Вы писали:
v> v>> v>> Но целевой прикладной код в 1C нифига не нейтивный, а управляемый. v> v>> DC>Кем управляемая, позвольте спросить? v> v>> Средой исполнения. v> DC>В таком случае — любой код на С++ тоже управляемый. v> Почему?
Потому что егоный код тоже управляется средой выполнения.
Здравствуйте, DenisCh, Вы писали:
v>> DC>В таком случае — любой код на С++ тоже управляемый. v>> Почему? DC>Потому что егоный код тоже управляется средой выполнения.
Этот твой поинт понятен.
Осталось обнаружить эту среду исполнения.
Итак, где она?
Здравствуйте, alex_public, Вы писали:
_>Ну да, начиная с какой-то версии они начали предоставлять не только COM интерфейс (как было изначально), но ещё и два C++ API и один .net API. Но мы же тут обсуждаем не это, а на чём написан сам продукт.
NanoCAD — платформа, как AutoCAD. Без дополнительных модулей — просто рисовалка, как AutoCAD.
NanoCAD ОПС — платформа + модуль для проектирования охранной и пожарной сигнализации, систем оповещения, пожаротушения, видеонаблюдения и контроля доступа. Он позволяет проектировать не в терминах квадратиков, кружочков и блоков текста, а в терминах конкретных реально существующих разного рода извещателей, оповещателей, контроллеров, исполнительных устройств и прочего, что выпускает народная промышленность. Базы оборудования прилагаются. Ты не рисуешь линию, ты прокладываешь кабель-канал, в котором лежит кабель существующей марки, и модуль ОПС знает, что именно по этому кабелю будет бежать: питание 230В, питание 12В, интерфейс RS-485 для связи с приборами, ДПЛС для связи приборов с адресными датчиками или ещё что. Подключаешь все входы и выходы оборудования друг к другу, собираешь всё в электротехническую модель, модуль ОПС её обсчитывает, автоматически маркирует оборудование на чертежах, сообщает о найденных косяках (данный кабель в данном количестве не поместится в данный короб, недостаточно мощности ИБП для подключённого оборудования, запиханные на бумаге в шкаф приборы в реальности в него не влезут и т.д.) и генерирует проектную документацию: спецификацию, кабельный журнал, структурную схему, ещё что-то.
И вот вся эта хренотень, которая делает из графического редактора что-то, что уже можно называть САПР, написана на NET.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Программист2013, Вы писали:
П>>Прилож-я на ASP.NET MVC довольно тормознутые как их не оптимизируй. Причем причину тормознутости никто не знает
K>Я в своё время сделал сайт на ASP.NET (тогда ещё MVC не было — мы практически "изобрели" его сами) со временем ответа в <80 мс при нагрузке в 60к запросов в секунду. Это на кластере из 4 серваков (2 веб и 2 app server'а). Сайт этот работает до сих пор (уже ~7 лет). K>Так что при наличии прямых рук всё возможно.
на счет 60 тысяч запросов в СЕКУНДУ... вроде даже у google.com столько нет 5 млрд в сутки
Здравствуйте, loginx, Вы писали:
K>>Так что при наличии прямых рук всё возможно. L>на счет 60 тысяч запросов в СЕКУНДУ... вроде даже у google.com столько нет 5 млрд в сутки
Мой софт временами держит 1 миллион запросов в секунду...
Здравствуйте, vdimas, Вы писали:
V>>>Дык, для этого COM АПИ и реализуется. V>>>Т.е. именно для VB и C#. _>>А почему не для 1C и Perl? У них тоже нет никаких проблем с вызовами COM API. V>Это тоже примеры не нейтива, т.е. это мой аргумент, не твой. V>А твой аргумент должен был быть в ответ на это: V>
V>Под чиста С++ был бы совсем другой АПИ.
Что-то ты запутался совсем. Мой изначальный тезис был про отсутствие Java/C# в мире CAD. А про то, что многие CAD системы выполнены по схеме C++ движок и какой-то скриптовой язык (python, lisp и т.п.) поверх него, я опять же не раз говорил в самом начале. )))
Что касается твоих последующих длинных и довольно любительских (похоже ты никогда не работал ни с проф. пакетами символьной математики, ни с Jupyter Notebook) рассуждений на тему сравнения Mathematica, Maple, Matlab и их современной альтернативы в виде Jupyter+Python+matplotlib+numpy+scipy+sympy, то я пожалуй не буду их комментировать. Потому как, хотя у меня есть много чего сказать по этой теме, но она является полным оффтопиком в данной дискуссии — ничто из перечисленного не относится к категории CAD'ов.
В первом приближении управляемым кодом называется код, выполнение которого управляется средой выполнения. В этом случае соответствующая среда выполнения называется общеязыковой средой выполнения или средой CLR, независимо от реализации (Mono, .NET Framework или .NET Core). Среда CLR отвечает за использование управляемого кода, его компиляцию в машинный код и последующее выполнение. Кроме того, среда выполнения предоставляет несколько важных служб, таких как автоматическое управление памятью, границы безопасности, безопасность типа и т. д.
1C интерпретатор. Никакой компиляции и сборки мусора нет.
С другой стороны .Net Native имеет сборщик мусора, но он нативный как D
Все таки среда исполнения не является фактором для определения управляемости. В том же C++ можно компилировать в исполняемом коде в библиотеки и использовать их динамически.
Использовать разного рода плагины.
Управля́емый код (англ. managed code) — термин, введённый фирмой Microsoft, для обозначения кода программы, исполняемой под «управлением» виртуальной машины .NET[1][2][3] — Common Language Runtime или Mono. При этом машинный код называется неуправля́емым кодом (англ. unmanaged code).
Слово «управляемый» (англ. managed) здесь относится к методу обмена информацией между программой и исполняющей средой. Оно означает, что в любой точке исполнения управляющая среда может приостановить исполнение и получить информацию, специфичную для текущего состояния. Необходимая для этого информация представлена в управляемом коде на языке Intermediate Language и в связанных с этим кодом метаданных.
С формальной точки зрения управляемым кодом является любой программный код, исполняемый в среде отладчика.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
_>>Развитие современных САПР идёт в направление создания законченной и готовой к производству модели автомобиля, самолёта и т.п., а не в размещение цистерны в сарае. ))) V>99.99% пользователей "современных СПАР" — строительные конторы.
Ууу, теперь понятно откуда у тебя такие извращённые представления о мире САПР.
V>Автомобилестроителей по пальцам рук и ног пересчитать можно. V>Самолётостроителей вообще на пальцах одной руки показать.
Конечно, только это был не исчерпывающий список, а всего лишь пара примеров. Посмотри вокруг себя — вся современная техника создана с помощью каких-то САПР. И любой транспорт (а не только автомобиль с самолётом) и любые машины, производственное оборудование, станки, да что угодно технически сложное. Но и это ещё не всё: это были примеры сложных механизмов (для которых оптимальны самые топовые САПР), а есть и другие области (только там оптимальны САПР уже среднего уровня). Взгляни например на мышку в своей руке — как ты думаешь, с помощью чего проектировался её корпус? А корпуса всей остальной твоей электроники и бытовой техники? )))
V>>>Скажу так, каждый твой последующий аргумент всё слабее и всё более оно выглядит как будто ты топишь против конкретно Автодеска. _>>Не, компания Autodesk мне вполне нравится. Мне не нравится неверное позиционирование AutoCAD в иерархии САПР. V>А по-факту, просто не понимаешь современной технологической цепочки. V>Например, есть Автокад с предустанволенными плагинами — AutoCAD Architecture. V>В нём выполняется т.н. "электронное ТЗ" после стадии эскизов. V>Т.е. в э том пакете выходят на конкретные основные размеры, углы, направляющие линии и т.д. V>Потом этот проект заливается в Revit (что-то типа Инвентора, только для строительства). V>В этом Revit проект обрастаем "мясом" поверх ТЗ. V>Компоненты для Revit могут быть изготовлены в том числе с помощью Inventor, бо тот является хорошим редактором самостоятельных сложносоставных 3D-объектов. V>Еще неплохим вариантом является визуальное редактирование алгоритмов порождения 3D через Grasshopper. V>Есть он как плагин для Revit. V>Есть и обратное — весь Revit как плагин для Grasshopper. )) V>Вернёмся к Автодеску. V>Ближе к концу проект опять переезжает в Architecture для финального "вылизывания" через то самое 2D-3D черчение, ну и надобность готовой проектной документации еще никто не отменял. V>А суть BIM состоит во всё большей автоматизации синхронизаций м/у различными специализированными системами с целью разделения работы над проектом в большой команде.
Ну даже если забыть про то, что сейчас в моде уже 4D BIM (позволяющие не только подобную интеграцию, но и планирование процесса строительства) и про то, что обсуждаемый изначально AutoCAD уж точно не имеет отношения к BIM (даже обычным 3D, типа Revit), то я так и не понял, с чего это ты вдруг решил, что имеешь право экстраполировать известный тебе процесс разработки из узкой области строительства, на весь мир САПР? Ни в каких других областях ничего подобного не наблюдается, т.к. там даже такого понятия как BIM нет.
Здравствуйте, alex_public, Вы писали:
_>Потому как, хотя у меня есть много чего сказать по этой теме, но она является полным оффтопиком в данной дискуссии — ничто из перечисленного не относится к категории CAD'ов.
Здравствуйте, Serginio1, Вы писали:
S> 1C интерпретатор. Никакой компиляции и сборки мусора нет.
Сборка мусора есть, как и в любом интерпретаторе.
S>С другой стороны .Net Native имеет сборщик мусора, но он нативный как D
Здра моя ра.
Код всё-равно управляемый.
После JIT-а тоже код нейтивный, но всё еще хорошо управляемый.
S>Все таки среда исполнения не является фактором для определения управляемости.
Всё-таки речь была больше не об этом, я управляемый код привёл лишь как пример.
А основной поинт в том, что прорва целевого прикладного кода писаны вовсе не на С++, а как раз на скриптах, VB, C#, Java и т.д.
Аналогия с 1С весьма показательна, аргументировать против невозможно.
S>В том же C++ можно компилировать в исполняемом коде в библиотеки и использовать их динамически.
Только это не С++, а С++/CLR.
S>Управля́емый код (англ. managed code) — термин, введённый фирмой Microsoft, для обозначения кода программы, исполняемой под «управлением» виртуальной машины .NET
И теперь этот термин широко используется для обозначения кода под любую виртуальную машину.
Твой скрипт в 1C сначала переводится в некий p-Code, потом исполняется.
S>Слово «управляемый» (англ. managed) здесь относится к методу обмена информацией между программой и исполняющей средой.
Верно.
Т.е. речь о том, что прикладная программа не общается с "железом" напрямую, а через некую контроллирующую прослойку.
S>С формальной точки зрения управляемым кодом является любой программный код, исполняемый в среде отладчика.
Это смотря какого отладчика.
Потому что одни отладчики могут вставлять ловушки-брекпоинты где угодно, а другие нет.
А разница в том, что первые реализуют эмулятор процессора (или используют специальный режим процессора), а вторые работают лишь на хуках, где эта техника не везде применима, например, при заходе в области расшареной памяти для бинарных образов кода.
Здравствуйте, alex_public, Вы писали:
_>>>Развитие современных САПР идёт в направление создания законченной и готовой к производству модели автомобиля, самолёта и т.п., а не в размещение цистерны в сарае. ))) V>>99.99% пользователей "современных СПАР" — строительные конторы. _>Ууу, теперь понятно откуда у тебя такие извращённые представления о мире САПР.
Остальные ~0.01% пользователей САПР-ов используют Matlab.
А всё, что ты там перечислял — это сотые доли процента от кол-ва всех юзверей всех САПР-ов.
V>>Автомобилестроителей по пальцам рук и ног пересчитать можно. V>>Самолётостроителей вообще на пальцах одной руки показать. _>Конечно, только это был не исчерпывающий список, а всего лишь пара примеров.
Исчерпывающий.
_>Посмотри вокруг себя — вся современная техника создана с помощью каких-то САПР.
Я уже говорил — каких.
_>Взгляни например на мышку в своей руке — как ты думаешь, с помощью чего проектировался её корпус?
Корпус мыша?
Я бы делал на плагине Grasshopper к Инвентору.
Это основной кейз сегодня для всяких "модных" криволинейностей.
Там за 5 минут можно накидать мышкой процедурную генерилку 3D-фигур и прикрутить рукоятки, которыми играть на глазах у заказчика, делая ей бока шире/уже, плавнее/изгибестее и т.д.
Это что-то типа визуального редактора вершинного шейдера, только выход идёт не на экран, а в модель Инвентора.
В любом случае, полноценный проект даже небольшого дома строитель-архитектор будет делать 2-3 месяца, если с 0-ля.
А корпусов мышек за рабочий день можно реализовать по эскизам добрый десяток.
Это совершенно несравнимые информационные размеры проектов.
Отсюда несравнимая потребность в рабочих местах проектировщиков.
_>А корпуса всей остальной твоей электроники и бытовой техники?
Инвентор?
Хотя, если речь о "просто корпусе" а-ля Китай, то можно использовать любую простейшую прогу твердотельного моделирования, и?
А если речь о сложном электронном девайсе, то корпус там идёт как часть проекта.
Вот как раз Inventor (с плагинами) + Eagle — от схематики, до разводки плат и 3D дизайна ВСЕГО устройства.
Полный цикл, однако.
Например, если надо ноут спроектировать или планшет какой.
Но таких контор, опять же, буквально единицы десятков во всём мире.
В миллионах остальных пользователей САПР-ов их не видно и под микроскопом.
_>Ну даже если забыть про то, что сейчас в моде уже 4D BIM (позволяющие не только подобную интеграцию, но и планирование процесса строительства) и про то, что обсуждаемый изначально AutoCAD уж точно не имеет отношения к BIM (даже обычным 3D, типа Revit), то я так и не понял, с чего это ты вдруг решил, что имеешь право экстраполировать известный тебе процесс разработки из узкой области строительства, на весь мир САПР? Ни в каких других областях ничего подобного не наблюдается, т.к. там даже такого понятия как BIM нет.
Да те области погоды давным-давно не делают.
Как только в более-менее приличный десктоп стала помещаться модель здания целиком, так фокус сместился на строительство.
Это всё не сравнимо, кароч, — любой проект самого сложного движка в твоей CATIA информационно будет на порядок проще BIM-проекта здания средней руки. И это при том, что движки разрабатывают единицы десятков контор по всему миру, а здания — сотни тысяч контор, если не миллионы (приводил уже пример — сотня контор только по нашему провинциальному Севастополю).
В общем я понял твою позицию, что САПР в которой можно спроектировать самолёт — это ерунда, по сравнению с САПР в которой можно заняться выбором двери между помещениями в своём сарае. Я (да и думаю мягко говоря не только я) с такой позицией конечно же не согласен, но твои взгляды это естественно никак повлиять не может, так что я не вижу о чём ещё можно продолжать дискуссию при таких различиях в базовых воззрениях.
