Ограничений связей как таковых нет. Для того, чтобы сделать сборку надо взять несколько тел и транслировать их в нужные места. Анализа перекрытия тел так же не производится.
Вообще, сборки в 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. Было бы удобно.)…
Вообще, сопряжения как таковые тут не прописываются.
Всё делается за счет правильно расчитанных цепочек размеров. Этим же обеспечивается параметризуемость и перестраиваемость.
Думаю, разработка windows версии на текущий момент в приоритете. Проект достаточно неплох, чтобы предложить его широкому кругу пользователей. Понятно, что без windows версии широкого распространения пока ждать не приходится. Так что над windows версией буду работать.
Вообще, изначально я собирался писать статью уже после проработки windows версии. Но там еще непочатый край работы, а лайки хочется собрать уже сейчас…
Вроде бы мнение о разных мозгах сформировалось под влиянием того факта, что мозг мужчины в среднем на сто грамм тяжелее мозга женщины. Во всяком такую версию я слышал. Дальнейшие исследования, впрочем, как утверждал тот же источник, показали, что вся эта масса приходится на соединительное вещество. По видимому мужчин чаще бьют по голове.
В очередной раз хочу упомянуть, что классификация есть проявление работы интеллекта.
В объективной реальности нет живой и неживой материи. Нет мягкого и жесткого времени, операционных систем реального времени и встраиваемых ОС. Это общие принципы, черты системы, которые выделяются нами, людьми, чтобы нам удобно было говорить о созданных нами системах.
Понимание того, что есть система реального времени может различаться у исследователя и практика. Потому что им в их работе удобно другое чуть-чуть другое понимание этого термина. Хотя говорят они об одном и тоже объективном явлении.
В зависимости от решаемой мной задачи, вирус может быть формой жизни, а может не быть ей. Это конечно не то знание, которым стоит ломать стройную картину миру студентам вузов и прочим лицам, пытающимся сформировать непротиворечивую картину мира, но с какого-то уровня понимания, все же стоит держать в голове, что это все это просто слова.
Фактически здесь на уровень логирования переноситься идея сборок Debug/Release. Строго говоря, он, вероятно, прав когда ставит под сомнения схему trace/debug/info/warn/error/fatal, как единственно возможную, но схема info/debug буквально требует второй уровень приоритетов.
Например, я часто в warning пишу информацию, которой уместнее было бы жить на уровне debug, но которая имеет определенную степень важности. На уровне debug она просто потеряется вследствии его загаженности. В этом смысле вызывает вопрос, что warning приоритетней info.
Вероятно, стоит задуматься над более гибкой схемой настройки уровней логирования.
Как лучше выбрать модель телефона под эксперимент с использованием с LinageOS?
Есть ли какая-то сводная таблица, или надо каждую модель искать на 4pda (сайте производителя) отдельно?
Любопытная механика. Можно попробовать написать такое, используя апи бота.
То есть, вроде как играет бот, но ему подсказывает человек. Шахматы наоборот.
Вообще, сборки в 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. Было бы удобно.)…
Всё делается за счет правильно расчитанных цепочек размеров. Этим же обеспечивается параметризуемость и перестраиваемость.
Не совсем понял про сопряжения…
В примерах, которые идут с библиотекой есть такой пример:
Organizer
Вот результат работы этого примера:
Также можно посмотреть сюда:
Zippo
Это модель моего 4-х колёсного робота, представленного на первом скриншоте.
Вообще, изначально я собирался писать статью уже после проработки windows версии. Но там еще непочатый край работы, а лайки хочется собрать уже сейчас…
В объективной реальности нет живой и неживой материи. Нет мягкого и жесткого времени, операционных систем реального времени и встраиваемых ОС. Это общие принципы, черты системы, которые выделяются нами, людьми, чтобы нам удобно было говорить о созданных нами системах.
Понимание того, что есть система реального времени может различаться у исследователя и практика. Потому что им в их работе удобно другое чуть-чуть другое понимание этого термина. Хотя говорят они об одном и тоже объективном явлении.
В зависимости от решаемой мной задачи, вирус может быть формой жизни, а может не быть ей. Это конечно не то знание, которым стоит ломать стройную картину миру студентам вузов и прочим лицам, пытающимся сформировать непротиворечивую картину мира, но с какого-то уровня понимания, все же стоит держать в голове, что это все это просто слова.
Например, я часто в warning пишу информацию, которой уместнее было бы жить на уровне debug, но которая имеет определенную степень важности. На уровне debug она просто потеряется вследствии его загаженности. В этом смысле вызывает вопрос, что warning приоритетней info.
Вероятно, стоит задуматься над более гибкой схемой настройки уровней логирования.
Есть ли какая-то сводная таблица, или надо каждую модель искать на 4pda (сайте производителя) отдельно?
То есть, вроде как играет бот, но ему подсказывает человек. Шахматы наоборот.
Любопытная тема для исследований. Отто Октавиус.
Поведение системы ориентации на земле, когда есть реакция опоры и в воздухе — две разные вещи.
Как отлаживать фильтры для дронов, чтобы не получить много удивления в момент отрыва аппарата от земли?