Обойдусь без вступительного слова. Здесь продолжение темы из "Вопросов начинающего".
Цитата
Андрей Мальчук написал: Однако, накал страстей) Методологию проектирования в флексе можно условно разделить на 2 направления: 1. Гибридная методика проектирования, по Алексею Плотникову - для тех, кому нужно что-то сделать, не углубляясь в нюансы параметризации и не сильно заморачиваться) Данная методика хорошо изложена в обучающих материалах и подходит для быстрого старта. Широко используется создание РП по граням, проецирование на РП ребер и пр. элементы не безопасной привязки к 3Д геометрии. 2. Продвинутая методика проектирования, по Алексею Чекмазову - для тех, кому нужна стабильность модели, возможность предсказуемой параметрической модификации в широком диапазоне значений. Определённо требует понимание того, что делаешь и понимание результата этих действий. Выбор разработчиков библиотек, мини-САПР и пр.Выбор той или иной методики проектирования обуславливается опытом, знаниями и задачами, стоящими перед разработчиком. Но всегда стоит помнить и понимать, что проект может править другой человек, и важно, чтобы он смог оперативно разобраться всех хитросплетениях мысли автора) p.s. с Хабра:Правил собственный код 9-ти летней давности. Как же я страдал (((...
Если говорить именно о проектировании, то я за комбинированный метод, начинается работа в сборке, из которой затем выгружаются фрагменты. Если предполагается кинематика, то лучше такие фрагменты делать изначально в файле и вставлять в сборку. Также, если сложные фрагменты, которые при выгрузке из сборки могут терять геометрию, то делаю снизу-вверх. Но в основном, когда надо быстро накидать концепцию сборки, делаю способом сверху-вниз. По-поводу продвинутой методики проектирования "имени Алексея Чекмазова" это слишком громко сказано. Но согласен с тем, что конструирование снизу-вверх возможно, когда хорошо представляешь, что хочешь получить в итоге, и конечно, в таком случае надо говорить не о прокетировании, а о конструировании изделия.
Если говорить о предмете спора, то, считаю, его надо именно проектировать, т.е. строить модель с учётом внесения необходимых изменений. Имею ввиду не параметризацию, типа изменения размеров или добавления новых тел на разные слои и последующее управление их видимостью, имею ввиду возможность изменения геометрии тела, типа операции. И чтобы всё можно было контролировать в едином пространстве сборки. Например, в модели Sila Musli, конечно можно сделать клапана тем же способом, что сделал и я, но значительно большими усилиями, чем сделал клапана я по его технологии (см. видео). Я добавил пару слоёв, пару профилей, пять операций и ни одной переменной, получил практически то же самое в одной сборке.
ps. С Хабра. Если человек правил код, наверное имелось ввиду разбирался с переменными? А если бы переменных было меньше, только самые основные и очевидные и в одном файле, а не в трёх, может и страданий было бы меньше?
ВладиславКМВ, проектирование сверху-вниз, при всём его видимом удобстве и простоте, таит в себе ряд подводных камней: потерю геометрии и высокие шансы встречи с рекурсией. Это не недостатки самого метода, а скорее ограничения в его текущей реализации, в 15м каде.
Цитата
ВладиславКМВ написал: По-поводу продвинутой методики проектирования "имени Алексея Чекмазова" это слишком громко сказано.
нет) Вы просто не занимались созданием библиотечных элементов, вроде тех, над которыми работал я: когда, казалось бы - тривиальная задача создания колена или тройника, затягивается не на одну неделю из-за того, что нужно реализовать универсальный общий случай, а не ряд частных. и основная проблема - вырождение геометрии при некоторых значениях из рабочего диапазона. Вот тогда и приходит понимание, что рекомендации Алексея не брюзжание, а практический опыт по набитым ранее шишкам. Потому, что это работает) Дабы не быть голословным: в приложении пример, можете по-изучать, поиграться и, попробовать реализовать по-своему. Кстати, на этом примере хорошо видны плюсы и минусы многотела ( по сути - частного случая проектирования сверху-вниз ) Чтобы лучше было понятно: под методикой Алексея понимается набор правил при проектировании, который основан на более глубоком понимании работы када. Например: не строить 3Д пути по 2Д путям. Вот казалось бы: почему? А причина в том, что в в кадах, по 15й включительно, 2Д пути - это полилинии, т.е. продукт аппроксимации кривой отрезками, с некоторой точностью. Вы можете в этом легко убедиться сами: постройте окружность и измерьте ее длину. А потом создайте по этой окружности 2Д путь и измерьте его длину. Значения после запятой будут отличаться. Вроде не критично, до тех пор, пока не станет задача проектирования лопаток винтов или турбин.
речь шла про программирование, про стиль написания кода, рефакторинг и про прогресс человека в этом деле) это про то, что, чем больше ты над собой работаешь, в профессиональном плане, тем сильнее понимаешь, на сколько корявыми были твои начальные проекты)
ВладиславКМВ, проектирование сверху-вниз, при всём его видимом удобстве и простоте, таит в себе ряд подводных камней:..... а еще и аппаратные средства ограничены. Столкнулся с ограничение метода сверху-вниз, стенд простой: гидростанция - стол, на столе сменные комплекты испытания Г/А, и обычные шланги РВД, проложить их лучше сверху-вниз, (в контексте сборки, а не по направлению ), но на 3... 5 РВД машина тормозит и теряет геометрию. Хотя прокладка рукавов-проводов-трубопроводов само просится. но ой потом вся работа на смарку.
Андрей Мальчук написал: Дабы не быть голословным: в приложении пример, можете по-изучать
В сборке нет фрагментов.
Цитата
Андрей Мальчук написал: Вы просто не занимались созданием библиотечных элементов, вроде тех, над которыми работал я
У меня есть библиотечные элементы - кухонные модули, я их конструировал, т.е. собирал снизу вверх, т.к. простая и понятная задача, нет совместной модификации геометрии для составных частей (за редким исключением, типа угловых модулей и их столешниц), а есть только модификация размеров, которые я делаю через переменные. Я говорю о том, что есть более сложные задачи, чем создание известных библиотечных элементов. Вот прилагаю свою сборку. Скажите, каким бы способом вы собирали такую сборку с учётом того, что делалась она не по чертежам, а по изображениям (причём аксонометрическим), но с необходимостью последующего уточнения формы и размеров?
Цитата
Шурик написал: ВладиславКМВ , проектирование сверху-вниз, при всём его видимом удобстве и простоте, таит в себе ряд подводных камней:
Думаю, я у себя тоже нашёл бы не один пример, когда выбор способа пр. сверху-вниз был неудачным. Я же не утверждаю, что этот способ универсальный и единственно правильный. Я просто хочу сказать , что противоположная безальтернативная точка зрения неверна. Не буду приводить примеры сложных работ типа проектирования производственного оборудования, причём в качестве прототипа у которого картинки из интернета и краткое описание для потребителей, Которое, если бы я делал строго снизу-вверх с соблюдением всех правил передачи параметров из сборки, да ещё со всеми возможными вариантами (а их было как минимум два да по каждому узлу) то делал бы не 7 месяцев, а гораздо дольше и, возможно, сломал бы голову . Возьмём очень простое изделие (см. приложение), сборка из четрёх деталей. Каким бы способом вы его проектировали с учётом тех же данных, что и у меня, т.е. картинка и примерный размер головной сборки?
ВладиславКМВ написал: Скажите, каким бы способом вы собирали такую сборку с учётом того, что делалась она не по чертежам, а по изображениям (причём аксонометрическим), но с необходимостью последующего уточнения формы и размеров?
Снизу-вверх. Создал бы прототип с, условно говоря - разметкой сборки в 3Д, использовал бы этот прототип для создания фрагментов, и в последствии - сборки. Тут больше вопрос привычки) Когда я делал свою библиотеку - у меня были изделия и некие правила, которые предстояло "узаконить". Ни чертежей, ни картинок, ни техпролцессов не было. Точнее, оно то вроде и было, но ни разу не соответствовало действительности. Был каталог продукции, в котором в таблицах, ошибка на ошибке) А в новом каталоге, волевым решением учредителя были изменены некоторые габаритные размеры. Вот только таблицы, значения которых после этого "поехали" - никто исправлять не стал) Видели бы Вы по каким "креативам" мне приходилось работать))) На их фоне рисунки или картинки - это чертежи с техпроцессами)
Андрей Мальчук написал: Снизу-вверх. Создал бы прототип с, условно говоря - разметкой сборки в 3Д, использовал бы этот прототип для создания фрагментов, и в последствии - сборки. Тут больше вопрос привычки)
Возможно, да, привычки. К плохому привыкают также, как и к хорошему. Я обойдусь без переменных, а в вашем случае без переменных не обойтись. Но такой труд напрасный, т.к. сборка имеет только одно исполнение. Один раз отработать все четыре фрагмента на одном эскизе и зафиксировать в выгруженных деталях. И всё.
Успех это способность идти от одной неудачи к другой без потери энтузиазма. (У.Черчиль)
ВладиславКМВ, тогда проще сделать многотелом и не заниматься выгрузкой тел. Если работа разовая - тогда проще многотелом делать. Смотрели пример из поста №6?
ВладиславКМВ написал: В дереве две детали, а в сцене одна? В чём шутка?
скорее всего это сделали новой опцией на теле "деталь-создать", ранее она еще называлась "доработка" - сразу совет, ни при каких условиях этой опцией не пользоваться, результат всегда неоднозначный =( Т.о. нужно пользоваться "деталь - выгрузить".
SaprOnOff86 написал: "деталь-создать", ранее она еще называлась "доработка" - сразу совет, ни при каких условиях этой опцией не пользоваться, результат всегда неоднозначный
SaprOnOff86 написал: сделали новой опцией на теле "деталь-создать", ранее она еще называлась "доработка" - сразу совет, ни при каких условиях этой опцией не пользоваться, результат всегда неоднозначный
Так кто-нибудь раскроет эту страшную тайну? Что в этой функции не так? Что там всегда неоднозначно получается? Я пару раз пробовал и все было вроде бы нормально.
B_S_V написал: Что в этой функции не так? Что там всегда неоднозначно получается?
На некоторых простейших примерах все получается, но на других примерах уже нет: попробуйте сделать кубик, рассеките его пополам, и из одной из половин выгрузите в деталь. Как только у выгружаемые тел в деталь остается какая-то топологическая зависимость - результат выгрузки приходится самостоятельно анализировать... Справедливости ради нужно сказать другие системы это либо вообще не умеют(NX в том числе: преобразование тела в файл с автоподстновкой в сборку, с поддержкой истории построения), либо тоже не ахти как.
SaprOnOff86 написал: NX в том числе: преобразование тела в файл с автоподстновкой в сборку, с поддержкой истории построения
Поясните. В NX выгружается всё и подстановку делает и с деревом и без дерева. Единственное, часть ненужную скрыть в телах надо будет это если с построениями выгружать. А так выгрузит и оставит в сборке изначальные построения если нада, или удалит если не нада. Потом можно связать сборку с деталировкой путём замены к примеру базового элемента, что в ТФ сделать нельзя. На данном этапе развития NX в плане работы со сборками намного мощнее чем TF. Покажите что не умеет NX, я такого не знаю.
Sila Musli, ну коллеги, работающие в НХ, сообщили что выгрузить дерево построения нельзя, если не сложно можете опровергунть видео-показом? 1. нарисовать куб 2. поставить отверстие 3. рассечь куб по оси отверстия 4. выгрузить тела в файлы 5. поменять отверстие(не прямым моделированием) в разных файлах. 6. показать сборку из "полукубиков" с разными диаметрами отв.