Сообщений в теме: 825

[a_max]

Вот только не уверен, что это все Вам нужно.

Как это, как это, ради этого все и писалось .

 

Понятно.
На вопрос, нужно-ли это все нам наверное лучше ответит a_max.
Я так думаю, что все эти конусы и цилиндры появились в докадовскую эпоху, когда надо было точно начертить проекции.
Да, использование конусов и цилиндров позволяет сохранить развертываемость в плоские листы. Но они и так будут плоскими, если их делать лентами по одной грани шириной и с жесткими ребрами. И не закручивать винтом.
Вообще у слоя есть свойство Developability. Может лучше математику сделать, чтобы не давала неправильно гнуть/крутить такие панели?

У нас все сейчас очень хорошо, чуть доработаем, и построение РО никакой проблемы представлять не будет. При условии понимания теории таких поверхностей конечно.

Математические изыскания на эту тему проводились в большом судостроении, но решали они совершенно другие задачи.

Уже почти составил план корректировок для инструментов.  Но чет дел навалилось, на днях выложу.

[a_max]

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

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

 

Не понял проблемы с цилиндрическими поверхностями. Можно делать цепочные/веерные зависимости/якорения...

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

[mm7]

Выложил 5.0.35

https://github.com/m...ases/tag/5.0.35

 

 

Для цилиндров нужно "якорение" ребер с сохранением параллельности.

[Wt_Terpi]

Я так думаю, что все эти конусы и цилиндры появились в докадовскую эпоху, когда надо было точно начертить проекции.

Именно так, способ построения достаточно древний. И сейчас методы проекционного черчения (2D) практической ценности при создании поверхности корпуса не имеют.

Кстати, в начальный период использования CAD - использовалось и проекционное черчение по полной программе и моделирование поверхностей было "проволочным".

 

Да, использование конусов и цилиндров позволяет сохранить развертываемость в плоские листы. Но они и так будут плоскими, если их делать лентами по одной грани шириной и с жесткими ребрами. И не закручивать винтом.
Вообще у слоя есть свойство Developability. Может лучше математику сделать, чтобы не давала неправильно гнуть/крутить такие панели?

А вот сам способ моделирования разворачивающейся поверхности как поверхности собранной из конусов и цилиндров имеет право на жизнь.

Более того, в настоящий момент полагаю, что данный метод является единственно правильным.

Тут следует пояснить, что мое мнение по этому вопросу постоянно претерпевало изменения. ...

Долго описывать методы которые применялись годами, тонкости их применения, преимущества и недостатки и почему переходил от одного к другому. Но сейчас, если нужен разворачивающийся корпус, то в первом приближении создаю грани. по ним поверхности как лофт по двум соседним граням с прямыми образующими. В некоторых случаях этого уже вполне хватает. Потом если все ОК делаю окончательные поверхности из участков конусов и призм. Если обратить внимание, то Орка делает разворачиваемые обводы из конусов и призм.

Поверхность, составленная из конусов и призм, разворачивается гарантированно и с абсолюной точностью. Про остальные, к сожалению, этого сказать нельзя. Рино конечно может развернуть не совсем разворачиваемую поверхность и даже совсем не разворачиваемую, но при этом может быть и ошибка в контуре. Было некоторое количество корпусов у которых была сделана развертка в Максурфе и Рино и при наложении разверток была видна ощутимая разница. Кроме того, полагаю, что такую поверхность можно будет экспортировать без ошибок. При этом возможно даже, что поверхности будут слегка отличаться - к сожалению зачастую математика различных CAD отличается и отличаются даже кривые перекинутые из одного CAD в другой. Но такие поверхности останутся жестко и однозначно разворачиваемыми.

[mm7]

Именно так, способ построения достаточно древний. И сейчас методы проекционного черчения (2D) практической ценности при создании поверхности корпуса не имеют.

Кстати, в начальный период использования CAD - использовалось и проекционное черчение по полной программе и моделирование поверхностей было "проволочным".

 

А вот сам способ моделирования разворачивающейся поверхности как поверхности собранной из конусов и цилиндров имеет право на жизнь.

Более того, в настоящий момент полагаю, что данный метод является единственно правильным.

Тут следует пояснить, что мое мнение по этому вопросу постоянно претерпевало изменения. ...

