То ж. На поточний момент вже опубліковані:

1. Порівняння CAD/CAM/CAE
2. 2D Sketching
3. Solid Modeling
4. Історичний екскурс
5. Surface Modeling

І настала пора поговорити про черговий блок, а саме про Параметрику та конфігурації.

Чесно кажучі, мені дуже дивно, чому людина яка огульно по всім пунктам ставила перевагу Fusion 360, і тільки в декількох пунктах написала “Зє Сейм” (не в сенсі Зеленський що виступає в польскому Сеймі, а в сенсі “the same”). Так от, мені дивно, що тут обійшлося без еківоків і перемогу віддали SW.

Чи це коректно? так, на мій погляд – коректно. Але давайте розбиратись.

І перш ніж порівнювати треба пояснити, що таке параметрика, яка вона буває, що вона дає і все таке. Але це довго. На старій версії Сапробасен, російською мовою це було десь 20+ публікацій. Якщо бажаєте побачити їх нову версію – пишіть, ставайте патронами і все таке. Короче, там досить багато роботи треба навіть щоб просто перекласти. Але

То ж Параметрика. Дехто Вважає, що, якщо в його моделі присутні якісь розміри в ескізах та “фічерах” і їх можна змінити – це вже параметрика. у в цілому воно так, але це приблизно те ж саме що розвалюху яка стоїть на цеглинах во дворі вже останні 50 років називати автомобілем.

І навіть якщо Ви це робите в потужному сучасному CAD

Ситуація буде не набагато краща. То ж розміри – це тільки перша цяточка. Конфігурації, рівняння (equation) – це вже краще, але також не все.

Зв’язок пращур/нащадок (parents/childrens) в тому числі у збірках між деталями, бібліотечні деталі та “фічери” це все також інструменти параметризації. Можна навіть сказати – “симптоми”, але не “причина” чи “хвороба”.

Головне в параметризації це ідея. Ідея яка полягає в тому, що ви свою модель/моделі створюєте таким чином щоб спростити і скоротити всі подальші роботи з цими моделями. Чи то Вам треба повторно використати ці деталі, моделі, збірки в інших проектах. Чи то Вам треба зробити проектний пошук і дослідити вплив окремих конструктивних параметрів і рішень на характеристики працездатності. Чи то Вам треба внести якісь косметичні зміни.

Ваша задача в тому, щоб для виконання будь якої подібної роботи Вам треба було витрачати якомога менше рухів, часу, дій. Не повторюючи весь, або майже весь процес побудови з нуля.

Це моя особиста точка зору, і це те, як я вчу своїх студентів.

Але, якщо це Ідея… то яке відношення це має до CAD? Ідея ж не має відношення до програми. І це дійсно так. Але хоч ідея і не має, можливість її реалізації – має.

Наприклад в PTC Creo (Pro/ENGINEER) я можу побудувати модель приводу (з курсу деталей машин) в якому повністю вся моя модель буде змінюватись від вхідних параметрів (момент, оберти, скільки часу воно повинно працювати) І електромотор, редуктор, кількість ступенів, вид корпусу, тип колес, і навіть діаметр болтів що будуть в редукторі та основи приводу з швелерів – все це буде автоматично, або автоматизовано обирати сам Creo. І відносно всього цього модель буде змінюватись. І байдуже там буде червячний редуктор чи циліндричний багатоступінчастий. АБСОЛЮТНО ВСЕ я можу закласти в параметри! Навіть обсяг мастила, та міцність чогось не тільки за емпіричними формулами, але і за розрахунками МСЕ (метод скінченних елементів). Реально Все. Принаймні в межах “курсача” ВНЗ. І все це буде зроблено без єдиної строчки коду, лише тими можливостями, що присутні в інструментах моделювання та параметризації Creo.

І повірте, навіть таке може спрацювати і зі значно більшими за обсягом збірками і зі значно більш складними задачами. Тут скоріш питання до користувачів і до доцільності такої глибини параметризації у реальному процесі проектування. Одна з речей якій я намагаюся навчити студентів:

не все, що МОЖНА параметризувати та автоматизувати, – ТРЕБА автоматизувати та параметризувати!

Друга, це як раз практичне набиття шишок, щоб виникло питання, а чи треба нам дізнаватися як глибока нора у кролика. І розуміння, що вона завжди глибша ніж здається.

Окей з Крео розібралися. Що стосується CATIA, NX – то там є трохи інші “плюшки”. На то всі вони і є CAD системами верхнього рівня.

