БАЗИС 8. Составная фурнитура

Сообщение от sborchik

Но удобней создать ее отдельно в пространстве модели из погонного материала (штанга, труба джок.) и сохранить как фрагмент. И вставлять ее как фрагмент в модель. Тогда ее можно будет растянуть и в смету пойдут реальные метры..

Скоро и фурнитуру сможем вытягивать. А точнее, в состав фурнитуры можно будет вводить и панели, и погонаж, и профили - а после установки этой фурнитуры на модель Смета будет видеть не только штуки, а и все остальное.

[Am0ralist]

Вот пример: полка имеет отверстие, которое должно быть всегда на одну треть от левого края и на две трети от правого (имею ввиду центр отверстия).

если области делят между собой изменение длины полки пополам, то отверстие будет сдвигаться от левого края в сторону центра.
если же области делят изменение длины полки пропорционально своей ширине (а на рисунки области выделения 1 к 2 соотносятся), то отверстие всегда будет делить полку в нужных пропорциях. если же области будут одинаковые, то отверстие будет так же смещаться к центру, как и в первом случае.
Так что второе поведение - более настраиваемое и универсальное.

[Kudesnick]

Сообщение от Am0ralist

По факту - ЛРН вообще мимо кассы, так как по сути она разрывает контур и в разрыве добавляет новые линии, если линия и направление растягивания имеют угол между собой. И она (а) не растягивает весь объект, что мы хотим получить (б) работает только на одну область выделенную внутри контура (в) так что на примере, как ЛРН работает на одной области рассуждать о том, как должно происходить растягивание двух и более областей - бессмыслено.

Сообщение от Am0ralist

Э, мы только что про ЛРН рассуждали, а вы тут уже про резиновую. Это как бы два разных принципа. Резиновая нить сдвигает все точки в выделенной области и заново перестраивает связи между ними и незахваченными внешними точками, а ЛРН по сути разрывает линии в месте пересечения с контуром и соединяет получившиеся точки новыми линиями. так что вы как-то разделяйте в обсуждениях одно от второго, это два ПРОТИВОПОЛОЖНЫХ принципа. И совместить их - легко лишь в ваших словах.

Возможно я открою вам тайну, но ЛРН и резиновая нить - одно и тоже. ЛРН - Линейная Резиновая Нить.
В 2D построении построении есть две похожих функции: ЛРН и "растянуть и сдвинуть". В 3D - только "растянуть и сдвинуть". Согласен, называю эту функцию неверно, но как-то прижилось со времён БМ7. Тем не менее, спутать её с какой-либо друго в 3D режиме невозможно.

Сообщение от Am0ralist

повторюсь, ЛРН вообще не так работает, как вы пытаетесь описать.
вы, по сути,указываете несколько зон растяжения. И нет, растяжение вполне может быть пропроционально выделенным областям. То есть если мы выделили полосу А и полосу Б, которая шире А в два раза, то вытягивая суммарно на 30% мы получим, что 10% по факту ушло на А и 20% на Б. Иначе программистам в итоге все же придется реализовывать это именно так) Так как это будет универсальное решение.

Сообщение от Am0ralist

Так что второе поведение - более настраиваемое и универсальное.

Я вполне себе представляю, что выделение разными областями может работать пропорционально. Но это лишь усложнит процесс задания зон, а сама пропорциональность нужна крайне редко - гораздо чаще возникает необходимость разбить расстояние пополам: ручки на ящиках, двери-купе, тумбы с двумя дверьми и т.д.

Сообщение от Am0ralist

значит таки эти объекты - что-то совершенно новое, не правда ли?

В нынешнем понимании функции "Растянуть и сдвинуть" окно выделения используется единовременно - это прямоугольник на одном из видах. Это окно нельзя сохранить, удалить, редактировать.
Как раз, чтоб иметь возможность пользоваться функциями растягивания многократно это окно нужно зафиксировтаь (сохранить). И вполне логично, что прямоугольник на 3D-модели превращается в параллелипипед. По своим внешним характеристикам он напоминает габаритную рамку, т.е. опять же ничгео придумывать не надо - лишь совместить имеющееся.

Сообщение от Am0ralist

та же ошибка в логике. и ЛРН, и резиновая нить работают только на одну область выделенную. Мы сейчас обсуждаем множественное растяжение.

Множественное ничем практически ничем не отличается от единовременного.
Сначала программа узнаёт на какое расстояние нужно увеличить/уменьшить базовую модель. Затем делит это расстояние на две/три/четыре части, в зависимости от количество резиновых зон. Получившийся результат сначала добавляет к первой зоне, потом - второй и т.д. Всё постепенно.

