Comments 72
Очень интересная библиотека. Жаль, что под windows не работает. Очень бы хотелось попробовать, хотя бы для моделирования простых объектов, пусть даже без анимации.
Думаю, разработка windows версии на текущий момент в приоритете. Проект достаточно неплох, чтобы предложить его широкому кругу пользователей. Понятно, что без windows версии широкого распространения пока ждать не приходится. Так что над windows версией буду работать.
Вообще, изначально я собирался писать статью уже после проработки windows версии. Но там еще непочатый край работы, а лайки хочется собрать уже сейчас…
Вообще, изначально я собирался писать статью уже после проработки windows версии. Но там еще непочатый край работы, а лайки хочется собрать уже сейчас…
Большое спасибо за ваш труд, действительно интересно.
P.S.: думаю за такую работу лайки не заставят себя ждать :)
P.S.: думаю за такую работу лайки не заставят себя ждать :)
Понятно, что без windows версии широкого распространения пока ждать не приходится
Пока Вы не погрузились с головой в Windows-версию, предлагаю подумать вот над чем:
1. У вас в статье есть ответы на вопросы из серии «как?», но нет ответа на вопрос «зачем?»
2. Вы — как программист — делаете проект, который гарантированно «соберёт лайки» от программистов. Но CADами-то пользуются конструктора. Что Вы можете предложить конструктору, чего нет у конкурентов, и нужно ли это ему вообще?
P.S: Лучший на мой взгляд конструкторский САПР (и мировой стандарт де-факто) — это SolidWorks от Dassault Systemes. Dassault — это не только программисты. Это большая фирма, помимо софта ещё разрабатывают и производят… настоящие самолёты. Они знают, какие фичи нужны конструкторам и пилят именно их. Собрать лайки за ещё один, уж простите за прямоту, «недоCAD» — круто. В одиночку — ещё круче. Я так не смогу. Но даст ли это Вам нужное количество денег/признания, относительно трудозатрат?
И да, плюсов Вам поставил :)
Ну, это в первую очередь инструмент, которым пользуюсь я сам.
Вон вчера краники на смесители напечатал :).
Вон вчера краники на смесители напечатал :).
Есть ли возможность сделать экспорт в форматы, поддерживаемые движком Godot?
Какие?
DAE, OBJ и GLTF 2.0
Счастлив сообщить, что тестовая виндовая сборка доступна.
github.com/mirmik/zencad/releases/tag/wintest
Это пока не релиз, но пощупать можно.
Работает standalone (ничего дополнительно ставить не надо). Протестировано (Ну, типо падает не сразу) на десятке.
Качать zip, запускать ZenCad.exe
(Пока x64 только)
github.com/mirmik/zencad/releases/tag/wintest
Это пока не релиз, но пощупать можно.
Работает standalone (ничего дополнительно ставить не надо). Протестировано (Ну, типо падает не сразу) на десятке.
Качать zip, запускать ZenCad.exe
(Пока x64 только)
На семерке 64 идут тестовые примеры. Дальше будем разбираться, например сплайн из 1000 и более точек.
Про сопряжения можно добавить.
При прямом, синхронном и компоновочном проектировании про сопряжения не вспоминают. Предполагается что нужно сразу знать, что хочешь получить. Если например в Компасе на чертеже видно, что деталь нужно подвинуть на 0.1, двигаем в исходном документе и все будет по нулям.
Есть исходные размеры и все остальные получаются в результате вычислений.
В T-Flex есть опорные элементы, вокруг которых все строится. Изменили опорный элемент, все перестроилось.
Это еще похоже на библиотеки, задали входные параметры и получили, может даже и целый кран.
drive.google.com/open?id=0B63y14wkcLqgNlVMZ0w4R0o0RVE
Результаты проектирования можно передавать сразу на станок
Про сопряжения можно добавить.
При прямом, синхронном и компоновочном проектировании про сопряжения не вспоминают. Предполагается что нужно сразу знать, что хочешь получить. Если например в Компасе на чертеже видно, что деталь нужно подвинуть на 0.1, двигаем в исходном документе и все будет по нулям.
Есть исходные размеры и все остальные получаются в результате вычислений.
В T-Flex есть опорные элементы, вокруг которых все строится. Изменили опорный элемент, все перестроилось.
Это еще похоже на библиотеки, задали входные параметры и получили, может даже и целый кран.
drive.google.com/open?id=0B63y14wkcLqgNlVMZ0w4R0o0RVE
Результаты проектирования можно передавать сразу на станок
Сопряжения уже практически добавлены.
Их надо только облагородить, выбрать окончательный вариант апи и внести в документацию…
См. пример robot.py
Их надо только облагородить, выбрать окончательный вариант апи и внести в документацию…
См. пример robot.py
Про сопряжения немного после, вначале код с векторами, которые можно складывать как вектора. В примерах везде числа, а в коде robot.py параметр управления идет с анимации.
Про сопряжения.
Слова «сопряжения можно добавить» применил в смысле рассказать про сопряжения. И если в ZenCad будут добавлены сопряжения, то как частный случай общих сопряжений. Например ось вращения проходит через заданную точку. Это просто легче считать, иначе придется полностью рассчитывать положение оси вращения.
Уравнения в этом случае не считаются и просто выполняется поворот.
В Компасе сопряжения понимают как совместить две плоскости любой ориентации. Здесь приходится все пересчитывать и бывают сопряжения несовместимы. Можно добавить одну деталь, включить сопряжение, все сопряжения начинают пересчитываться и бывает что можно потерять сборку.
В Компасе можно применить только совпадение Локальных Систем Координат (ЛСК).
При этом уравнения не считаются, просто поворачивают до совпадения ЛСК двух деталей. ЛСК в деталях нужно предварительно построить и задать имя ЛСК.
Про имя ЛСК можно остановиться подробней, потому что если правильно задать имя, проектирование можно считать выполненным.
Даже если есть правильное имя ЛСК, вручную буковки в дереве построения искать очень напрягает. А по полученному списку всех ЛСК, программе только за радость сравнить и включить совпадение выбранных ЛСК.
Пример. На сборочный чертеж поместили мотор, имеющий четыре отверстия для крепления. На каждом отверстии стоит ЛСК с именем «Хочу Болт 10 с шайбами».
В базе должны быть перечни всех ЛСК по каждой детали.
Ищем «Кому Болт 10 с шайбами».
По имени находим в базе нужную ЛСК, загружаем в сборку деталь «Болт с шайбами» и включаем совпадение ЛСК. Все, болт на месте. И т.д.
Это в Компасе, а ZenCad нужно еще изучать.
#!/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 нужно еще изучать.
Я думаю, в конечном итоге zencad тоже будет сопрягать два изделия, совмещая определенные ЛСК (собственно, он уже почти так делает). Но конечно, вместо названий будет прямое указание, что и куда ставить. Названия — это не для скриптов.
По поводу np.array: В дальнейшем я вообще постараюсь убрать или спрятать поглубже слассы vector и point. Будем как раз с np.array работать. Мне кажется, это в духе питона и удобно для использования стороннего софта.
По поводу np.array: В дальнейшем я вообще постараюсь убрать или спрятать поглубже слассы vector и point. Будем как раз с np.array работать. Мне кажется, это в духе питона и удобно для использования стороннего софта.
Простые модели — не всегда интересно. А можно примеры сборок, да ещё и перестраиваемых?))
Ну или хотя бы примеры кода с взаимосвязями (сопряжения) тел в модели.
А в целом — этого мне не хватало лет 5 назад очень сильно.
Вообще, сопряжения как таковые тут не прописываются.
Всё делается за счет правильно расчитанных цепочек размеров. Этим же обеспечивается параметризуемость и перестраиваемость.
Всё делается за счет правильно расчитанных цепочек размеров. Этим же обеспечивается параметризуемость и перестраиваемость.
Небольшое дополнение в сторону сопряжений и сборок :) https://github.com/sevikkk/valurap/blob/master/zcad/robot.py
Интересный проект. Есть ли возможность записать и выложить небольшое ознакомительное видео?
1. Как пользователь OpenScad, Python, а также FreeCAD и Blender с радостью узнал о новой библиотеке. С другой стороны возникло опасение, а не возникнет ли хаоса в этой экосистеме. FreeCAD использует и OpenScad и Python, но свои библиотеки. Blender тоже использует Python, но свои библиотеки. Все что-то развивают независимо друг от друга, в итоге растёт зоопарк и не понятно на что ориентироваться.
2. И ещё одно соображение — САПР это не только движок, но ещё и набор типовых элементов — крепежа, подшипников, зубчатых передач, резьб. И возможность сгенерировать комплект конструкторской документации — двумерные чертежи. Поэтому FreeCAD — это полноценный САПР. А OpenSCAD, ZenCAD и Blender это средства 3-мерного моделирования, но для инженерной работы они не пригодны, или пригодны условно.
2. И ещё одно соображение — САПР это не только движок, но ещё и набор типовых элементов — крепежа, подшипников, зубчатых передач, резьб. И возможность сгенерировать комплект конструкторской документации — двумерные чертежи. Поэтому FreeCAD — это полноценный САПР. А OpenSCAD, ZenCAD и Blender это средства 3-мерного моделирования, но для инженерной работы они не пригодны, или пригодны условно.
Правильный или неправильный, полноценный или неполноценный САПР, это уж как кому нравится. ZenCad в комплект конструкторской документации уметь не собирается. Это не его задача. Зубчатые передачи и резьбы планируются, но не как готовые элементы, а скорее как набор библиотечных функций.
Я прорабатывал вопрос интеграции с FreeCad… Пока вызвать силами FreeCad скрипт zencad без некоторой головной боли не получается, но можно использовать brep файлы для передачи геометрии.
Blender и FreeCad используют python как расширяющую часть своего движка. И хотя тот же FreeCad можно использовать без графического интерфейса, полноценно писать модели на нем скриптами врядли получится.
В целом, думаю, ответ нет. Та ниша, на которую нацелен zencad не пересекает ареал обитания не Blender, ни FreeCad. Задача ZenCad в том, чтобы писать параметризуемые модели без лишней головной боли. Да, ZenCad напрямую конкурирует с OpenScad. Это естественно, так как он является попыткой преодолеть недостатки OpenScad. Очень условно конфликтует с pythonOCC — тут явно разные цели. Крайне условно с solidpython… (В силу убогости концепта последнего, да простят меня его разработчики...).
Вообще, вопрос хаоса всегда решается проработанными интерфейсами. Тогда получается не хаос, а живая экосистема, где каждая библиотека занимается своей частью работы. Тот же pythonOCC имеет интерфейс к FreeCad. Если так получится, что zencad получит сколь-нибудь значительную популярность, можно будет попробовать заполучить во FreeCad интерфейс и для ZenCad. (Мне сейчас в голову пришла мысль, что возможно удасться подсунуть геометрию из ZenCad в интерфейс для pythonOCC. Было бы удобно.)…
Я прорабатывал вопрос интеграции с FreeCad… Пока вызвать силами FreeCad скрипт zencad без некоторой головной боли не получается, но можно использовать brep файлы для передачи геометрии.
Blender и FreeCad используют python как расширяющую часть своего движка. И хотя тот же FreeCad можно использовать без графического интерфейса, полноценно писать модели на нем скриптами врядли получится.
В целом, думаю, ответ нет. Та ниша, на которую нацелен zencad не пересекает ареал обитания не Blender, ни FreeCad. Задача ZenCad в том, чтобы писать параметризуемые модели без лишней головной боли. Да, ZenCad напрямую конкурирует с OpenScad. Это естественно, так как он является попыткой преодолеть недостатки OpenScad. Очень условно конфликтует с pythonOCC — тут явно разные цели. Крайне условно с solidpython… (В силу убогости концепта последнего, да простят меня его разработчики...).
Вообще, вопрос хаоса всегда решается проработанными интерфейсами. Тогда получается не хаос, а живая экосистема, где каждая библиотека занимается своей частью работы. Тот же pythonOCC имеет интерфейс к FreeCad. Если так получится, что zencad получит сколь-нибудь значительную популярность, можно будет попробовать заполучить во FreeCad интерфейс и для ZenCad. (Мне сейчас в голову пришла мысль, что возможно удасться подсунуть геометрию из ZenCad в интерфейс для pythonOCC. Было бы удобно.)…
Вы со мной не согласитесь, но идея чисто скриптового САПРа изначально ориентирована на узкую нишу. Идеальный САПР — это двусторонний — где легко из визуального проектирования получить скрипт, а из скрипта столь же легко получить визуальную модель. Моё мнение — лучше потратить силы на доработку FreeCAD до этого идеала, а не рыть ещё один параллельный туннель. Но силы ваши — вам виднее :-)
Думаю, как дополнение хорошо смотрелась бы популярная в 3д прогах «нодовая» система моделирования. Каждый узел соответствуют одной функции скрипта с соответствующими параметрами.
Мне это представление всегда казалось новомодным ненужным наворотом. Это как функциональные диаграммы и Verilog. Verilog явно более могучий.
Такое представление, конечно, можно сделать, хотя оно будет работать только до тех пор, пока мы не подтягиваем дополнительных библиотек. А фишка ZenCad как раз в интеграции с экосистемой python. Сделать можно… Только зачем? Нодовое представление — это такой костыль, который применяется интерактивным графическим кадом, чтобы добавить параметризуемость, не добавляя скрипты, потому-что скрипты нарушают красивое дерево модели. А zencad — это как бы сразу о скриптах…
В общем, имхо, лишнее это…
Кстати… Если уж на то пошло, evalcache, который занимается контролем ленивых вычислений в zencad умеет визуализировать дерево вычисления в консоли (Для отладочных целей). Так что задача нодового построения фактически решена. Хотя и не нужна на мой взгляд.
Такое представление, конечно, можно сделать, хотя оно будет работать только до тех пор, пока мы не подтягиваем дополнительных библиотек. А фишка ZenCad как раз в интеграции с экосистемой python. Сделать можно… Только зачем? Нодовое представление — это такой костыль, который применяется интерактивным графическим кадом, чтобы добавить параметризуемость, не добавляя скрипты, потому-что скрипты нарушают красивое дерево модели. А zencad — это как бы сразу о скриптах…
В общем, имхо, лишнее это…
Кстати… Если уж на то пошло, evalcache, который занимается контролем ленивых вычислений в zencad умеет визуализировать дерево вычисления в консоли (Для отладочных целей). Так что задача нодового построения фактически решена. Хотя и не нужна на мой взгляд.
Я конечно даже поверхностно не владею текущим «раскладом» в области «CAD» систем, не знаком с целевой аудиторией на которую рассчитана описанная в статье система, но довольно давно наблюдаю за эволюцией некоторых популярных 3д редакторов. Могу отметить, что нодовые системы так или иначе проникают практически во все. Причина, имхо, в том, что скрипты и плагины способны писать настолько незначительное количество обычных пользователей, что ими можно пренебречь, а вот освоить пусть не столь универсальную, но все же довольно гибкую нодовую систему могут уже некоторые «продвинутые» пользователи. Т.е. если целевая аудитория состоит не из одних программистов, то нодовая система позволит существенно больше популяризовать продукт, снизив порог вхождения, но хозяин — барин. ) Тот же гудини имеет продвинутую систему и скриптов и нод, а их умелое сочетание позволяет получить результат быстрее, чем только скриптами.
Идея понятна.
Но думаю, это всё же не наш метод. Строго говоря, для zencad графический интерфейс — это что-то прикрученное сверху. Чем меньше обратных связей от gui к скрипту, тем прозрачнее работа системы.
Мне кажется, если человеку нужна нодовая система, он возьмёт Rhino или того же Houdini… И будет прав. Не зачем лезть в чужой огород.
zencad — это для программистов, которым понадобилось 3д.
В мануале даже девиз написан: CAD system for righteous zen programmers
Но думаю, это всё же не наш метод. Строго говоря, для zencad графический интерфейс — это что-то прикрученное сверху. Чем меньше обратных связей от gui к скрипту, тем прозрачнее работа системы.
Мне кажется, если человеку нужна нодовая система, он возьмёт Rhino или того же Houdini… И будет прав. Не зачем лезть в чужой огород.
zencad — это для программистов, которым понадобилось 3д.
В мануале даже девиз написан: CAD system for righteous zen programmers
zencad — это для программистов, которым понадобилось 3д.
Это хорошо сказано. Но я соглашусь с автором выше: нодовая структура проще скриптования, и потому доступнее. Мне нравится аналогия с html разметкой: есть декларативная нодная структура, понятная всем. Дальше поверх нее можно строить редакторы, в которых можно работать как визуально так и на уровне разметки. И вот это мне видится крутой фичей. Я сужу по себе, верстая xaml я могу буквально писать пространственные структуры. Это давно напрашивается в CAD.
Многие коментаторы этого поста говорят о том, как 3д модель удобно построить. ZenCad это немного о другом.
Я понял свою ошибку. Я сказал слово САПР. И понеслась. А ZenCad, это не САПР… Или, точнее, его можно использовать как САПР, но это не его цель. ZenCad — это библиотека 3д моделирования для экосистемы питона. Когда я писал его API визуализации, я вдохновлялся matplotlib.
ZenCad, это помимо собрать на коленке под 3д печать поломавшийся держатель для душа… Это и без нас…
ZenCad — это о том, как взять результат аналитического решения из sympy и построить по нему поверхность без промежуточных экспорто-импортов… Или же о том, как тяп-ляп нарисовать клешню робота и быстренько провести полунатурное моделирование без интеграции с gazebo…
Не вижу я в этих кейсах нодовой модели…
Я понял свою ошибку. Я сказал слово САПР. И понеслась. А ZenCad, это не САПР… Или, точнее, его можно использовать как САПР, но это не его цель. ZenCad — это библиотека 3д моделирования для экосистемы питона. Когда я писал его API визуализации, я вдохновлялся matplotlib.
ZenCad, это помимо собрать на коленке под 3д печать поломавшийся держатель для душа… Это и без нас…
ZenCad — это о том, как взять результат аналитического решения из sympy и построить по нему поверхность без промежуточных экспорто-импортов… Или же о том, как тяп-ляп нарисовать клешню робота и быстренько провести полунатурное моделирование без интеграции с gazebo…
Не вижу я в этих кейсах нодовой модели…
Скажите, есть поддержка сборок, состоящих из нескольких деталей и ограничений/связей между ними, как это сделано в том же Inventor или SolidWorks? Этого сильно не хватало во FreeCAD (так-то есть, но кривое и сырое).
Ограничений связей как таковых нет. Для того, чтобы сделать сборку надо взять несколько тел и транслировать их в нужные места. Анализа перекрытия тел так же не производится.
Вообще, сборки в zencad — это просто визуализация нескольких невзаимодействующих тел на одной сцене.
Связи как таковые тут не нужны, потому что вы все равно не сможете переместить тело мышкой по сцене. Локация жестко определена скриптом. Концепт не тот…
Вообще, сборки в zencad — это просто визуализация нескольких невзаимодействующих тел на одной сцене.
Связи как таковые тут не нужны, потому что вы все равно не сможете переместить тело мышкой по сцене. Локация жестко определена скриптом. Концепт не тот…
UFO just landed and posted this here
Можно ли уточнить…
В оперскад сфера с fn=300 (насколько я понимаю, это 300 треугольников по диаметру) обрабатывается довольно долго. Увеличение до 400-500 делает вылет программы. При большом размере сферы 300 треугольников маловато будет для обработки на фрезерном станке. Видны переходы (на 3д принтере этих переходов не видно, разрешение не то).
В описанной выше программе, как с этим? Можно ли увеличить количество треугольников в stl модели?
В оперскад сфера с 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, после чего сгенирировать там мешсеть так, как это необходимо.
Надо начать с того, что zencad оперирует с граничным представлением. То есть до момента конвертации в STL меш сети нет, а есть аналитическая сферическая поверхность.
При конвертации в STL (Через графический интерфейс, или же при использовании api) система предлагает выбрать параметр delta, который влияет на разрешение конечной модели (Вообще у opencascade больше параметров. Со временем они будут добавлены). Как конкретно этот параметр влияет, надо смотреть в документации на opencascade, но точно можно сказать, что чем он меньше тем больше точность.
Я протестировал openscad и zencad на обыкновенной сфере. Длина stl файла для zencad при delta==0.001 превышает длину файла stl для openscad при fn=300. Следовательно точность можно сделать выше. С другой стороны, время генерации файлов практически одинаковое.
Преимущество zencad здесь как раз в том, что zencad строит меш сеть только в момент конвертации, в то время как openscad проводит булевы операции прямо над полигональной сетью. Поэтому чем больше разрешение, тем больше требуется вычислительных ресурсов. В zencad операции вычисления модели и построения сети развязаны. Можно даже построить модель в zencad, экспортировать ее во freecad, после чего сгенирировать там мешсеть так, как это необходимо.
Отличная работа. Увидел аналог своих начинаний в прошлом. За язык я взял тогда c#, и считаю это лучше питона: строгая типизация, MS VS — отличная IDE со всеми мыслимыми плюшками. За геометрический движок я взял SolidWorks API. Кто-то скажет «там же итак есть api на сишарп». Есть, но волосы от него дыбом. Целью было сделать не просто тул для генерации геометрий из сишарпа, а хороший internal DSL в функциональном стиле. Поигравшись немного я понял что это тупик… В лучшем случае можно сделать хороший c# api поверх убогого api. Проблема в том, что теряется связь с визуальной частью, там где напрямую можно выбрать какой то элемент геометрии. В вашем случае те же проблемы. Питон обертку вы сделали. Она может даже сама по себе имеет ценность, для любителей питона. Дальше, линейные скрипты, до if ветвлений — по сути и есть декларативная разметка. Если есть двустороння связь с визуальной частью — отлично. Если нет — снова имеем только просто некий api на питоне.
В целом направление хорошее, надо работать. Хорошо что взяли готовое геометрическое ядро… Для сборок, кстати, есть solvespace.
В целом направление хорошее, надо работать. Хорошо что взяли готовое геометрическое ядро… Для сборок, кстати, есть solvespace.
От части метод ближайшей точки, рефлексия, и макросы решают задачу выбора элемента геометрии. Вообще, я уделяю много внимания этой проблеме. Это действительно принципиальное слабое место любого скриптового када.
П.С. C#… VS… Что-то это как-то слишком сложненько.
П.С. C#… VS… Что-то это как-то слишком сложненько.
мне всегда казалось что строгая типизация проще, потому что не дает совершать ошибок банальных. плюс лучшая работа интелисенса. вместо VS есть VS Code сейчас… в общем конечно вопрос вкуса
Но это значит, что сначала вы компилируете exe, который затем строит модель… Зачем так сложно?
ну и что. OpenScad пошел по пути своего языка, своего редактора,… вы правильно пишите в статье — зачем это делать когда есть питон (сишарп в моем случае). Только я еще больше отсекаю лишнюю работу: зачем редакторы, IDE. Одному человеку написать этот функционал? сума сошли?.. Билдить сишарп на клиенте не проблема. Проблема создать максимально комфортное окружение.
Мне кажется, sublime text прекрасен в качестве редактора, что для openscad, что для zencad. vscode тоже неплох. Но VS — это как-то черезчур…
Ну как вам сказать… Вы же тоже для людей имеющих отношение к коду делали эту вещь. Я, например, весьма избалован прелестями IDE. Вряд ли какой то sublime text сранивнится с IDE, я уже не говорю про плюшки от Jetbrains. Я бы хотел тул где буквально пишут модель. Отсюда следует что почти все фичи при написании кода применимы и к процессу написания модели. Рефакторинги те же — если имеете дело с кодом то неизбежны и рефаторинги. Мне не очень было интересно создать какую то независимую вещь. Интереснее обкатать воркфлоу, на максимальной комфортности. Вам же важнее сделать законченное что то. Это тоже правильно.
Как и в Openscad, в ZenCad встроенный редактор имеет роль «на подхвате». Предполагается, что что пользователь пользуется внешним редактором.
Насколько разобрался задание на построение цифрами в переменных. Сейчас больше компоновочная геометрия с точными линиями. Если не самому рисовать, то можно загрузить из текстовой таблицы линии прорисовки или компоновочной геометрии.
Говорили про отсутствие чертежей. Если на станок выдать координаты в текстовом виде, зачем чертежи.
Для иллюстрации вышесказанного. Допустим хотим вырезать гипоидную инструментом. Оси инструмента и заготовки не пересекаются. На одной оси сечение инструмента вращается, на другой оси заготовка вращается. Сечений много и нужен полученный профиль на заготовке.
Получили поверхность. Ее сразу обрабатываем инструментом и выдаем координаты на станок в текстовом виде.
Как почитаешь, что гипидную на пятикоординатном целый день вырезают и еще кучу фрез выбрасывают, сразу искоровую обработку зауважаешь. Из любого металла, это не 3D принтер. Так можно и дома шестеренку на задний мост за неделю выточить.
Можно ли с созданной моделью сделать что-то полезное помимо преобразования в STL для отправки на 3D-принтер? Есть ли шанс, что в будущем можно будет создавать чертежи по модели? Можно ли как-то отображать размеры на трехмерной модели?
На текущий момент кроме конвертации в stl есть конвертация в brep с возможностью экспорта во freecad (он в чертежи, кажется, умеет). Возможно будет построение сечений (мне их нехватает), но полноценных чертежей тут ждать не стоит (если они и будут, то в виде какой-то надстройки сверху и очень нескоро. Я ими заниматься совершенно нехочу, потому как мне они совершенно не нужны).
Отображение размеров в виде размерных стрелочек сейчас тоже нет. В принципе, сами примитивы для их создания можно добавить (надписи есть, линии есть), но это в любом случае будет не автоматическая простановка. Каждую стрелочку придется ручками прописывать в код. Фишка сомнительной полезности.
Отображение размеров в виде размерных стрелочек сейчас тоже нет. В принципе, сами примитивы для их создания можно добавить (надписи есть, линии есть), но это в любом случае будет не автоматическая простановка. Каждую стрелочку придется ручками прописывать в код. Фишка сомнительной полезности.
Для тех, кто следит за темой.
Не могу не поделиться этой видюшкой :):
Это, конечно, вообще не основное назначение zencad, но такое тоже можно.
P.S. Версия zencad 1.0 постепенно выходит на финишную прямую. Месяца через два-три, полагаю, можно будет торжественно объявить релиз.
Не могу не поделиться этой видюшкой :):
Это, конечно, вообще не основное назначение zencad, но такое тоже можно.
P.S. Версия zencad 1.0 постепенно выходит на финишную прямую. Месяца через два-три, полагаю, можно будет торжественно объявить релиз.
отличный проект! я, будучи приверженцем OpenSCAD и алгоритмического CAD проектирования, очень воодушевился прямо :)
Для тех, кто испытывает трудности с инсталляцией: ставьте с предыдущей версией PyQT5 (5.14.0). В последней есть баг bugs.launchpad.net/rapid/+bug/1859124
Для тех, кто испытывает трудности с инсталляцией: ставьте с предыдущей версией PyQT5 (5.14.0). В последней есть баг bugs.launchpad.net/rapid/+bug/1859124
python3 -m pip install zencad pyqt5==5.14.0
Вот я прям целевая аудитория! Как говорится shut up and take my money :) Раньше мебель рисовал, теперь еще и 3d принтер добавился. И везде одна и та же проблема — надо мышкой елозить, повторяя одни и те же действия многократно, а потом исходные данные немного поменялись и начинай сначала. И да, мне проще числом указать, куда что сдвинуть или как повернуть, чем мышкой это сделать, даже с учетом прилипания.
Проведу аналогию с Excel, в котором удобно записывать ход решения задачи сразу же забесплатно получая визуализацию значений и пересчет при изменении начальных данных.
Так что zencad попал в точку. И проектные решения правильно приняты:
Уточню — мне профессионально CAD совсем не нужны, я не готов вкладывать много усилий в их изучение. Я программист, у которого временами появляется потребность в трехмерном моделировании. Righteous zen programmer. :)
Спасибо. Очень бы хотелось, чтобы проект жил и развивался дальше.
Кстати, этой статье скоро два года, пора бы напомнить о себе и рассказать, что добавилось за это время :)
Проведу аналогию с Excel, в котором удобно записывать ход решения задачи сразу же забесплатно получая визуализацию значений и пересчет при изменении начальных данных.
Так что zencad попал в точку. И проектные решения правильно приняты:
- Python лучше своего языка. С новым API разобраться проще, чем с новым языком, потому что для общих вещей типа управляющих конструкций используется известный язык общего назначения.
- Возможность использовать свой привычный редактор не теряя возможности оперативно получить визуализацию — это же просто REPL какой-то! :)
Уточню — мне профессионально CAD совсем не нужны, я не готов вкладывать много усилий в их изучение. Я программист, у которого временами появляется потребность в трехмерном моделировании. Righteous zen programmer. :)
Спасибо. Очень бы хотелось, чтобы проект жил и развивался дальше.
Кстати, этой статье скоро два года, пора бы напомнить о себе и рассказать, что добавилось за это время :)
Нисколько не умаляя ценности данной библиотеки (самому очень нравится), все-таки справедливости ради замечу, что параметрическое моделирование (т.е. когда любая операция имеет численные параметры и занесена в стек — и в любой момент к ней можно вернуться и параметры изменить) есть практически во всех более-менее серьезных CAD-системах! ;) Какой-нибудь Tinkercad не в счет (там все, что только можно принесено в жертву ради снижения порога вхождения).
Для меня библиотека интересна скорее как возможность вывести в виде твердотельных моделей результаты какой-то алгоритмики… Не знаю — фракталы какие-нибудь, или сложные поверхности. ;) В виду наличия 3D-принтера именно это представляется наиболее интересным, кмк.
Для меня библиотека интересна скорее как возможность вывести в виде твердотельных моделей результаты какой-то алгоритмики… Не знаю — фракталы какие-нибудь, или сложные поверхности. ;) В виду наличия 3D-принтера именно это представляется наиболее интересным, кмк.
А я так и сказал — скорее всего есть, но я с серьезными CAD-ами не знаком и не имею мотивации вкладываться в изучение :) А тут порог вхождения (для программиста) очень низкий :)
Про сложные поверхности я тоже думаю, но это в перспективе :)
Про сложные поверхности я тоже думаю, но это в перспективе :)
В библиотеке, кстати, с некоторых пор появилась построение поверхности по массиву точек (процедура interpolate2), но ей таки обвязки нехватает. Не очень понятно, как эту поверхность в объёмное тело засунуть, для этого некоторая сноровка и понимание работы ядра требуется. В этом направлении тоже надо наращивать.
В защиту скриптового подхода в параметрическом моделировании могу заметить, что средства параметрического моделирования в современных мейнстримных CAD имеют часто ограничения по сравнению с нормальным языком программирования. То есть, размеры задать, массивы построить вы можете, но фильтры какие-нибудь посчитать, условные инструкции добавить, это уже сложно. Ну и конечно да, стирается грань для склеивания с результатами мат расчетов.
Безусловно. Скриптовый подход сам по себе — это довольно круто. Особенно в плане всевозможных процедурных алгоритмов, типа резьб, шестеренок и тому подобное.
Меня лишь немного смутило вот это: «повторяя одни и те же действия многократно, а потом исходные данные немного поменялись и начинай сначала». ;) Все-таки в современных CAD-системах процесс немного не так примитивен.
А так скриптовые системы сосуществуют параллельно с CAD-ами, занимают свою вполне определенную нишу. На thingiverse довольно много готовых параметрических моделей в формате openscad, что довольно-таки удобно.
Систем для скриптового моделирования много, но у них один общий… Ну нельзя сказать «недостаток», скорее подход: в них встроен некий язык, для написания скриптов. В вашем же случае парадигма иная: у вас cad-библиотека для языка! Это как бы предполагает (на мой взгляд), что мы идем от языка: что у нас какая-то крутая математика/физика/статистика… Да хоть — машинное обучение! ;) К которому идет возможность твердотельного моделирования. И это круто. Я поэтому спрашивал про вывод в jupiter-notebook, помните? ;)
Хотя, наверное, просто как sCAD для Python-разработчиков ZenCad тоже можно рассматривать — почему нет?
Меня лишь немного смутило вот это: «повторяя одни и те же действия многократно, а потом исходные данные немного поменялись и начинай сначала». ;) Все-таки в современных CAD-системах процесс немного не так примитивен.
А так скриптовые системы сосуществуют параллельно с CAD-ами, занимают свою вполне определенную нишу. На thingiverse довольно много готовых параметрических моделей в формате openscad, что довольно-таки удобно.
Систем для скриптового моделирования много, но у них один общий… Ну нельзя сказать «недостаток», скорее подход: в них встроен некий язык, для написания скриптов. В вашем же случае парадигма иная: у вас cad-библиотека для языка! Это как бы предполагает (на мой взгляд), что мы идем от языка: что у нас какая-то крутая математика/физика/статистика… Да хоть — машинное обучение! ;) К которому идет возможность твердотельного моделирования. И это круто. Я поэтому спрашивал про вывод в jupiter-notebook, помните? ;)
Хотя, наверное, просто как sCAD для Python-разработчиков ZenCad тоже можно рассматривать — почему нет?
Ну в том же не-совсем-мейнстримном FreeCAD вполне себе нормальный питон в качестве языка скриптов и тот же CASCADE под капотом.
Я в результате туда и ушел :) Основная проблема скриптовых языков — выбрать поверхность/вершину так, что бы при изменении параметров и перестройке всех шагов она осталась той же.
И с учетом того, что topo-naming'а в каскаде из коробки нет, а в FreeCAD'е его за 2 года так и не собрались смержить, то про какие-то кардинальные изменения параметров можно забыть.
Соответственно в качестве автоматизации подготовки либо для финальных сборок — да скрипты работают, но для низкоуровневого рисования — все-таки мышка намного удобнее :)
На начальном этапе я дошел до такого: github.com/sevikkk/valurap/blob/master/freecad/unbuild_part.py — конвертор из FreeCADа в питон, но проблема поиска вершин/граней всю идею очень быстро похоронила.
Я в результате туда и ушел :) Основная проблема скриптовых языков — выбрать поверхность/вершину так, что бы при изменении параметров и перестройке всех шагов она осталась той же.
И с учетом того, что topo-naming'а в каскаде из коробки нет, а в FreeCAD'е его за 2 года так и не собрались смержить, то про какие-то кардинальные изменения параметров можно забыть.
Соответственно в качестве автоматизации подготовки либо для финальных сборок — да скрипты работают, но для низкоуровневого рисования — все-таки мышка намного удобнее :)
На начальном этапе я дошел до такого: github.com/sevikkk/valurap/blob/master/freecad/unbuild_part.py — конвертор из FreeCADа в питон, но проблема поиска вершин/граней всю идею очень быстро похоронила.
Реально используемый код: github.com/sevikkk/valurap/blob/master/freecad/frame.py
Делает верхнеуровневую сборку всех покупных частей, для того, что бы можно было дизайнить пластик опираясь на реальные грани/отверстия/зазоры и т.д.
Делает верхнеуровневую сборку всех покупных частей, для того, что бы можно было дизайнить пластик опираясь на реальные грани/отверстия/зазоры и т.д.
Если честно, я только сейчас с вашей подачи узнал, что FreeCAD, по все видимости, так же может быть использован как модуль в привычной среде исполнения, такой как jupiter-notebook, например. ;) До этого я считал, что python встроен в него и использовать построение твердых тел, как часть чего-то большего — затруднительно…
Начал дальше гуглить — похоже даже в blender при желании можно зарядить какой-нибудь open-CV, или sklearn! Как собственно и упомянутый FreeCAD!
Начал дальше гуглить — похоже даже в blender при желании можно зарядить какой-нибудь open-CV, или sklearn! Как собственно и упомянутый FreeCAD!
Там немного сложно с использованием в качестве модуля, поскольку там все плохо с зависимостями и питон собран с нестандартными флагами, но его можно запустить в CLI режиме, когда он не показывает окно и не инициализирует визуальные части, но полностью работает вся моделирующая часть:
И можно макрос настроить, что-бы запускать в визуальном режиме. Ну и там есть просто окно консоли питоновой, в котором в интерактивном режиме можно потыкать API в контексте живой модели.
FreeCAD --consoleИ можно макрос настроить, что-бы запускать в визуальном режиме. Ну и там есть просто окно консоли питоновой, в котором в интерактивном режиме можно потыкать API в контексте живой модели.
>> ls /Applications/FreeCAD.app/Contents/Resources/bin/
FreeCAD FreeCADCmd ccx pip pyside2-rcc python
python — тут обычный питон, который ничего не импортирует раньше времени, но в котором можно все что нужно заимпортить и написать, вплоть до запуска UI :)Новую статью по библиотеке планировалось написать еще год назад, но жизнь, как говорится, закрутила. Будем навёрстывать. Как минимум, за два года мы стали сильно стабильнее, освоили анимацию, и некоторое дополнительное количество новых операций.
А вот это github.com/tpaviot/pythonocc-core
не замена вот этой библиотеке github.com/mirmik/servoce
случайно? Это я случайно нашел и на всякий случай информирую :)
не замена вот этой библиотеке github.com/mirmik/servoce
случайно? Это я случайно нашел и на всякий случай информирую :)
Два года назад она базировалась на заброшенном OCE.
Думаю эту мысль уже второй день и чем больше думаю, тем больше мне она нравится.
Когда я только начинал писать 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Мб. Таким образом придётся, видимо, дополнительно выкачивать его после установки.
В общем, я поэксперементирую в этом направлении, потому как проект уже начинает ржаветь, а такая модернизация может вдохнуть в него новую жизнь.
Sign up to leave a comment.
Система скриптового 3д моделирования ZenCad