Создание больших сборок средствами Inventor API. Общие рекомендации.

Автор Тема: Создание больших сборок средствами Inventor API. Общие рекомендации.  (Прочитано 7881 раз)

0 Пользователей и 3 Гостей просматривают эту тему.

Оффлайн Александр РивилисАвтор темы

  • Administrator
  • *****
  • Сообщений: 13882
  • Карма: 1787
  • Рыцарь ObjectARX
  • Skype: rivilis
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн brigval

  • ADN Club
  • Сообщений: 17
  • Карма: 0
  • Подпись под аватаром
Меня всегда интересовал один вопрос. Допустим я соединил между собой детали в сборке некоторыми зависимостями.
Вариант 1. Теперь все детали зафиксирую, наложив зависимость "Базовый" ("Grounded").
Вариант 2. Сначала, удалю все зависимости между деталями и только потом зафиксирую все детали зависимостью "Базовый" ("Grounded").
Вопрос. Равноценны ли эти два варианта в плане повышения производительности или увеличивает производительность только варинт 2?

Оффлайн Владимир Ананьев

  • ADN DevHelp
  • *
  • Сообщений: 148
  • Карма: 8
Ответ определяется реализацией механизма (солвера), который управляет вычислением зависимостей.  Понятно, что второй вариант, как наиболее простой, должен быть выигрышнее.
Но вот насколько ему может проигрывать первый вариант, предсказать так вот просто не берусь.  Если солвер, видя Ground, более ничего не анализирует, разницы большой быть не должно (вроде бы :) ).

Каковы масштабы ваших моделей?  Сколько зависимостей (по порядку величины) вы убиваете, переходя к варианту 2?


P.S.
Тотальное убиение зависимостей - практически необратимая операция.  Это имеет смысл делать лишь во вполне конкретных ситуациях.
P.P.S.
Если интерес не платонический, можно побеспокоить носителей "тайн стиха".

Оффлайн brigval

  • ADN Club
  • Сообщений: 17
  • Карма: 0
  • Подпись под аватаром
Если интерес не платонический, можно побеспокоить носителей "тайн стиха".

Если вариант 1 равен варианту 2 по производительности, то управлять зависимостями становится очень удобно.
Вы можете побеспокоить "носителей" по этому вопросу?

Оффлайн Владимир Ананьев

  • ADN DevHelp
  • *
  • Сообщений: 148
  • Карма: 8
А какова, все же, размерность задачи, если измерять ее в количестве зависимостей?
Можно ли как-то оценить максимальную длину цепочки зависимостей?

Оффлайн brigval

  • ADN Club
  • Сообщений: 17
  • Карма: 0
  • Подпись под аватаром
А какова, все же, размерность задачи, если измерять ее в количестве зависимостей?
Можно ли как-то оценить максимальную длину цепочки зависимостей?

Ну скажем, в небольшом блоке 12 модулей. Для их крепления использовано 6 зависиомстей (сами модули и внты к ним). Получаем 72 зависимости. Плюс еще несколько элементов. Под 100 в блоке.
Это не самый большой вариант. При проектировании шкафов больше. Специально не считал. При загрузке шкафов загружаются 40000 и более компонентов и 1000 и более файлов. Это так, для наглядности того, что производительность имеет смысл.