KiCad с годами стал намного лучше, но при этом ему по-прежнему недостаёт возможности рисовать плавные, закруглённые дорожки с каплевидными падами (teardrops). И хоть многие находят этот функционал не особо нужным, в его пользу существует ряд аргументов, которые и привели к реализации данного проекта, а именно двух плагинов — для скругления дорожек и формирования каплевидных подводов.

Предыстория и мотивы


Так выглядели многие ранние, рисованные от руки печатные платы, каждая дорожка на которых была плавной и слегка изогнутой:

Из PDP-8

Старый осциллограф

Плата управления памятью ядра Data General Nova 3 (из chookfest)

Сдвиговый регистр из оборудования космической программы Apollo

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

Некоторые преимущества каплевидных падов и скруглённых дорожек оспариваются, но я приведу наиболее общепринятые:

  • изогнутые углы потенциально уменьшают вероятность ошибиться при травлении;
  • в случае несоосности просверлённого отверстия и пада каплевидный подвод снижает вероятность прорыва дорожки;
  • в гибких печатных платах острые углы концентрируют напряжение, поэтому их устранение снижает вероятность перелома дорожки;
  • использование произвольных углов позволяет делать более плотную разводку;
  • также может наблюдаться повышение электромагнитной совместимости (ЭМС), поскольку острые переходы создают резкое изменение импеданса.

На последнем пункте люди обычно останавливаются отдельно. Опыты показывают, что на частотах ниже ГГц разница оказывается незначительной. Поэтому многие разработчики утверждают, что ввиду отсутствия преимуществ от ЭМС смысла в подобном подходе нет. Но меня реально задевает мнение людей в духе «Только невежды, которые не разбираются в EMC, станут стремиться к закруглённым дорожкам».

Здесь я хочу указать на два важных момента:

  • каплевидные пады и закруглённые дорожки круто смотрятся. Некоторые делают их такими даже просто ради красоты;
  • отсутствие поддержки функционала, который реализован в других программах CAD, вызывает отток пользователей. К примеру, для проектировки гибких плат я не использую KiCad.

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

Ещё этот функционал можно добавить через «экшен-плагины», то есть скрипты Python. Такой способ намного ограниченнее, но зато исключает необходимость рекомпиляции исходного кода KiCad.

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


Существующие решения


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

Я нашёл ещё один репозиторий, который переупаковывает предыдущий скрипт как экшен-плагин, хотя на сборках Windows он не работает. Ввиду ужасной цепочки зависимостей и проблем релизы KiCad для Windows статически упакованы с помощью Python 2 и старого wsWidgets API. Проблема эта незначительна и касается только диалогового окна GUI.

Тем не менее обе версии скрипта имеют ещё один проблемный нюанс, который, на первый взгляд, может быть незаметен.


Алгоритм поэтапно скругляет углы, отсекая дорожки при каждой итерации, если их угол превышает установленное пороговое значение. Точка отсечения определяется либо параметром максимальной длины, либо процентным отношением этой длины к длине текущей дорожки – выбирается наименьший вариант. Однако алгоритм не учитывает изменение длины, происходящее непосредственно в процессе закругления – в результате чего оно никогда не получается симметричным.

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


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

Корректировка подразделения


Эта операция скругления, по сути, представляет собой двухмерную версию Subdivision Surface (подразделения поверхности), которую можно наглядно продемонстрировать в Blender (с помощью Catmull-Clark):


При этом стоит помнить, что разделение применяется равномерно, здесь нет никаких параметров, кроме количества итераций. Тот факт, что экшен-плагин запрашивает два дополнительных неясных параметра (length % и scaling %) уже настораживает. Нам нужно ограничить максимальный радиус изгиба, но для этого требуется всего один параметр.

Если порыться в исходном коде, то выясняется, что length % — это величина укорачивания, определяемая кратчайшей дорожкой на пересечении. Разобраться с этим было непросто, но предустановленное значение 50% означает, что проходов требуется вдвое больше.

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


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


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


В скругляющем скрипте при установке length % на четверть сегменты будут получаться не совсем одной длины. Но это всё ещё не объясняет странные результаты, которые мы наблюдали. На деле основная проблема скрипта в том, что после срезания угла длина сегмента изменяется, и для следующего угла используется неверное значение.

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


Тем не менее результат меня всё ещё не удовлетворял. Чтобы обеспечить идеальное скругление, нужно добавить фактор косинуса. Я порисовал на бумаге треугольники и придумал новую формулу для высчитывания процента длины сегмента. Подставив её в скрипт, мы, в конце концов, проходим самый сложный тест – квадрат. Если скругление будет работать корректно, то он должен превращаться в идеальный круг.


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

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


Превосходно. А теперь самое сложное…

Каплевидные подводы


В репозитории flexRoundingSuite реализована некоторая поддержка каплевидных подводов, но недостаточно качественная. В ещё одном репозитории предлагается подход получше с использованием заливки зон. Это даёт отличное преимущество в виде полного отсутствия ошибок DRC, поскольку, если нет места для подвода, то медная заливка пада автоматически отступит.