Що стосується SW – не все, що можна відтворити в топах, тут також можна відтворити. Особливо без програмування. Але дуже багато. Що стосується Інвентору – трохи менше. Що стосується Fusion 360 – ще менше.

Можливості з параметризації у SW та Inventor можна оцінити десь +/- у 8, у Fusion – 6. І якщо Вам здається, що різниця невелика, то це у логаріфмічній шкалі. тобто 10⁸ та 10⁶. так, думаю буде трохи краще зрозуміле порівняння різниці.

Давайте по формальностям де можлива параметрика:

1. Ескізи
2. фічери
3. цифрофі параметри
4. рівняння
5. нецифрові параметри
6. конфігурації
7. бібліотечні інструменти
8. наслідкові зв’язки

Якісні характеристики параметрики:

1. наявність можливості
2. швидкість
3. обсяг/ємність
4. стійкість

Почну з другого.

З наявністю все просто – або вона є, або її немає. Ну наприклад Конфігурації – в СВ – є, в Фьюжі – немає.

Хоча не все так просто, може бути, але обмежене. А може бути, але сильно впливати на інші речі (наприклад на швидкість чи стійкість). А може бути формально, але відсутні тонкі чи ручні налаштування, що сильно обмежує можливості використання (принаймні в випадках складніших за 2+2).

Швидкість та обсяг часто взаємопов’язані. В принципі Швидкість обсяг та стійкість – теж. 😉 І частково це описано в попередньому абзаці.

Тож вони пов’язані але окремі, тому розглянемо Швидкість. У Вас є умовний ескіз з умовними 10 лініями в яких умовно 10 залежностей/обмежень (constrains) та умовно 3 розміри.

у вас є так само умовний ескіз з 100 лініями, і ескіз з умовними 1000 та 10 000 ліній.

Нам здається що логічно було б, якби швидкість була так само кратна. тобто 10 ліній – 0.001с, 100 ліній 0.01… 10 000 – 1 с. Але на практиці, 100 ліній буде оброблятися приблизно 0.1-1с, 1000 вже може думати до декількох хвилин, а 10 000 може взагалі не працювати

І от те наскільки швидко обробляються ті чи інші речі, наскільки повільно зростає час при збільшенні кількості елементів Y (наприклад в ескізі): чи то 2*Y чи 2^Y чи 10^Y чи 10^2Y чи 10^{Y^2} – це і є та сама швидкість.

Те скільки елементів система може обробити перш ніж почне глючити – це обсяг. А те наскільки процес буде передбачуваним, більш того не просто передбачуваним (як в анекдоті “точно за графіком”), а правильно передбачуваним (коли повільна та швидка зміна параметрів та налаштувань не змінюють топологію та всі інші “фізичні” параметри поведінки моделі) – це стійкість.

За моїм досвідом, допоки в SW використовувався чистий “вирішувач” DCM від D-cubed для параметрики, – він був більш крутим (як мінімум за стійкістю та обсягом) ніж зараз, з додатком/заміни частик функціоналу на власну, розробку від Dassault (та Ledas) (це суто особисті враження, довести в цифрах не можу. І це враження з високою вирогідністю – хибне)

На поточний момент SW та Inventor дуже схожі за наявністю, швидкістю, стійкістю обсягом, з перевагою до СВ але невеликою. Фьюж поступається Інвентору досить сильно. Особливо за стійкістю та обсягом. Імхо… але може колись ми це протестуємо більш детально

І тепер перейдемо до порівнянь місць з параметрикою.

Ескіз. (дивимось на 2D Sketching, але трохи тут розглянемо).

То ж базові об’єкти – однакові. Базові констрейни (обмеження, constrains) – однакові. Але є різниці. В СВ тип сплайнів можна змінювати після створення. І це дозволяє параметризувати будь який сплайн дуже різними способами.

Також вектори дотичності можуть в св бути не однаковими в різних напрямках, що іноді корисно. А також Дотичність і Кривина – краще контролюються вручну, констрейнами та параметрами в СВ. Окрім того в СВ до еліпсу, сплайну конічної кривої та кривої по рівнянню можна малювати дотичні об’єкти в довільному місці. А у фьюжі та інвенторі – дзуськи. Але у фьюжу можна проставити розмір на дотичність… і він працює більш адекватно ніж його аналог в св. Короче не все так однозначно… (с)