Долго описывать методы которые применялись годами, тонкости их применения, преимущества и недостатки и почему переходил от одного к другому. Но сейчас, если нужен разворачивающийся корпус, то в первом приближении создаю грани. по ним поверхности как лофт по двум соседним граням с прямыми образующими. В некоторых случаях этого уже вполне хватает. Потом если все ОК делаю окончательные поверхности из участков конусов и призм. Если обратить внимание, то Орка делает разворачиваемые обводы из конусов и призм.

Поверхность, составленная из конусов и призм, разворачивается гарантированно и с абсолюной точностью. Про остальные, к сожалению, этого сказать нельзя. Рино конечно может развернуть не совсем разворачиваемую поверхность и даже совсем не разворачиваемую, но при этом может быть и ошибка в контуре. Было некоторое количество корпусов у которых была сделана развертка в Максурфе и Рино и при наложении разверток была видна ощутимая разница. Кроме того, полагаю, что такую поверхность можно будет экспортировать без ошибок. При этом возможно даже, что поверхности будут слегка отличаться - к сожалению зачастую математика различных CAD отличается и отличаются даже кривые перекинутые из одного CAD в другой. Но такие поверхности останутся жестко и однозначно разворачиваемыми.

имеется ввиду, если они в один ряд? или как футбольный мяч?

 

[Wt_Terpi]

имеется ввиду, если они в один ряд? или как футбольный мяч?

На каждой грани последовательно в ряд.

Но формально, лграничений нет.

[mm7]

У нас как бы все из трапеций. Но это управляющая сеть. Она задает поверхность. И тут уже зависит от ребер (жесткие / "мягкие") и вертексов угловые или "мягкие".
Если сделать все ребра жесткими, то все будет прекрасно разворачиваться по этим трапециям (и иногда треугольникам).
Но обычно нужны плавные обводы. И тут могут быть проблемы с разворачиваемостью (сокр Р). Поверхность, посчитанная алгоритмом subdivision/averaging ведет себя как эластичная сетка натянутая на рамку. И может прогибаться даже на упр сети сделанной цилиндрами и конусами, нарушая Р.
Говоря о математике, я и имел ввиду сделать этот SD/A алгоритм так, чтобы он не нарушал Р. Но не знаю пока как.

a_max тянет в сторону НЮРБСов. Но это значит делать совсем другой движок. Пока неясно как совместить НЮРБСы с поверхностями в существующем движке.

 

Сообщение отредактировал mm7: 10 июня 2020 - 19:49

[Wt_Terpi]

Тут ничего посоветовать не могу.

Но, полагаю, что нюрбсы были бы правильным выбором базовой математики для кривых и поверхностей.

Для примера скажу, что то, что в Автокаде базово математика кривых (и поверхностей) не использует нурбс представляет некоторую проблему при экспорте в автокад. Так или иначе приходится скидывать как 2D чертежи так и например раскрой в dwg или dxf и достаточно часто, если приглядываешься, замечаешь некоторые мелкие неприятные отклонения обусловленные как раз отсутствием этой базы.

 

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

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

[mm7]

Да, согласен, зерно в этом есть. А_макс что-то пробовал в Автокаде. Но тоже чем-то остался недоволен.

Добавлять надо будет создание корпуса, в том числе гладкими методами, без Р-я. Сейчас уже много делают формуя из композитов, а не из фанерных листов.
ГС, ГД и тп добавлять...
Но тогда это будет - вечно догонять Орку...

 

[Wt_Terpi]

Да, если начинать на другой платформе, то работы действительно дофига.

А сейчас кого догоняете? Дельфт, максурф, си солютион? Ну и как, легче стало?

Но я вот полагаю, что одна из ключевых причин того, что Марин дизайн отъели хороший кусочек торта была в том, что они правильно выбрали стратегию и платформу, а не в том, что их код шибко лучше. С чегой-то такой гордый Mаксурф вдруг обзавелся прямым экспортом в Рино?

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

Кстати если уж речь зашла о пластике. На самом деле в реальном проекте из пластика надо столько теории нарисовать кроме обводов корпуса, что волосы дыбом встают когда вспоминаешь. Палуба с кокпитом как правило более трудоемкая чем корпус, хренова куча выформовок, подформовок, обнизок и подставок, внутренние секции, паук, крышечки... И все это с уклонами, переходами и радиусами, ... чтобы скучно не было.

Ну и где извините это все лучше рисовать?

 

Я кстати не уверен, что базой в таком случае должен быть именно Рино. Есть достаточно много популярных пакетов.

Но каждый кулик свое болото хвалит - я рисую в Рино, а не в Автокаде, Инвенторе, Компасе, Солиде...