Однако в моём случае корректно сгенерировалось всего несколько подводов. Алгоритм предполагает, что каждая дорожка подходит к паду или отверстию прямо, никогда не отклоняясь от оси, что оказывается верным лишь в некоторых случаях. Опять же, можно пройтись по печатной плате и подправить их вручную, но меня такой вариант не устраивает.


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

Для этого я добавил в плагин использование кубических кривых Безье. У кубической кривой есть четыре точки: начало, конец и две контрольных. Если мы обеспечим, чтобы и первая, и вторая контрольные точки, которые соединяются с отверстием и дорожкой соответственно, были касательными, то кривая всегда будет переходить в них плавно. Остаётся разобраться, какой «вес» нужно установить для каждой из этих двух точек.

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

Чтобы этот вопрос прояснить, я нарисовал в Photoshop кривые и поэкспериментировал с ними.


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


Если ширина подвода меньше 100%, точку сопряжения необходимо немного повернуть. На скриншоте ниже всё выглядит не сильно печально, но оставлять это так не стоит.


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


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

Совмещение скриптов


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


Здесь мне представилось два варианта решения. Первый – это отредактировать скрипт, чтобы не сегментировать дорожки, расположенные слишком близко к паду. Второй – это отредактировать плагин генерации подводов, чтобы он считывал ситуацию, следовал по дорожке вдоль её изгиба и начинал формировать подвод с дальней стороны назад. И хоть первый вариант выглядит проще, чаще всего мы имеем ситуацию с небольшим изгибом 450 сразу перед отверстием, и если его не закруглить, то подвод должен будет принять очень странную форму. Так что я склонился ко второму решению.

На этом этапе я, пожалуй, выскажусь по поводу написания скриптов на Python для этих экшен-плагинов. Я уже говорил, что здесь используется Python 2 для Windows и Python 3 для Linux. Плагины кэшируются, поэтому любое внесение изменений влечёт за собой перезапуск KiCad. Печально то, что большинство сообщений об ошибках сбрасываются в /dev/null, но если их перехватить, то они наверняка окажутся неверными, так как их информация будет относиться к не кэшированным файлам Python. Мне кажется, здесь должно быть решение (простое удаление файлов .pyc не помогло), но я его так и не нашёл.

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

Как бы то ни было, но больше всего я недоволен слабой документацией. Есть немного справочного материала по doxygen, но он не имеет прямого отношения к представленному Python API. Похоже, что лучше всего искать помощи в чужих экшен-плагинах. Майлс МакКу, который упоминается в исходном коде нескольких плагинов, ведёт блог, где можно найти много полезной информации.

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


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

Как видно на картинке выше, это не даёт идеального результата для произвольных, нереалистичных углов, но при использовании разумных или скруглённых дорожек итог получается именно таким, на какой я рассчитывал.


Поигравшись с параметрами, я получил другие результаты, но все они оказались достаточно удовлетворительными. Если вам нужны реально жирные капллевидные пады, то теперь они возможны!


Есть здесь и пограничный случай – когда при следовании по дорожке встречается несколько путей. В ситуации с T-перекрёстком, закруглённом в гладкую Y, следование только по одной дорожке приводит к формированию подводов странной формы. Поскольку удачного способа исправить это нет, то при встрече на дорожке развилки код у неё останавливается и помещает в этом месте небольшой подвод. Так результат получается более-менее сносный.


Естественно, размещение отверстия на дорожке ведёт к формированию подводов с двух сторон. Чтобы это точно произошло, можете дорожку в этом месте разорвать.


Заключение


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

В качестве желательного функционала здесь сильно недостаёт возможности делать изгибы автоматически соответствующими требованиям DRC. После исправления логики разделения тесно расположенные дорожки больше не выбрасывают идиотских ошибок, хотя все ещё сохраняются проблемы, которые необходимо корректировать, если исходная схема платы выполнена некорректно. Идеальным решением здесь будет обнаруживать ошибки DRC по мере их возникновения, как это делает режим маршрутизации highlight collisions, и выбирать подходящий радиус изгиба.

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

Похоже, что Python API выступает здесь ограничивающим фактором, так как ни одна из систем DRC недоступна. Но я думаю, что алгоритм должен действовать примерно так:

  • создавать структуру из всех подлежащих скруглению пересечений;
  • для каждого из них записывать максимально возможное закругление на основе длины дорожки и расстояний до фиксированных точек, таких как отверстия и пады;
  • для каждого искать все пересечения на внутреннем радиусе при максимальном закруглении и создавать список дорожек, которые необходимо обработать перед текущей;
  • упорядочивать структуру согласно зависимости от дорожек;
  • прорабатывать структуру, закругляя пересечения, не имеющие зависимостей, и удаляя эти пересечения от всех элементов, которые от них зависят. Продолжать по списку, по ходу проверяя ошибки DRC;
  • Повторить процесс n раз.


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