Але в СВ контролю трохи більше. Також в СВ можна задавати довжину дуги (дуже давно) і довжину довільного сплайну (не дуже давно). Ще раз, не контролювати – тобто заміряти результат, а саме задати. Повірте це дуже круто.

Також важливим є той факт, що в SW є така річ як блоки, і до речі з ними є додатковий цікавий функціонал, бо весь блок може працювати не тільки як сукупність об’єктів, але і як об’єкт.

У всьому іншому функціонал +/- схожий. І там, і там можна малювати будь які профілі, складні ескізи і навіть механізми, що будуть рухатись.
І там, і там чим більше об’єктів в ескізі – тим йому складніше. Чим більше розмірів, чим більше констрейнів – тим ще гірше.

Я цей пункт не перевіряв вже декілька років, і за цей час Autodesk декілька разів звітувала про покращення стабільності та швидкості параметрики ескізів, тому про поточний стан швидкості/ємності/стійкості я нічого сказати не можу. Коли тестував, це було десь так SW>Inventor>>F360. АЛЕ ТРЕБА ПЕРЕВІРЯТИ. Якщо є інтерес – пишіть. Буде значний інтерес – зробимо.

Що стосується не швидкості а стійкості – у мене до ескізів фьюжа і особливо до проецьованих об’єктів – завжди є зауваження. були, є, і продовжуються. Причому не тільки про сильних змінах вхідних параметрів, але і взагалі про те як вони працюють. Дуже часто глючать. Іноді це можна вирішити шляхом повільної зміни параметрів, але часто – ні. Окрім того є проблеми що в одному напрямку зміни працюють нормально, а у зворотньому – нажаль ні.

Це дуже сильно заважає контрольованості, а значить і параметризації.

Фічери

У фьюжа є одна фішка, яка є перевагою для маленьких простих проектів, і проблемою для великих чи складних. Мова йде про те, що у фьюжі з моменту створення не було різниці між збіркою та деталлю. З початку в цьому не було необхідності. Потім вона з’явилася і це реалізували костилем…. і так воно і залишилось.

Окей, а проблема в чому?

В “великих” системах не просто так роблять окремо спрощені: габаритні-моделі, що відповідають за параметризацію. Моделі, що доопрацьовують ті спрощені/габаритні до детальних об’єктів підзбірок та деталей з потрібним рівнем деталізації. Та потім знов збирають це в кінематичну/функціональну збірку (іноді також керуючи рівнем деталізації для різних задач).

Окрім того параметричну збірку та “кінематичну” розносять ще для того, щоб прості зміни положень об’єктів не примушували перебудовувати всю збірку при кожному русі, і не впливали на самі деталі. Тобто для кардинального спрощення роботи.

Чи означає цей абзац, що у Фьюжі такого зробити не можна? Ні!

Окей, так а тоді в чому проблема?

А проблема в тому, що ті хто проектують чи моделюють не знають про такі правила, вважають їх зайвими і не вміють працювати з таким “пайплайном”. Тобто за такими алгоритмами. Принаймні здебільшого. І по суті фьюж та автодеск це “заохочуть” “ускладнивши” процес роботи в подібному стилі і “спростивши” процес роботи “все в одному”. Так це зроблено через налаштування до задач цільової авдиторії, але це автоматично призводить до погіршення параметричних можливостей.

Якщо дуже умовно, то у автівок з меншими колесами та меншими габаритами є певні переваги в міських умовах, у порівнянні з великими машинами на великих колесах. Але на бездоріжжі вони мають значно менший теоретичний (і практичний) максимум всюдихідності ніж більш великі машини.

Так, я розумію, що тут можна навести приклад порівняння всюдихідності Suzuki Jimny та якогось Bugatti Veyron. Але я думаю приклад з колесами та базою – зрозумілий.

Так от такий підхід коли все в одному призводить до того, що в Вас вся збірка в одному файлі. І якби ці 2..10..20…100…1000 об’єктів створювались окремими файлами деталей, окремими підзбірками і все таке, то зрозуміло, що навіть якщо кожна б з деталей мала велику “історію” (ну тобто “дерево”, або “таймлайн”), то все одно, кожен об’єкт мав би складність не більше 100 фічерів (ну може в окремих випадках 200 але то вже край). І кожен раз Вам потрібно працювати не більш ніж з однією деталлю. кожен раз ви працюєте з 10..20.. ну 50 фічерами. не більше! А у фьюжі. Навіть якщо кожне тіло містить лише 10..20 фічерів, то при 20 об’єктах Вам треба розібратись з кашею в 100-400 фічерів. А якщо побудувати однакові збірки то Ви розумієте, що там де в SW чи Inventor ми працюємо з арифметичною прогресією. Тут по суті ми працюємо з геометричною. І через це, складність росте швидше, а контроль втрачається значно швидше. А з урахуванням того, що в Вас по суті дуже часто ще перемішуються фічери і зв’язки між різними деталями… З урахуванням того, що Ваша збірка є одночасно і параметричною і кінематичною…. Короче, це все дуже сильно б’є по МОЖЛИВОСТІ параметризації.