Если идти таким путем, то надо тщательно взвесить и очень аккуратно выбрать.

[mm7]

Да, если начинать на другой платформе, то работы действительно дофига.

А сейчас кого догоняете? Дельфт, максурф, си солютион? Ну и как, легче стало?

Но я вот полагаю, что одна из ключевых причин того, что Марин дизайн отъели хороший кусочек торта была в том, что они правильно выбрали стратегию и платформу, а не в том, что их код шибко лучше. С чегой-то такой гордый Mаксурф вдруг обзавелся прямым экспортом в Рино?

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

Кстати если уж речь зашла о пластике. На самом деле в реальном проекте из пластика надо столько теории нарисовать кроме обводов корпуса, что волосы дыбом встают когда вспоминаешь. Палуба с кокпитом как правило более трудоемкая чем корпус, хренова куча выформовок, подформовок, обнизок и подставок, внутренние секции, паук, крышечки... И все это с уклонами, переходами и радиусами, ... чтобы скучно не было.

Ну и где извините это все лучше рисовать?

 

Я кстати не уверен, что базой в таком случае должен быть именно Рино. Есть достаточно много популярных пакетов.

Но каждый кулик свое болото хвалит - я рисую в Рино, а не в Автокаде, Инвенторе, Компасе, Солиде...

Если идти таким путем, то надо тщательно взвесить и очень аккуратно выбрать.

Так-то оно так. Но вы на проектировании возможно деньги зарабатываете. А для меня этот проект бесплатный. Потому много сил вложить не могу. Началось с того, что мне надо было спроектировать доску и посчитать ее литраж и сопротивление. Потом посмотрел, Тимошенко этот проект забросил, Дэлфт начали свой, закрытый. Я тогда взял исходники и перенес ФШ в Линукс. Просто перенес. Для забавы. А потом и для Виндовз стал компилить. Потом начались добавления, улучшения ...

Сейчас мы по некоторым штукам не догоняем, а перегоняем ДэлфШип.

 

начинать на другой платформе - это надо команду спецов по кораблям, ГС, ГД, КАДам, программеров, проджект менеджеров... целую компанию. Для нее надо финансирование... А для этого исследование рынка.. А тут уже на рынке  Рино, Максюрф, Орка ... Вряд-ли что выгорит.

 

Про пластик я вообще только о корпусе думал. Но вообще да, можно и кокпит сделать из пенопласта и заламинировать стеклом.

А что, сделать кокпит из листового материла в КАДе проще? Тоже наверно деталюшек много.

Я как-то никогда не думал ориентировать ФриШип для серьезной профессиональной разработки. Для самодельщиков - сделать корпус, обводы, прикинуть водоизмещение и сопротивление, требуемую мощность и скорость... А остальное уже как у кого получится.

[a_max]

Да, если начинать на другой платформе, то работы действительно дофига.

А сейчас кого догоняете? Дельфт, максурф, си солютион? Ну и как, легче стало?

Догонять нам вообще никого не надо, я именно за это и агитирую. Надо сразу обойти.. всех но не во всем .И задел для этого уже есть.

На другой же платформе применить отработанные принципы никогда не поздно. В чем то готовая платформа поможет, а чем то создаст трудности.

Причем чем круче платформа, тем больше трудностей может возникнуть. 

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

P/S Хорошо что вы наконец нашли время заскочить в тему  .

[a_max]

Я как-то никогда не думал ориентировать ФриШип для серьезной профессиональной разработки. Для самодельщиков - сделать корпус, обводы, прикинуть водоизмещение и сопротивление, требуемую мощность и скорость... А остальное уже как у кого получится.

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

[mm7]

Цилиндр можно задать уже существующими инструментами.

1. Создать точки основания и вершины цилиндра Cyl1, Cyl2
2. Создать точки направляющих A1,A2, B1,B2, C1,C2. Проследить чтобы они были параллельны и образовывали цилиндр.
3. Жестко заякорить A1,B1,C1 на Cyl1 и A2,B2,C2 на Cyl2
4. Выровнять (постоянно) точки борта на линии A1-A2, B1-B2, C1-C2

теперь можно таскать Cyl1, Cyl2 - участок борта будет смещаться с сохранением цилиндричности.

Прикрепленные изображения

• 

[a_max]

Цилиндр можно задать уже существующими инструментами.