Ну и ещё одна потенциальная доработка: я сказал, что при использовании зон для подводов никогда не возникают ошибки DRC, что не совсем так. Если два подвода наложатся друг на друга, то это вызовет проблему. Доработка, позволяющая смещать подводы от центра, повышает такую вероятность. Исправить это можно с помощью инкрементирования или рандомизирования приоритета их зон, чтобы одна всегда шла первой. Такой приём исключит (или усложнит) опцию remove all teardrops, поскольку приоритет зон используется как ID, но при рендеринге в новый файл с закруглением дорожек это проблемой не станет.


Как использовать плагины


Мои доработки в плагин для формирования подводов уже добавлены в репозиторий kicad_scripts.

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

На следующей неделе ожидайте продолжение темы.

Комментарии (29)


  1. agalakhov
    17.04.2022 14:25
    +6

    KiCAD 6 скруглять не умеет. В один клик в нем ставится плагин скругления, который, однако, страшно глючит.


    В KiCAD 7 обещают нативную поддержку дуг.


    1. Bright_Translate Автор
      17.04.2022 14:26
      +2

      Благодарю за прояснение.


  1. virtusha
    17.04.2022 15:16
    -11

    Квадратные дорожки выглядят на много красивее, чем круглые. Все круглое - уродливое!


    1. lab412
      17.04.2022 16:30
      +11

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


      1. Serge78rus
        17.04.2022 18:35
        -6

        у вас лицо тоже круглое, и глаза круглые — они тоже по вашему уродливые?
        Насчет утверждения о «круглости» формы человеческого лица — это Вы немного перегнули.


        1. eurol
          18.04.2022 11:13
          +2

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


      1. praeivis
        18.04.2022 17:39
        +1

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


        1. nochkin
          18.04.2022 19:25
          +2

          Нормальность заминусованного коммента под вопросом. А плюсы у второго коммента не за обзывание.

          Но каждый видит только то, что хочет. Это да. Таков мир, которой мы сами себе создали.


    1. PKav
      18.04.2022 01:33
      +7

      Не важно как выглядят дорожки, важно как с ними работает плата.


  1. GeneyRoka
    17.04.2022 17:12
    +3

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


    1. pfr46
      17.04.2022 19:27
      +4

      Для меня прямые кажутся более строгими, а округлые как-то вальяжно выглядят.


    1. agalakhov
      17.04.2022 20:22
      +5

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


      1. pfr46
        17.04.2022 21:31
        -2

        Тут сразу вопрос: а разработчики печатных плат для тех же компьютеров не знают об этом? Я об углах на высоких частотах.


        1. atd
          17.04.2022 22:35
          +3

          Возьмите любую свежую 25G+ сетевуху и там будет сделанно именно так


        1. GennPen
          18.04.2022 02:12
          +3

          Конечно знают. Используют и скругленные и угловые где необходимо.

          Hidden text

          С 14-й минуты:


  1. lab412
    17.04.2022 17:42
    +4

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


    1. atd
      17.04.2022 22:34
      +2

      Что-то похожее происходит в TopoR ))


    1. agalakhov
      18.04.2022 15:37

      Вы описываете симуляцию отжига?


  1. Dark_Purple
    17.04.2022 19:18
    +4

    Чтоб электрочики не спотыкались..)


  1. iShrimp
    17.04.2022 19:37
    +12

    Жаль, что не вспомнили российский TopoR, который существует аж с 2001 года (ныне поставляется в составе САПР DeltaDesign).


  1. Jury_78
    17.04.2022 20:18
    +4

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


  1. checkpoint
    18.04.2022 01:31
    +5

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


  1. red_dragon
    18.04.2022 08:00
    -4

    Я с детства не любил овал...


  1. nixtonixto
    18.04.2022 09:19
    +2

    Используют углы под 45° потому, что так у дорожки получается меньше точек и, следовательно, в герберах накапливается мЕньшая погрешность. Ведь герберы — не в плавучке, поэтому даже в формате 3.5 в такой плате могут накапливаться ошибки. Ну и сам гербер-файл будет монструозным. И редактирование трассировки у вас стало невозможным, а ведь каждая плата имеет несколько ревизий, сходу в продакшн никто не делает, кроме самодельщиков.

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


    1. atd
      18.04.2022 10:48

      дуги окружности могут быть в гербере, а вот насчёт безье я не уверен.

      > редактирование трассировки у вас стало невозможным

      в топоре это сделано так: можно двигать любые (незакреплённые) дорожки, всё соседнее сапр будет «расталкивать» а после редактирования натянет обратно и скруглит.


  1. Uzix
    18.04.2022 09:22
    +2

    Использовал данный плагин в своих хобби поделках. После его применения плате требуется доработка "напильником", но итоговый результат мне нравится.

    Hidden text


    1. checkpoint
      18.04.2022 11:41
      +4

      Почему у платы углы не скруглены ? ;)


  1. srg27y
    18.04.2022 09:38
    +1

    пользовался этімі інструментамі в альтіуме

    но как отметілі вышэ, вознікают определенные сложності прі дальнейшем редактірованіі

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


  1. AquariusStar
    19.04.2022 11:49

    У меня один вопрос к округлятору дорожек: а как насчёт выдержки длины дорожек (особенно в дифференциальных), чтобы выдержать нужные времена задержек и фаз?