Так, у фьюжі можна редагувати “компоненти” таким чином, що нібито то окремі деталі. Так, у фьюжі ви ставите шарніри та зв’язки в певних місцях “таймлайну”. Що дає можливість дещо зменшити проблемність та відтягнути агонію, контролюючи проект трохи більший ніж без цього. Але це не є заміною. І якщо в класичному методі Вам буде потреба переробити одну окрему деталь, то тут в вас буде сипатись весь проект… що призведе до необхідності переробляти його весь. А це значно інші почуття. Імхо.

Цифрові параметри

Тож цифрові параметри. Вони є двох типів: ті що Ви задаєте і можете змінювати +/- довільно і ті що отримуються в результаті якихось обчислень . В першу чергу, “1. driving dimension” це параметри = розміри з ескізів, потім з фічерів. Що стосується Driven то він має підрозділи. В першу це чергу розміри в ескізах (“2. Driven Dimension”), але і розміри з аннотацій, а також певні інтегральні характеристики (“3. integral characteristic”): маса, об’єм, автоматичні габарити.

По першим майже все однаково (різниця описана там де говорили про ескізи та порівнювали солід/сюрфейс моделінг).

З другими різниць більше. у SW ці параметри та розміри є повноцінними і можуть як завгодно приймати участь в параметризації моделі (з урахуванням того, що їх не можна задати, вони тільки обчислюються). А от у F360 вони не є повність повноцінними. Ще десь півроку-рік тому вони взагалі не були суб’єктом параметризації. Тобто подивитися та проставити їх можна було (і доречі тільки в 2Д) а далі – дзуськи. Тобто ніде більше Ви це не могли використати. На сьогоднішній момент їх вже можна пррописувати в рівняння, в інші розміри, в поля керувань деякими фічерами. Але не всюди. Не всюди. Зовсім не всюди.

Проте сам факт, що через 8 років прохань від користувачів Autodesk цим все ж таки зайнялась – досить радісний. Бо це означає, що функціонал з’явиться. Бо як мінімум в Інвенторі це вже є. Треба лише почекати

Що ж стосується третього пункту. То тут все погано. В SW можна їх контролювати опосередковано – тобто, або ставити допуск який контролюється при перебудові моделі і видає сповіщення якщо щось не так, або робити оптимізацію параметрами першого типу контролюючи третій (автоматизовано, але не автоматично). В Інвенторі та фьюжі (без програмування) цього робити не можна (наскільки пам’ятаю).

Здавалося б яка різниця, адже ж ці речі завжди можна перевірити руками за потреби. Воно то так. Але коли це робиться автоматично чи хоча б автоматизовано – це значно краще.

Окей, а якщо СВ має можливості оптимізації, то чому це автоматизовано, а не автоматично?

Якщо б, не було PTC Creo та його модулю BMX (Behavioral Modeling eXtension), я б те ж вважав, що жодних проблем тут немає. Але в Крео можна сказати, що якась інтегральна характеристика (наприклад маса деталі) на певному етапі історії побудови повинна дорівнювати чомусь конкретному. І все далі можна про це не думати це так і буде. Завжди при будь яких змінах (якщо це взагалі можливо).

І коли порівнюєш всі три варіанти – тоді і розумієш наскільки це потужна штука. Особливо коли розумієш, що так можна робити скільки завгодно раз і з будь яким інтегральним параметром. так само як і з параметром 1го типу – driving dimension

Що ще слід сказати. У обох систем, через наявність певних приколів які заклали програмісти, є свої особливості в роботі. В SW максимальний габарит який може бути в моделі – 2км (наскільки я пам’ятаю). І Якщо Вам здається, що це дуже велика цифра і Вам воно ніколи не буде потрібно. Повірте, випадки бувають. Також не всюди можна ввести 0 чи від’ємне число