1. Создать точки основания и вершины цилиндра Cyl1, Cyl2
2. Создать точки направляющих A1,A2, B1,B2, C1,C2. Проследить чтобы они были параллельны и образовывали цилиндр.
3. Жестко заякорить A1,B1,C1 на Cyl1 и A2,B2,C2 на Cyl2
4. Выровнять (постоянно) точки борта на линии A1-A2, B1-B2, C1-C2

теперь можно таскать Cyl1, Cyl2 - участок борта будет смещаться с сохранением цилиндричности.

Чет не очень понял. Вы бы файлик прикладывали.

Тут пионерам тестовый швертботик ваяю, с транцами, вспомнилось что вы говорили про выравнивание точки по плоскости (заданной 3 точками). Может сделать такое тоже? В максюрфе такая фича есть. В некоторых случаях очень даже кстати будет.

Разметка в этом релизе осталась пока так же. Не правили еще?

Еще-при попытке Save as-вылет..Лог-в файле.

Прикрепленные изображения

• 

Прикрепленные файлы

•  Save_as.txt   1,4К   135 Количество загрузок:

Сообщение отредактировал a_max: 13 июня 2020 - 03:06

[mm7]

фаил приложил

 

> вспомнилось что вы говорили про выравнивание точки по плоскости (заданной 3 точками).

 

Я говорил про автовыравнивание по 3-м основным плоскостям, не по произвольной. В основном для того, чтобы точки, лежащие на ДП у=0, оставались всегда на ней. Но в более общем случае, точта заблокированная относительно плоскости, даже на расстоянии от нее, т.е. в данном измерении, может двигаться в других измерениях.

 

>Разметка в этом релизе осталась пока так же. Не правили еще?

 

что за разметка?

>Еще-при попытке Save as-вылет..Лог-в файле.

 

правлю ...

 

Прикрепленные файлы

•  cyl-constraint.zip   26,6К   119 Количество загрузок:

Сообщение отредактировал mm7: 13 июня 2020 - 20:52

[a_max]

Я говорил про автовыравнивание по 3-м основным плоскостям, не по произвольной. В основном для того, чтобы точки, лежащие на ДП у=0, оставались всегда на ней. Но в более общем случае, точта заблокированная относительно плоскости, даже на расстоянии от нее, т.е. в данном измерении, может двигаться в других измерениях.

 

что за разметка?

Я так понимаю сам принцип работы параметризации взаимосвязей у вас отработан. И можно просто различные алгоритмы применять.В Максюрфе есть инструмент-выравнивание по 3 точкам, Align to plane (Moves a number of selected control points into the plane defined by the first three control points selected. To constrain the movement in certain directions hold the shift key down whilst selecting this command. A dialog box will appear within which you define the constraints). Надо наверное уравнение плоскости по трем точкам, и уравнение на плоскость.В общем выведу вычисления. 

 

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

 

Ваши построения посмотрел, но вы решили задачу которая очень редка. Мои построения обеспечивали как перемещение ведомого ряда точек (верхних) с наклоном образующих, так и перемещение точек попарно с регулировкой формы кромок но без изменения наклона образующих. Попробуйте, я вроде подробно описал как работает. И вот такая задача встречается часто.

Сообщение отредактировал a_max: 14 июня 2020 - 00:41

[mm7]

Я так понимаю сам принцип работы параметризации взаимосвязей у вас отработан. И можно просто различные алгоритмы применять.В Максюрфе есть инструмент-выравнивание по 3 точкам, Align to plane (Moves a number of selected control points into the plane defined by the first three control points selected. To constrain the movement in certain directions hold the shift key down whilst selecting this command. A dialog box will appear within which you define the constraints). Надо наверное уравнение плоскости по трем точкам, и уравнение на плоскость.В общем выведу вычисления. 

 

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

 

Ваши построения посмотрел, но вы решили задачу которая очень редка. Мои построения обеспечивали как перемещение ведомого ряда точек (верхних) с наклоном образующих, так и перемещение точек попарно с регулировкой формы кромок но без изменения наклона образующих. Попробуйте, я вроде подробно описал как работает. И вот такая задача встречается часто.

 

Дело в том, что для программы все точки равны, что разметочные, что нет. Т.е. надо вводить для точки тип/флаг - конструкционная она или разметочная.

Пока можно сделать просто, чтобы свободные точки не учитывались в общих и ГС размерах.

 

[a_max]

Дело в том, что для программы все точки равны, что разметочные, что нет. Т.е. надо вводить для точки тип/флаг - конструкционная она или разметочная.
Пока можно сделать просто, чтобы свободные точки не учитывались в общих и ГС размерах.