[Am0ralist]

Сообщение от Kudesnick

Возможно я открою вам тайну, но ЛРН и резиновая нить - одно и тоже. ЛРН - Линейная Резиновая Нить.
В 2D построении построении есть две похожих функции: ЛРН и "растянуть и сдвинуть". В 3D - только "растянуть и сдвинуть". Согласен, называю эту функцию неверно, но как-то прижилось со времён БМ7. Тем не менее, спутать её с какой-либо друго в 3D режиме невозможно.

Открою вам тайну, тогда еще веселее. Обычная резиновая нить вообще никак не поможет, хотя бы потому, что в областях выделений НЕТ ТОЧЕК. А раз нет точек, то и сделать она ничего не сделает. Можете проверить.

Сообщение от Kudesnick

Я вполне себе представляю, что выделение разными областями может работать пропорционально. Но это лишь усложнит процесс задания зон, а сама пропорциональность нужна крайне редко - гораздо чаще возникает необходимость разбить расстояние пополам: ручки на ящиках, двери-купе, тумбы с двумя дверьми и т.д.

Сделать А и не сделать Б - глупо и черевато переделкой. Потому что как появится, так сразу и начнется ной, что нужно именно пропорционально. Потому что это только Вам оно не сильно нужно, а не другим. Это усложнит задачу только пользователям и то не сильно, если будет Ctrl+C.

Сообщение от Kudesnick

В нынешнем понимании функции "Растянуть и сдвинуть" окно выделения используется единовременно - это прямоугольник на одном из видах. Это окно нельзя сохранить, удалить, редактировать.
Как раз, чтоб иметь возможность пользоваться функциями растягивания многократно это окно нужно зафиксировтаь (сохранить). И вполне логично, что прямоугольник на 3D-модели превращается в параллелипипед. По своим внешним характеристикам он напоминает габаритную рамку, т.е. опять же ничгео придумывать не надо - лишь совместить имеющееся.

Офигеть, дайте два. "Совместить имеющееся"... Лом чем-то напоминает весло, давайте грести им, сидя в бочке - будет каноэ. Примерно так прозвучит ваше виденье в глазах программистов.

Сообщение от Kudesnick

Множественное ничем практически ничем не отличается от единовременного.

Вот это "практически" и выльется в написание абсолютно нового функционала с нуля. Так как ИИ еще не изобрели и приходится с компьютерами языком алгоритмов общаться. По факту сейчас подобного функционала нет вообще (исходя из того, как оно работает), и насколько из старого что подойдет - скорее всего не сразу скажет даже программист Базиса.

[Kudesnick]

Сообщение от Am0ralist

Открою вам тайну, тогда еще веселее. Обычная резиновая нить вообще никак не поможет, хотя бы потому, что в областях выделений НЕТ ТОЧЕК. А раз нет точек, то и сделать она ничего не сделает. Можете проверить.

Посыпаю голову пеплом. Конечно зоны указал неверно. Должно быть так:

И, соответственно, распределение расстояния меняется. Для каждой последующей (находящейся правее) зоны расстояние увеличивается на величину сдвига первой зоны.
Путём небольших арифметических вычислений получаем: х = d / 6.
Где х - величина сдвига первой зоны, d - общая величина сдвига.
Т.о. величина сдвига второй зоны равна: х * 2 = d / 3
величина сдвига третьей зоны равна: х * 3 = d / 2

Сообщение от Am0ralist

Сделать А и не сделать Б - глупо и черевато переделкой. Потому что как появится, так сразу и начнется ной, что нужно именно пропорционально. Потому что это только Вам оно не сильно нужно, а не другим. Это усложнит задачу только пользователям и то не сильно, если будет Ctrl+C.

Поймите, я совсем не против этого. Просто для этого надо предусматривать какой-то отдельный тумблер, потому что всегда в приоритете должно быть то, что требуется чаще и бОльшему количеству людей.

Сообщение от Am0ralist

Офигеть, дайте два. "Совместить имеющееся"... Лом чем-то напоминает весло, давайте грести им, сидя в бочке - будет каноэ. Примерно так прозвучит ваше виденье в глазах программистов.

Сообщение от Am0ralist

Вот это "практически" и выльется в написание абсолютно нового функционала с нуля. Так как ИИ еще не изобрели и приходится с компьютерами языком алгоритмов общаться. По факту сейчас подобного функционала нет вообще (исходя из того, как оно работает), и насколько из старого что подойдет - скорее всего не сразу скажет даже программист Базиса.

