Комментарии 72
Вообще, изначально я собирался писать статью уже после проработки windows версии. Но там еще непочатый край работы, а лайки хочется собрать уже сейчас…
P.S.: думаю за такую работу лайки не заставят себя ждать :)
Понятно, что без windows версии широкого распространения пока ждать не приходится
Пока Вы не погрузились с головой в Windows-версию, предлагаю подумать вот над чем:
1. У вас в статье есть ответы на вопросы из серии «как?», но нет ответа на вопрос «зачем?»
2. Вы — как программист — делаете проект, который гарантированно «соберёт лайки» от программистов. Но CADами-то пользуются конструктора. Что Вы можете предложить конструктору, чего нет у конкурентов, и нужно ли это ему вообще?
P.S: Лучший на мой взгляд конструкторский САПР (и мировой стандарт де-факто) — это SolidWorks от Dassault Systemes. Dassault — это не только программисты. Это большая фирма, помимо софта ещё разрабатывают и производят… настоящие самолёты. Они знают, какие фичи нужны конструкторам и пилят именно их. Собрать лайки за ещё один, уж простите за прямоту, «недоCAD» — круто. В одиночку — ещё круче. Я так не смогу. Но даст ли это Вам нужное количество денег/признания, относительно трудозатрат?
И да, плюсов Вам поставил :)
Вон вчера краники на смесители напечатал :).
У нас есть открытый код freecad, который построен вокруг того же ядра. FreeCad позволяет экспорт в DAE и OBJ. Насчет GLTF я не понял.
Значит я теоретически могу посмотреть, как эта конверсия выполнена во FreeCad и сделать тоже самое.
Так что да. Возможность есть.
github.com/mirmik/zencad/releases/tag/wintest
Это пока не релиз, но пощупать можно.
Работает standalone (ничего дополнительно ставить не надо). Протестировано (Ну, типо падает не сразу) на десятке.
Качать zip, запускать ZenCad.exe
(Пока x64 только)
Про сопряжения можно добавить.
При прямом, синхронном и компоновочном проектировании про сопряжения не вспоминают. Предполагается что нужно сразу знать, что хочешь получить. Если например в Компасе на чертеже видно, что деталь нужно подвинуть на 0.1, двигаем в исходном документе и все будет по нулям.
Есть исходные размеры и все остальные получаются в результате вычислений.
В T-Flex есть опорные элементы, вокруг которых все строится. Изменили опорный элемент, все перестроилось.
Это еще похоже на библиотеки, задали входные параметры и получили, может даже и целый кран.
drive.google.com/open?id=0B63y14wkcLqgNlVMZ0w4R0o0RVE
Результаты проектирования можно передавать сразу на станок
Их надо только облагородить, выбрать окончательный вариант апи и внести в документацию…
См. пример robot.py
#!/usr/bin/env python3
# coding: utf-8
from zencad import *
import numpy as np
test_mode()
for n in range(1,5,1):
d=12+n
a=np.array([0, 0, 0])
b=np.array([0, 20, d])
c=np.array([0, 12, d])
pnts = points([a, b])
pnts2 = points([a+c, b])
m0 = polysegment(pnts)
m2 = polysegment(pnts2)
display(m0)
display(m2)
show()
Про сопряжения.
Слова «сопряжения можно добавить» применил в смысле рассказать про сопряжения. И если в ZenCad будут добавлены сопряжения, то как частный случай общих сопряжений. Например ось вращения проходит через заданную точку. Это просто легче считать, иначе придется полностью рассчитывать положение оси вращения.
Уравнения в этом случае не считаются и просто выполняется поворот.
В Компасе сопряжения понимают как совместить две плоскости любой ориентации. Здесь приходится все пересчитывать и бывают сопряжения несовместимы. Можно добавить одну деталь, включить сопряжение, все сопряжения начинают пересчитываться и бывает что можно потерять сборку.
В Компасе можно применить только совпадение Локальных Систем Координат (ЛСК).
При этом уравнения не считаются, просто поворачивают до совпадения ЛСК двух деталей. ЛСК в деталях нужно предварительно построить и задать имя ЛСК.
Про имя ЛСК можно остановиться подробней, потому что если правильно задать имя, проектирование можно считать выполненным.
Даже если есть правильное имя ЛСК, вручную буковки в дереве построения искать очень напрягает. А по полученному списку всех ЛСК, программе только за радость сравнить и включить совпадение выбранных ЛСК.
Пример. На сборочный чертеж поместили мотор, имеющий четыре отверстия для крепления. На каждом отверстии стоит ЛСК с именем «Хочу Болт 10 с шайбами».
В базе должны быть перечни всех ЛСК по каждой детали.
Ищем «Кому Болт 10 с шайбами».
По имени находим в базе нужную ЛСК, загружаем в сборку деталь «Болт с шайбами» и включаем совпадение ЛСК. Все, болт на месте. И т.д.
Это в Компасе, а ZenCad нужно еще изучать.
По поводу np.array: В дальнейшем я вообще постараюсь убрать или спрятать поглубже слассы vector и point. Будем как раз с np.array работать. Мне кажется, это в духе питона и удобно для использования стороннего софта.
Простые модели — не всегда интересно. А можно примеры сборок, да ещё и перестраиваемых?))
Ну или хотя бы примеры кода с взаимосвязями (сопряжения) тел в модели.
А в целом — этого мне не хватало лет 5 назад очень сильно.
Всё делается за счет правильно расчитанных цепочек размеров. Этим же обеспечивается параметризуемость и перестраиваемость.
Небольшое дополнение в сторону сопряжений и сборок :) https://github.com/sevikkk/valurap/blob/master/zcad/robot.py
2. И ещё одно соображение — САПР это не только движок, но ещё и набор типовых элементов — крепежа, подшипников, зубчатых передач, резьб. И возможность сгенерировать комплект конструкторской документации — двумерные чертежи. Поэтому FreeCAD — это полноценный САПР. А OpenSCAD, ZenCAD и Blender это средства 3-мерного моделирования, но для инженерной работы они не пригодны, или пригодны условно.
Я прорабатывал вопрос интеграции с FreeCad… Пока вызвать силами FreeCad скрипт zencad без некоторой головной боли не получается, но можно использовать brep файлы для передачи геометрии.
Blender и FreeCad используют python как расширяющую часть своего движка. И хотя тот же FreeCad можно использовать без графического интерфейса, полноценно писать модели на нем скриптами врядли получится.
В целом, думаю, ответ нет. Та ниша, на которую нацелен zencad не пересекает ареал обитания не Blender, ни FreeCad. Задача ZenCad в том, чтобы писать параметризуемые модели без лишней головной боли. Да, ZenCad напрямую конкурирует с OpenScad. Это естественно, так как он является попыткой преодолеть недостатки OpenScad. Очень условно конфликтует с pythonOCC — тут явно разные цели. Крайне условно с solidpython… (В силу убогости концепта последнего, да простят меня его разработчики...).
Вообще, вопрос хаоса всегда решается проработанными интерфейсами. Тогда получается не хаос, а живая экосистема, где каждая библиотека занимается своей частью работы. Тот же pythonOCC имеет интерфейс к FreeCad. Если так получится, что zencad получит сколь-нибудь значительную популярность, можно будет попробовать заполучить во FreeCad интерфейс и для ZenCad. (Мне сейчас в голову пришла мысль, что возможно удасться подсунуть геометрию из ZenCad в интерфейс для pythonOCC. Было бы удобно.)…
Такое представление, конечно, можно сделать, хотя оно будет работать только до тех пор, пока мы не подтягиваем дополнительных библиотек. А фишка ZenCad как раз в интеграции с экосистемой python. Сделать можно… Только зачем? Нодовое представление — это такой костыль, который применяется интерактивным графическим кадом, чтобы добавить параметризуемость, не добавляя скрипты, потому-что скрипты нарушают красивое дерево модели. А zencad — это как бы сразу о скриптах…
В общем, имхо, лишнее это…
Кстати… Если уж на то пошло, evalcache, который занимается контролем ленивых вычислений в zencad умеет визуализировать дерево вычисления в консоли (Для отладочных целей). Так что задача нодового построения фактически решена. Хотя и не нужна на мой взгляд.
Но думаю, это всё же не наш метод. Строго говоря, для zencad графический интерфейс — это что-то прикрученное сверху. Чем меньше обратных связей от gui к скрипту, тем прозрачнее работа системы.
Мне кажется, если человеку нужна нодовая система, он возьмёт Rhino или того же Houdini… И будет прав. Не зачем лезть в чужой огород.
zencad — это для программистов, которым понадобилось 3д.
В мануале даже девиз написан: CAD system for righteous zen programmers
zencad — это для программистов, которым понадобилось 3д.
Это хорошо сказано. Но я соглашусь с автором выше: нодовая структура проще скриптования, и потому доступнее. Мне нравится аналогия с html разметкой: есть декларативная нодная структура, понятная всем. Дальше поверх нее можно строить редакторы, в которых можно работать как визуально так и на уровне разметки. И вот это мне видится крутой фичей. Я сужу по себе, верстая xaml я могу буквально писать пространственные структуры. Это давно напрашивается в CAD.
Я понял свою ошибку. Я сказал слово САПР. И понеслась. А ZenCad, это не САПР… Или, точнее, его можно использовать как САПР, но это не его цель. ZenCad — это библиотека 3д моделирования для экосистемы питона. Когда я писал его API визуализации, я вдохновлялся matplotlib.
ZenCad, это помимо собрать на коленке под 3д печать поломавшийся держатель для душа… Это и без нас…
ZenCad — это о том, как взять результат аналитического решения из sympy и построить по нему поверхность без промежуточных экспорто-импортов… Или же о том, как тяп-ляп нарисовать клешню робота и быстренько провести полунатурное моделирование без интеграции с gazebo…
Не вижу я в этих кейсах нодовой модели…
Вообще, сборки в zencad — это просто визуализация нескольких невзаимодействующих тел на одной сцене.
Связи как таковые тут не нужны, потому что вы все равно не сможете переместить тело мышкой по сцене. Локация жестко определена скриптом. Концепт не тот…
В оперскад сфера с fn=300 (насколько я понимаю, это 300 треугольников по диаметру) обрабатывается довольно долго. Увеличение до 400-500 делает вылет программы. При большом размере сферы 300 треугольников маловато будет для обработки на фрезерном станке. Видны переходы (на 3д принтере этих переходов не видно, разрешение не то).
В описанной выше программе, как с этим? Можно ли увеличить количество треугольников в stl модели?
Надо начать с того, что zencad оперирует с граничным представлением. То есть до момента конвертации в STL меш сети нет, а есть аналитическая сферическая поверхность.
При конвертации в STL (Через графический интерфейс, или же при использовании api) система предлагает выбрать параметр delta, который влияет на разрешение конечной модели (Вообще у opencascade больше параметров. Со временем они будут добавлены). Как конкретно этот параметр влияет, надо смотреть в документации на opencascade, но точно можно сказать, что чем он меньше тем больше точность.
Я протестировал openscad и zencad на обыкновенной сфере. Длина stl файла для zencad при delta==0.001 превышает длину файла stl для openscad при fn=300. Следовательно точность можно сделать выше. С другой стороны, время генерации файлов практически одинаковое.
Преимущество zencad здесь как раз в том, что zencad строит меш сеть только в момент конвертации, в то время как openscad проводит булевы операции прямо над полигональной сетью. Поэтому чем больше разрешение, тем больше требуется вычислительных ресурсов. В zencad операции вычисления модели и построения сети развязаны. Можно даже построить модель в zencad, экспортировать ее во freecad, после чего сгенирировать там мешсеть так, как это необходимо.
В целом направление хорошее, надо работать. Хорошо что взяли готовое геометрическое ядро… Для сборок, кстати, есть solvespace.
П.С. C#… VS… Что-то это как-то слишком сложненько.
Насколько разобрался задание на построение цифрами в переменных. Сейчас больше компоновочная геометрия с точными линиями. Если не самому рисовать, то можно загрузить из текстовой таблицы линии прорисовки или компоновочной геометрии.
Говорили про отсутствие чертежей. Если на станок выдать координаты в текстовом виде, зачем чертежи.
Для иллюстрации вышесказанного. Допустим хотим вырезать гипоидную инструментом. Оси инструмента и заготовки не пересекаются. На одной оси сечение инструмента вращается, на другой оси заготовка вращается. Сечений много и нужен полученный профиль на заготовке.
Получили поверхность. Ее сразу обрабатываем инструментом и выдаем координаты на станок в текстовом виде.
Как почитаешь, что гипидную на пятикоординатном целый день вырезают и еще кучу фрез выбрасывают, сразу искоровую обработку зауважаешь. Из любого металла, это не 3D принтер. Так можно и дома шестеренку на задний мост за неделю выточить.
Отображение размеров в виде размерных стрелочек сейчас тоже нет. В принципе, сами примитивы для их создания можно добавить (надписи есть, линии есть), но это в любом случае будет не автоматическая простановка. Каждую стрелочку придется ручками прописывать в код. Фишка сомнительной полезности.
Не могу не поделиться этой видюшкой :):
Это, конечно, вообще не основное назначение zencad, но такое тоже можно.
P.S. Версия zencad 1.0 постепенно выходит на финишную прямую. Месяца через два-три, полагаю, можно будет торжественно объявить релиз.
Для тех, кто испытывает трудности с инсталляцией: ставьте с предыдущей версией PyQT5 (5.14.0). В последней есть баг bugs.launchpad.net/rapid/+bug/1859124
python3 -m pip install zencad pyqt5==5.14.0
Проведу аналогию с Excel, в котором удобно записывать ход решения задачи сразу же забесплатно получая визуализацию значений и пересчет при изменении начальных данных.
Так что zencad попал в точку. И проектные решения правильно приняты:
- Python лучше своего языка. С новым API разобраться проще, чем с новым языком, потому что для общих вещей типа управляющих конструкций используется известный язык общего назначения.
- Возможность использовать свой привычный редактор не теряя возможности оперативно получить визуализацию — это же просто REPL какой-то! :)
Уточню — мне профессионально CAD совсем не нужны, я не готов вкладывать много усилий в их изучение. Я программист, у которого временами появляется потребность в трехмерном моделировании. Righteous zen programmer. :)
Спасибо. Очень бы хотелось, чтобы проект жил и развивался дальше.
Кстати, этой статье скоро два года, пора бы напомнить о себе и рассказать, что добавилось за это время :)
Для меня библиотека интересна скорее как возможность вывести в виде твердотельных моделей результаты какой-то алгоритмики… Не знаю — фракталы какие-нибудь, или сложные поверхности. ;) В виду наличия 3D-принтера именно это представляется наиболее интересным, кмк.
Про сложные поверхности я тоже думаю, но это в перспективе :)
В библиотеке, кстати, с некоторых пор появилась построение поверхности по массиву точек (процедура interpolate2), но ей таки обвязки нехватает. Не очень понятно, как эту поверхность в объёмное тело засунуть, для этого некоторая сноровка и понимание работы ядра требуется. В этом направлении тоже надо наращивать.
В защиту скриптового подхода в параметрическом моделировании могу заметить, что средства параметрического моделирования в современных мейнстримных CAD имеют часто ограничения по сравнению с нормальным языком программирования. То есть, размеры задать, массивы построить вы можете, но фильтры какие-нибудь посчитать, условные инструкции добавить, это уже сложно. Ну и конечно да, стирается грань для склеивания с результатами мат расчетов.
Меня лишь немного смутило вот это: «повторяя одни и те же действия многократно, а потом исходные данные немного поменялись и начинай сначала». ;) Все-таки в современных CAD-системах процесс немного не так примитивен.
А так скриптовые системы сосуществуют параллельно с CAD-ами, занимают свою вполне определенную нишу. На thingiverse довольно много готовых параметрических моделей в формате openscad, что довольно-таки удобно.
Систем для скриптового моделирования много, но у них один общий… Ну нельзя сказать «недостаток», скорее подход: в них встроен некий язык, для написания скриптов. В вашем же случае парадигма иная: у вас cad-библиотека для языка! Это как бы предполагает (на мой взгляд), что мы идем от языка: что у нас какая-то крутая математика/физика/статистика… Да хоть — машинное обучение! ;) К которому идет возможность твердотельного моделирования. И это круто. Я поэтому спрашивал про вывод в jupiter-notebook, помните? ;)
Хотя, наверное, просто как sCAD для Python-разработчиков ZenCad тоже можно рассматривать — почему нет?
Я в результате туда и ушел :) Основная проблема скриптовых языков — выбрать поверхность/вершину так, что бы при изменении параметров и перестройке всех шагов она осталась той же.
И с учетом того, что topo-naming'а в каскаде из коробки нет, а в FreeCAD'е его за 2 года так и не собрались смержить, то про какие-то кардинальные изменения параметров можно забыть.
Соответственно в качестве автоматизации подготовки либо для финальных сборок — да скрипты работают, но для низкоуровневого рисования — все-таки мышка намного удобнее :)
На начальном этапе я дошел до такого: github.com/sevikkk/valurap/blob/master/freecad/unbuild_part.py — конвертор из FreeCADа в питон, но проблема поиска вершин/граней всю идею очень быстро похоронила.
Делает верхнеуровневую сборку всех покупных частей, для того, что бы можно было дизайнить пластик опираясь на реальные грани/отверстия/зазоры и т.д.
Начал дальше гуглить — похоже даже в blender при желании можно зарядить какой-нибудь open-CV, или sklearn! Как собственно и упомянутый FreeCAD!
FreeCAD --console
И можно макрос настроить, что-бы запускать в визуальном режиме. Ну и там есть просто окно консоли питоновой, в котором в интерактивном режиме можно потыкать API в контексте живой модели.
>> ls /Applications/FreeCAD.app/Contents/Resources/bin/
FreeCAD FreeCADCmd ccx pip pyside2-rcc python
python
— тут обычный питон, который ничего не импортирует раньше времени, но в котором можно все что нужно заимпортить и написать, вплоть до запуска UI :)Новую статью по библиотеке планировалось написать еще год назад, но жизнь, как говорится, закрутила. Будем навёрстывать. Как минимум, за два года мы стали сильно стабильнее, освоили анимацию, и некоторое дополнительное количество новых операций.
не замена вот этой библиотеке github.com/mirmik/servoce
случайно? Это я случайно нашел и на всякий случай информирую :)
Думаю эту мысль уже второй день и чем больше думаю, тем больше мне она нравится.
Когда я только начинал писать zencad, я смотрел на pythonocc и как-то он у меня не вязался с идеей программы, хотелось чтобы zencad был обёрткой над некоторой плюсовой библиотекой и чтобы вся логика оставалась на стороне плюсов, а тут получалась какая-то обёртка над обёрткой и в общем, не нравилось оно мне. Практика показала, что я выбрал не самое удобное решение — очень много кода, который решает чисто логистические задача и довольно высоки накладные расходы на внесение изменений.
Переходом на pythonOCC-core можно решить ряд проблем, а заодно наконец-то добавить возможность расширения, то есть позволить в рамках zencad использовать api opencascade на случай, если zencad окажется недостаточно функционален.
Собрал сейчас pythonocc-core для новенького opencascade-7.5.0, он сейчас с occ работает. Не знаю, перешел ли автор на occ или поддерживает все версии occ и oce. Выглядит юзабельно, можно перепереть api zencad на OCC.Core и мне эта мысль вот прям очень нравится. Есть пара вопросов по части дистрибьюции, pythonocc-core нет на pypi, а хотелось бы распространяться именно через него. максимальный вес пакета в pypi порядка 100Мб. pythonocc-core в собранном виде весит порядка 300Мб. Таким образом придётся, видимо, дополнительно выкачивать его после установки.
В общем, я поэксперементирую в этом направлении, потому как проект уже начинает ржаветь, а такая модернизация может вдохнуть в него новую жизнь.
Система скриптового 3д моделирования ZenCad