Я думаю там уже использовался существующий какой то . В старом же фришипе не реагирует разметка на точки. Только на грани. У вас тоже так было, но в каком то из релизов сбилось, подозреваю что с свободными кривыми.
 
Формулы нашел для Alighn to Plane , там не сложно в общем, правда с матрицей. Я в эксель по-простецки забью, но есть и программные способы решения ее с рекурсией и еще как то , типа универсальные. 

Прикрепленные изображения

• 
• 
• 
• 

Сообщение отредактировал a_max: 14 июня 2020 - 02:52

[mm7]

Точки исправил. Они ранее не влияли на Мин-Макс размеры из-за другого бага.

 

Хорошо. В программе какая-то формула есть. Но поверхность задана не 3-мя точками, а матрицей коэф-тов.

3D plane: a*x + b*y + c*z -d = 0.0;

 

Я пока новшества вводить не буду. Надо пофиксить баги.

[mm7]

Я так понимаю сам принцип работы параметризации взаимосвязей у вас отработан. И можно просто различные алгоритмы применять.В Максюрфе есть инструмент-выравнивание по 3 точкам, Align to plane (Moves a number of selected control points into the plane defined by the first three control points selected. To constrain the movement in certain directions hold the shift key down whilst selecting this command. A dialog box will appear within which you define the constraints). Надо наверное уравнение плоскости по трем точкам, и уравнение на плоскость.В общем выведу вычисления. 

 

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

 

Ваши построения посмотрел, но вы решили задачу которая очень редка. Мои построения обеспечивали как перемещение ведомого ряда точек (верхних) с наклоном образующих, так и перемещение точек попарно с регулировкой формы кромок но без изменения наклона образующих. Попробуйте, я вроде подробно описал как работает. И вот такая задача встречается часто.

Сделал и так. И к цилиндру примкнул конус. Борт стал "фанерным".

 

Сделал имена точек видимыми на 3-Д.

Прикрепленные файлы

•  cyl-constraint.ftm.zip   18,66К   113 Количество загрузок:

Сообщение отредактировал mm7: 14 июня 2020 - 18:40

[a_max]

Сделал и так. И к цилиндру примкнул конус. Борт стал "фанерным".

 

Сделал имена точек видимыми на 3-Д.

Ну так все равно через группу. Только точек у вас больше. Сейчас нюанс в том что можно только конус от группы можно сделать зависимым, а хотелось бы наоборот, так более применимо на практике. Вот на карттинке. Сейчас группа С2 задает наклон образующих J2K2 и  J3K3 и соответсвенно положение вершины конуса Cone5 которая выровнена на крайнюю образующую. Сдвигая группу мы меняем и конус. Но на практике удобнее двигать Cone5 а группа C2 ( точки C22 и C23) двигались по выравниванию.Сейчас если для точки группы назначить выравнивание, то по нему будет двигаться только эта точка. Если можно добавить в группу свойство перемещение ее (всю) выравниванием то будет более гибко в использовании.

Прикрепленные изображения

• 

Прикрепленные файлы

•  Test_strake_2.ftm.txt   30,44К   129 Количество загрузок:

[mm7]

Ну так все равно через группу. Только точек у вас больше. Сейчас нюанс в том что можно только конус от группы можно сделать зависимым, а хотелось бы наоборот, так более применимо на практике. Вот на карттинке. Сейчас группа С2 задает наклон образующих J2K2 и  J3K3 и соответсвенно положение вершины конуса Cone5 которая выровнена на крайнюю образующую. Сдвигая группу мы меняем и конус. Но на практике удобнее двигать Cone5 а группа C2 ( точки C22 и C23) двигались по выравниванию.Сейчас если для точки группы назначить выравнивание, то по нему будет двигаться только эта точка. Если можно добавить в группу свойство перемещение ее (всю) выравниванием то будет более гибко в использовании.

 

Это баг, надо править...


 

[a_max]

Это баг, надо править...

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

[mm7]

Можно назначить разные ограничения, но если мы двигаем точку A, то B и C тоже должны двигаться в том же направлении, если они все в группе, и потом уже к ним применяются их ограничения.
А в данном случае они не двигаются. Т.е.  - баг. Я вроде правил его...

 

 

исправил зум колесом мыши. Сейчас зумит с центром под курсором.

Сообщение отредактировал mm7: 15 июня 2020 - 22:45