І жарт в тому, що, навіть, якщо ви ввели цифри, які теоретично допускаються, – у SW можуть бути проблеми з тим, що він не зможе одночасно опрацювати ці цифри. Спробуйте намалювати звичайний прямокутник з розмірами 1мм на 1 км… 😉 не завжди вийде. і навіть з більш адекватними розмірами можуть бути проблеми.

У фьюжа та інвентора свої приколи які іноді вилазять боком, і тільки в Autocad можна намалювати супутник з точністю до гвинтів та мікросхем на орбіті землі. З тією самою орбітою. Принаймні так казала Autodesk ще десь років 30 тому.

То ж треба бути готовим, що є певні обмеження. Про деякі ми написали. Про все інше – якось іншим разом.

Рівняння

Тут простіше зробити ось так:

• Autodesk Fusion 360, список функцій
• Autodesk Inventor, список функцій
• DS SolidWorks: рівняння, список функцій

Я навіть не буду порівнювати ані можливості, ані розміри розділів довідки, ані те наскільки просто їх знайти 😉 В кого буде бажання сам подивиться.

Що я можу сказати основні алгебраїчні, тригонометричні та логічні функції – тут є. Цього здебільшого вистачає всім.

Є певні різниці в структурі посилань на параметри, в обробці одиниць вимірювання і можливості використання результатів в різних місцях, але формально все досить схоже.

У SolidWorks є можливість створювати різні рівняння для різних конфігурацій (а самі конфігурації контролювати через Excel), а у Inventor можна робити все те ж саме але трохи іншим чином і теж не без Екселю.

У Fusion 360 все значно простіше.

Єдине що тут можна сказати, що треба контролювати циклічні змінні і той факт, що рівняння обчислюються на початку перебудови, але якщо є посилання на driven – то може бути ситуація коли доведеться оновлювати геометрію декілька разів, бо результати обчислень будуть змінюватись.

Як ви розумієте – це не дуже добра ситуація. І якщо прості випадки циклів “автомат” ловить і попереджає, то зі складними може не впоратись. Частково через це та той факт що у фьюжі “all-in-one” і не впроваджувлась можливість використання driven розмірів у рівняннях. Ну і звісно, що тепер задача контролю цього лежить для фьюжа на користувачі. І це трохи складніше відслідкувати, ніж у SolidWorks чи Inventor.

Також слід сказати, що у SW на відміну від Fusion 360 можна працювати не тільки з цифровими параметрами (всіх трьох типів), але й з текстовими. Що також буває досить корисним

Нецифрові Параметри

Здається, що як раз попередній пункт закінчився фразою про “нецифрові параметри” і не зрозуміло нащо тут ще один пункт як раз про це.

Але. Нецифрові параметри бувають різними. Це може бути текст, що треба нанести гравіюванням на корпусі (наприклад). Це може бути матеріал, колір..

Це може бути щось “логічне” (ifthen). Наприклад якщо товщина (маса, матеріал) деталі менша за робимо по одному, більша – по іншому. н

Це можуть бути нецифрові опції фічерів (через все, до об’єкту, на глибину)

Це можуть бути логічні “вибірки” геометричних об’єктів. Наприклад зробити закруглення всіх кромок, що виникли в результаті якоїсь операції. Або “всіх нових кромок окрім” і все це теж логічні параметри, але не ті що ifthen, а ті що можуть бути описані за допомогою якогось алгоритму чи логіки.

Так от, коли ми дещо зрозуміли про те які взагалі бувають параметри, ми можемо зрозуміти хто, що і як може змінювати і як це вплине на параметрізацію

Creo – все що завгодно, ну майже. Так, я розумію, що тут не йде мова про Крео, але коли розглядаєш щось, треба орієнтуватись на кращих. Так у Поверхнях ми посилалися на Icem Surf та Alias. В параметризації – на Крео.

Чому? Бо вони “бест, оф зе бест, оф зе бест, сєр! з відзнакою, сєр!”

А що ж до двох інших топів? Catia, NX? Вони пішли трохи в іншому шляху щодо параметризації. Вони вміють те що не вміє Крео, але не вміють того що вміє він 😉 І це не зовсім параметризація, скоріш автоматизація, тому тут ми це не будемо розглядати.

То ж Крео може все. Катя, НХ можуть майже все що може Крео. СВ може багато. Інвентор може трохи менше, але за рахунок iLogic – трохи більше. і Так в СВ те ж є апі та скріпти, але… Але в Інвенторі ці скрипти можуть бути частиною моделі. Частково СВ може виправитись через “макро-фичи” (macros feature). Але тут такі пішли тонкощі та ньюанси, що треба витратити ще декілька публікацій на порівняння. Тому як і у випадку Катя/Крео/Нх скажемо що Inventor та SolidWorks тут дуже схожі просто пішли різними шляхами.

