Правильный ответ тут такой:
У нас есть открытый код freecad, который построен вокруг того же ядра. FreeCad позволяет экспорт в DAE и OBJ. Насчет GLTF я не понял.
Значит я теоретически могу посмотреть, как эта конверсия выполнена во FreeCad и сделать тоже самое.
На текущий момент кроме конвертации в stl есть конвертация в brep с возможностью экспорта во freecad (он в чертежи, кажется, умеет). Возможно будет построение сечений (мне их нехватает), но полноценных чертежей тут ждать не стоит (если они и будут, то в виде какой-то надстройки сверху и очень нескоро. Я ими заниматься совершенно нехочу, потому как мне они совершенно не нужны).
Отображение размеров в виде размерных стрелочек сейчас тоже нет. В принципе, сами примитивы для их создания можно добавить (надписи есть, линии есть), но это в любом случае будет не автоматическая простановка. Каждую стрелочку придется ручками прописывать в код. Фишка сомнительной полезности.
От части метод ближайшей точки, рефлексия, и макросы решают задачу выбора элемента геометрии. Вообще, я уделяю много внимания этой проблеме. Это действительно принципиальное слабое место любого скриптового када.
П.С. C#… VS… Что-то это как-то слишком сложненько.
Многие коментаторы этого поста говорят о том, как 3д модель удобно построить. ZenCad это немного о другом.
Я понял свою ошибку. Я сказал слово САПР. И понеслась. А ZenCad, это не САПР… Или, точнее, его можно использовать как САПР, но это не его цель. ZenCad — это библиотека 3д моделирования для экосистемы питона. Когда я писал его API визуализации, я вдохновлялся matplotlib.
ZenCad, это помимо собрать на коленке под 3д печать поломавшийся держатель для душа… Это и без нас…
ZenCad — это о том, как взять результат аналитического решения из sympy и построить по нему поверхность без промежуточных экспорто-импортов… Или же о том, как тяп-ляп нарисовать клешню робота и быстренько провести полунатурное моделирование без интеграции с gazebo…
Отличный вопрос.
Надо начать с того, что 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 — это просто визуализация нескольких невзаимодействующих тел на одной сцене.
Связи как таковые тут не нужны, потому что вы все равно не сможете переместить тело мышкой по сцене. Локация жестко определена скриптом. Концепт не тот…
Но думаю, это всё же не наш метод. Строго говоря, для zencad графический интерфейс — это что-то прикрученное сверху. Чем меньше обратных связей от gui к скрипту, тем прозрачнее работа системы.
Мне кажется, если человеку нужна нодовая система, он возьмёт Rhino или того же Houdini… И будет прав. Не зачем лезть в чужой огород.
zencad — это для программистов, которым понадобилось 3д.
В мануале даже девиз написан: CAD system for righteous zen programmers
Мне это представление всегда казалось новомодным ненужным наворотом. Это как функциональные диаграммы и Verilog. Verilog явно более могучий.
Такое представление, конечно, можно сделать, хотя оно будет работать только до тех пор, пока мы не подтягиваем дополнительных библиотек. А фишка ZenCad как раз в интеграции с экосистемой python. Сделать можно… Только зачем? Нодовое представление — это такой костыль, который применяется интерактивным графическим кадом, чтобы добавить параметризуемость, не добавляя скрипты, потому-что скрипты нарушают красивое дерево модели. А zencad — это как бы сразу о скриптах…
В общем, имхо, лишнее это…
Кстати… Если уж на то пошло, evalcache, который занимается контролем ленивых вычислений в zencad умеет визуализировать дерево вычисления в консоли (Для отладочных целей). Так что задача нодового построения фактически решена. Хотя и не нужна на мой взгляд.
Правильный или неправильный, полноценный или неполноценный САПР, это уж как кому нравится. 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. Было бы удобно.)…
Довольно мало. Использовал cjdns для того, чтобы ходить на домачний сервер через nat. Дело кончилось оформлением белого айпи адреса.
cjdns требует настройки. И на моем raspberry pi посему-то отваливается на вторые сутки работы.
Отличные новости. CJDNS был прекрасен, но работал нестабильно. Попробуем еще раз. Мешсети так или иначе быть.
У нас есть открытый код freecad, который построен вокруг того же ядра. FreeCad позволяет экспорт в DAE и OBJ. Насчет GLTF я не понял.
Значит я теоретически могу посмотреть, как эта конверсия выполнена во FreeCad и сделать тоже самое.
Так что да. Возможность есть.
Отображение размеров в виде размерных стрелочек сейчас тоже нет. В принципе, сами примитивы для их создания можно добавить (надписи есть, линии есть), но это в любом случае будет не автоматическая простановка. Каждую стрелочку придется ручками прописывать в код. Фишка сомнительной полезности.
П.С. C#… VS… Что-то это как-то слишком сложненько.
Я понял свою ошибку. Я сказал слово САПР. И понеслась. А ZenCad, это не САПР… Или, точнее, его можно использовать как САПР, но это не его цель. ZenCad — это библиотека 3д моделирования для экосистемы питона. Когда я писал его API визуализации, я вдохновлялся matplotlib.
ZenCad, это помимо собрать на коленке под 3д печать поломавшийся держатель для душа… Это и без нас…
ZenCad — это о том, как взять результат аналитического решения из sympy и построить по нему поверхность без промежуточных экспорто-импортов… Или же о том, как тяп-ляп нарисовать клешню робота и быстренько провести полунатурное моделирование без интеграции с gazebo…
Не вижу я в этих кейсах нодовой модели…
Надо начать с того, что 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 — это просто визуализация нескольких невзаимодействующих тел на одной сцене.
Связи как таковые тут не нужны, потому что вы все равно не сможете переместить тело мышкой по сцене. Локация жестко определена скриптом. Концепт не тот…
Но думаю, это всё же не наш метод. Строго говоря, для zencad графический интерфейс — это что-то прикрученное сверху. Чем меньше обратных связей от gui к скрипту, тем прозрачнее работа системы.
Мне кажется, если человеку нужна нодовая система, он возьмёт Rhino или того же Houdini… И будет прав. Не зачем лезть в чужой огород.
zencad — это для программистов, которым понадобилось 3д.
В мануале даже девиз написан: CAD system for righteous zen programmers
Такое представление, конечно, можно сделать, хотя оно будет работать только до тех пор, пока мы не подтягиваем дополнительных библиотек. А фишка ZenCad как раз в интеграции с экосистемой python. Сделать можно… Только зачем? Нодовое представление — это такой костыль, который применяется интерактивным графическим кадом, чтобы добавить параметризуемость, не добавляя скрипты, потому-что скрипты нарушают красивое дерево модели. А zencad — это как бы сразу о скриптах…
В общем, имхо, лишнее это…
Кстати… Если уж на то пошло, evalcache, который занимается контролем ленивых вычислений в 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. Было бы удобно.)…