Не помню писал или нет - кнопка merge с указанием threshold в vertex manipulation mode для автоспайки вертексов. Позволит нивелировать косяки работы клиптула с большими брашами, обусловленные точностью этих ваших флоатов кажется (отслаивающиеся фейсы и одиночные вертексы).
Рассмотрите такие варианты:
1. Сделать в Clipping tool выделение брашей в 3d, а так же в проектция, при зажатом shift.
2. Окно Наложения текстуры прикреплять по краям
3. В вертесе выделение прямоугольником.
Кажется, я напутал.
Я делал опцию KeepDefaultEpairs, которая позволяет не удалять ключи, которые в данном классе прописаны в fgd как дефолтовые. По умолчанию она false, что препятствует "наращиванию" числа ключей при смене энтитей.
Но все остальные ключи - скажем, введённые вручную - остаются. Если юзер их ввёл - почему бы ему самому их не удалить? Ведь для чего-то же он их вводил! А если при смене энтитей мы будем удалять ключи - а напомню, что Джек не умеет отменять изменения в ключах - то мы будем терять их НАВЕКИ.
XaeroX писал: Если юзер их ввёл - почему бы ему самому их не удалить?
Навряд ли юзер вспомнит что именно он вводил. Тут такая тема, вот допустим если меняешь класснейм у Кварка, то все поля, которые не соответствуют данной энтите выделяются в отдельный список и сразу видно что дефолтное, а что левое. А Джек судя по всему мешает всё в кучу, вот народ и путаетцо.
В чём вообще удобство ключей остающихся в энтити при изменении класса? Это сделано по чьей-то просьбе или просто получилось как побочный эффект архитектуры?
> если класснейм вводить вручную
Проблема, что он это класснейм меняет не по нажатию на энтер, а хватает всё подряд,что попадает под паттерн по мере ввода -- в результате набирает всякое плохое.