Що стосується Fusion. В нього скрипти та аддони по суті впроваджувались не стільки як інструмент безмежного розширення можливостей і функціоналу, скільки як інструмент автоматизації рутини. Тому, нажаль тут з параметрами значно менше можливостей для роботи навіть через АПІ. Ну а без АПІ – можливостей ще менше

Десь так. йдемо далі?

Конфігурації

Тут все просто. В SW вони є. В AI вони є. у F360 – ще простіше, бо їх немає.

Є додатковий плагін. Але своїх можливостей – немає.

і в СВ і в Інвенторі конфігурації набувають додаткової потужності при інтеграції з MS Excel. І тут потрібно ще сказати, що саме з Excel а не з LibreOffice, OpenOffice чи ще якихось інших продуктах. Через те що тут питання не стільки в функціоналі таблиць, скільки конкретні об’єкти та функції API. А от плагін до фьюжу використовує Google Sheets. Що є прикольним.

Ну в цілому на цьому все. Дещо було сказано раніше. Але в цілому цього достатньо. Доречі, в мене є підозра, що якби хоч в якомусь вигляді у фьюжі були конфігурації, навіть дуже дебелі, то автор початкового порівняння і тут би написав що фьюж або кращій або рівний. А так був вимушений сказати, що св трохи краще. Ну а я свою оцінку теж дав (на початку).

Бібліотечні Інструменти

Тут все просто. Приблизно як і в конфігураціях.

В SolidWorks, Inventor – бібліотеки є. Причому як бібліотеки деталей, так і бібліотеки фічерів. Є можливість доповнювати ці бібліотеки своїми розробками. А от у фьюжі функціоналу бібліотек – немає. Взагалі.

І тут можна заперечити: а McMaster, а TraceParts? Але це такі ж бібліотеки Фьюжа, як і СВ чи будь якого іншого продукту. Це дуже круті бібліотеки, але вони не є параметричними, це по перше (хоча їм це не заважає) і вони є продуктонезалежними (тобто це їм теж не заважає). І якщо у якості бібліотек покупних деталей це ще можна використати, то от у якості своєї, чи бібліотеки фічерів – нажаль вже неможна.

Наслідкові Зв’язки

Як би дивно це не звучало, але ВСЯ параметрика в CAD побудована на наслідкових зв’язках.

Все базується на Ескізах. А Ескізи базуються на площинах та гранях. Площини базуються на гранях, вершинах, кромках (які були утворені фічерами, що базуються на ескізах) та ескізах. Об’єкти ескізів базуються на об’єктах що створені раніш (проекції, співпадіння, перетинання, рівняння). А ще об’єкти ескізу зв’язані між собой за допомогою констрейнів та розмірів. Фічери базуються на інших фічерах, чи посилаються на них. А сюди ще рівняння. А сюди ще зв’язки у файлах збірок на моделі що входять до них. А сюди ще зв’язки в деталях на об’єкти і підоб’єкти збірок в які вони входять. А сюди ще той факт що збірка може бути побудована на основі багатотільної деталі, деталі пов’язані з іншими деталями напряму, без збірки. І багато чого іншого.

Короче, “Дім, який побудував Джек”.

І все це працює на ідеї зв’язків. То ж щоб називатися кращим, треба не тільки мати можливості послатися на щось, зв’язати щось. Але і контролювати це, керувати цим, робити заміну (за потреби).

Через те що Фьюж був орієнтований на непрофесіоналів які про це нічого не знали, то, нажаль, в ньому цей функціонал, по суті, відсутній як клас. Точніше посилатися можна але лише автоматом. А от контролювати та керувати цим процесом вже не вийде. На сьогодні, вже, дещо існує. Але у порівнянні з Інвентором, Солідом – це крапля в морі. А ті в свою чергу мають дуже обмежений функціонал у порівнянні з Топами (Катя, Крео, НХ).

Ну і нагадую що важлива не тільки можливість як факт, але й стійкість, швидкість, обсяг. А це через те що у фьюжі моделі все в одному – знов трохи проблемне. дуже “трохи”

То ж. Маю надію, що я дещо розкрив цей напрям і цей пункт. Але думаю, що повинно бути купа питань – то ж агов в коментарі. Буду вдячний