Вот только не надо мне рассказывать про сложности написания кода. Сколько знаю программеров, все, все до единого, после постановки какой-то задачи отнекиваются руками и ногами, мол это очень сложно, нереально, нужно всё переделывать. А в итоге получается, что гораздо больше времени уходило на спор и отстаивание нужной функции.

[St Bruno]

Kudesnick, Am0ralist, не нужно выделять никаких дополнительных зон, они уже существуют - это расстояния между точками, расположенными вдоль вектора смещения. Нужно всего лишь научить программу растягивать эти расстояния пропорционально и предоставить пользователю выбор: растягивать пропорционально или нет (как сейчас). При растягивании на видах - это дело техники, и я не вижу больших сложностей для такого алгоритма. Программа уже работает с этими зонами и точками. А как дополнительный функционал можно предложить выбор зон, которые во время выполнения команды не будут растягиваться.

[Koha]

Kudesnick,
Am0ralist,
Уважаемые- толк то будет от ваших словесных баталий? Если вы можете это сделать-так сделайте.Оба вроде как бы программисты.Так предложите свои услуги Базис.

[Am0ralist]

Сообщение от Kudesnick

Вот только не надо мне рассказывать про сложности написания кода. Сколько знаю программеров, все, все до единого, после постановки какой-то задачи отнекиваются руками и ногами, мол это очень сложно, нереально, нужно всё переделывать. А в итоге получается, что гораздо больше времени уходило на спор и отстаивание нужной функции.

Ответ: потому, что программист должен быть уверен, что вам нужно именно это и именно так.
Все. Иначе это выльется в "а тут еще рюшечку, а здесь переделайте вот так вот - это же недолго, ой, а мы тут кое-что забыли".
Что не отменяет того факта, что подобного функционала в базисе скорее нет, чем есть подходящий.

Сообщение от St Bruno

Kudesnick, Am0ralist, не нужно выделять никаких дополнительных зон, они уже существуют - это расстояния между точками, расположенными вдоль вектора смещения. Нужно всего лишь научить программу растягивать эти расстояния пропорционально и предоставить пользователю выбор: растягивать пропорционально или нет (как сейчас). При растягивании на видах - это дело техники, и я не вижу больших сложностей для такого алгоритма. Программа уже работает с этими зонами и точками. А как дополнительный функционал можно предложить выбор зон, которые во время выполнения команды не будут растягиваться.

для простой прямой панельки - это вообще не сложно - одинаковые прямые берут и одинаково растягиваются.
А проблема как раз для сложных контуров. И тут программе в любом случае придется указывать что растягивать, а что нет. И вопрос, как сделать это и явно, и удобно - касается в том числе и нас, так как у Базиса, если они возьмутся подобное реализовывать, не факт, что с первой попытки получится удачно...

Сообщение от Koha

Kudesnick,
Am0ralist,
Уважаемые- толк то будет от ваших словесных баталий? Если вы можете это сделать-так сделайте.Оба вроде как бы программисты.Так предложите свои услуги Базис.

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

[St Bruno]

Сообщение от Am0ralist

для простой прямой панельки - это вообще не сложно - одинаковые прямые берут и одинаково растягиваются.
А проблема как раз для сложных контуров. И тут программе в любом случае придется указывать что растягивать, а что нет. И вопрос, как сделать это и явно, и удобно - касается в том числе и нас, так как у Базиса, если они возьмутся подобное реализовывать, не факт, что с первой попытки получится удачно...

Так дело в том, что программа всё это уже делает, только разными командами по-разному. А нужно совместить и добавить математики. Конечно, есть какие-то нюансы, заложенные в алгоритме программы, но боюсь, их можно увидеть только с точки зрения базис-программиста, которому, как и всем нам, лень переделывать одно и то же. Но, такова его работа.

[yavsochi]

Сообщение от sborchik

Думаю вопросы и споры по заглушкам для евриков ушли в прошлое)))

Также стало удобно для петель составную фурнитуру подбирать .
С произвольной фурнитурой+составная также, но с помощью сборок ,сделал шуруп, включил её в сборку и в смете порядок

[Dima1313]

Возможность создания и установки произвольной составной фурнитуры – структурного элемента, в который может входить несколько различных типов фурнитуры, а также все остальные трехмерные элементы – панели, профили, тела и т.д. При этом после установки составной фурнитуры все эти элементы не объединяются под именем общей фурнитуры, а остаются теми же элементами, что и были при создании составной фурнитуры, и читаются модулями БАЗИС-Смета, БАЗИС-Раскрой и БАЗИС-ЧПУ.

В чем отличие от блока сборок? В каких случаях применять? и как?