Операция Transform

[koluna]

Здравствуйте!

OS: Linux Mint 18.1 Serena
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.13528 (Git) AppImage
Build type: None
Branch: releases/FreeCAD-0-17
Hash: 5c3f7bf8ec51e2c7187789f7edba71a7aa82a88b
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedKingdom (en_GB)

1. При выполнении данной операции, появляющиеся оси координат, за которые двигать и вращать, часто находятся в очень неудобном месте. Таскать за стрелки неудобно! Как я понимаю, это связано с локальной системой координат объекта? Можно ли это исправить?
2. Почему не получается применить Transform сразу более чем к одному объекту?

[DeepSOIC]

При выполнении данной операции, появляющиеся оси координат, за которые двигать и вращать, часто находятся в очень неудобном месте. Таскать за стрелки неудобно! Как я понимаю, это связано с локальной системой координат объекта? Можно ли это исправить?

Да, именно так. Исправить можно, но слишком сложно.

Почему не получается применить Transform сразу более чем к одному объекту?

Не предусмотрели. Можно сгруппировать объекты операцией Part Compound, и двигать Compound. Однако это не всегда приемлемо, потому что оригиналы остаются на месте. А разделять этот Compound потом как-то не красиво.
Второй вариант - запихать детали в контейнер Part, и двигать контейнер. К сожалению, большинство интрументов не "видят" эту передвинутость. В 0.18 передвинутую копию со "впечатанным" местоположением от Part можно создать инструментом Shapebinder, и то не без применения хитростей. Для 0.17 можно применить инструмент Ghost с адд-он верстака Part-o-magic.

[koluna]

Да, именно так. Исправить можно, но слишком сложно.

Можно в двух словах описать, пожалуйста?
Я поэкспериментировал немного. Нарисовал эскиз прямоугольника с одним углом в (0, 0). Выдавил.
Оси при Transform заняли удобное положение - прямо на детали в этом углу
Перенес угол в эскизе прямоугольника в другое место. Оси при Transform - как описано выше, неудобно расположены.

Второй вариант - запихать детали в контейнер Part, и двигать контейнер. К сожалению, большинство интрументов не "видят" эту передвинутость.

Так, я в глубокой депрессии
Это что получается, работа с контейнером Part реализована криво?
Я тут только собрался привести свое "дерево" в нормальный вид, раскидав все по созданным Parts, а тут - грабли
Инструменты не видят - как это проявляется? Чем это грозит? Это что получается, контейнер Part - бессмысленный элемент?

Практический пример группировки, которую я предполагал.
Стол принтера. В Part XXX запихиваем все детали стола: горизонтальная часть, вертикальный задник, две укосины снизу.
Ось Z. В Part YYY запихиваем все детали: винт, валы, держатели валов, винта, гайка, подшипники...
Какие ограничения на такие Part с учетом "невидимости" может при этом быть?

Для 0.17 можно применить инструмент Ghost с адд-он верстака Part-o-magic.

А что дает этот инструмент и какие он накладывает ограничения?

[DeepSOIC]

Можно в двух словах описать, пожалуйста?

Да нет проблем.

1. переместить штуку так, чтобы глобальное начало координат совестить с нужным углом или ценнтром чего-нибудь.
2. Выделить штуку, Part Make Compound (в меню верстака Part обитает).
Готово. Но неудобно же, ведь штуку придётся передвинуть.
С контейнером Part можно поступить аналогично, используя ещё один Part вместо Compound.

[DeepSOIC]

Так, я в глубокой депрессии
Это что получается, работа с контейнером Part реализована криво?

Ну в общем да.


Пример. Кидаем кубик и цилиндр. Кубик в один Part, цилиндр в другой.
Теперь спаяем их (Part Fuse). Fusion будет в корне.
Теперь переместим любой из Part. -> Fusion не изменится. А в Report View появится warning, что-то типа "Links go out of allowed scope".

Решается эта проблема через Ghost/Shapebinder. Делаем Ghost цилиндра и кубика в корень, и спаиваем привидения вместе. Так, Fusion будет следовать за перемещениями Part, Part001.

Ghost содержит свой маленький набор грабель. Он не может импортировать геометрию внутрь Part, если к Part.Placement привязаны формулы. (вытаскивать геометрию ИЗ Part с формулами он может. Проблема возникнет например если импортировать кубик в Part цилиндра, а Part цилиндра управляется формулами. Проблема возникает потому, что в таком случае невозможно подобрать последовательность пересчёта объектов - возникает циклическая зависимость).

[koluna]

С контейнером Part можно поступить аналогично, используя ещё один Part вместо Compound.

Т. е., Part с деталями помещаем еще в один Part и его уже двигаем?

[koluna]

Ндас...
Кстати, с группами тоже самое?
А, может, совсем не использовать контейнер Part и все объекты по одному перемещать?

[DeepSOIC]

Кстати, с группами тоже самое?

Группы (то, что со значком папки в дереве) неперемещаемы, так что там этой проблемы нет в принципе.

[koluna]

Группы (то, что со значком папки в дереве) неперемещаемы, так что там этой проблемы нет в принципе.

Да, туплю

Эксперимент в Part.
Создал цилиндр, сферу, деталь. В деталь поместил цилиндр и сферу. Деталь передвинул с помощью трансформа. Все нормально.
Выполнил внутри детали над ее объектами булеву операцию. Результат уехал в исходную точку - ненормально.
Вы это имели в виду, когда говорили "не видят"?

В Part Design теже проблемы?
Создал два тела, деталь, в деталь поместил тела. Передвинул деталь. Все нормально.
Делал в телах детали вырезы, фаски - все нормально.
Хотел попробовать выполнить булеву операцию не получилось (Boolean operation with two or more bodies), но это, видимо, уже другой вопрос

[DeepSOIC]

Создал цилиндр, сферу, деталь. В деталь поместил цилиндр и сферу. Деталь передвинул с помощью трансформа. Все нормально.
Выполнил внутри детали над ее объектами булеву операцию. Результат уехал в исходную точку - ненормально.

И да и нет. Просто булева операция в корень падает. Если затолкать и булеву операцию тоже в Part, то всё нормально будет (а если включён Part-o-magic, и Part активна, то операция автоматически попадёт в Part.