LINUX.ORG.RU

Релиз OpenSCAD 2019.05

 , , , ,


5

1

16-го мая после четырёх лет разработки вышла новая стабильная версия OpenSCAD – 2019.05.

OpenSCAD – это неинтерактивный 3D CAD, являющийся чем-то вроде 3D-компилятора, который генерирует модель по скрипту на специальном языке программирования. OpenSCAD хорошо подходит для 3D печати, а также для автоматической генерации большого количества однотипных моделей по заданному набору параметров. Для полноценного использования требует только клавиатуру и базовые навыки написания кода.

OpenSCAD написан на C++, распространяется под лицензией GPLv2 и работает на всех основных ОС: Linux, *BSD, macOS, Windows.

Новое в этой версии

Ссылки

>>> Подробности

Deleted

Проверено: Shaman007 ()

Похоже в федоровских пакетах забыли включить поддержку геймпадов и 3D-печати =(.

Deleted ()
Ответ на: комментарий от Deleted

Похоже в федоровских пакетах забыли включить поддержку геймпадов и 3D-печати =(.

fix

Deleted ()

Надо будет глянуть, лол. Прошлая версия была отвратительно забагованной.

Deleted ()

Использую эту программу, так как не осилил мышевозительный CAD.

Заработала мне несколько сот евро на изделиях для калибровки измерительных приборов, применяемых в топосъемке пещер. (https://bitbucket.org/ngry/distox2_cube/src/master/)

Сильно не хватает ей быстродействия (как подсчета, так и рендера) на таких штуках как резьбы и всякие фаски/приливы.

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

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

Да кстати, рендер там адская смесь старого OpenGL с новым (в новый gllinestipple не занесли, а очень хочется).

nikitos ★★ ()

В убунтовский ppa ещё не завезли, там всё ещё 2015.03-2.

Beewek ()

Очешуеть, долго же они раскачивались :)

AP ★★★★★ ()

Интересная штука, я уже успел потыкать недолго.

aquadon ★★★★★ ()
Ответ на: комментарий от nikitos

Сильно не хватает ей быстродействия (как подсчета, так и рендера) на таких штуках как резьбы и всякие фаски/приливы.

Ты так пишешь, будто в ней есть резьбы, фаски и приливы...

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

Есть средства их создать, и есть примеры(https://dkprojects.net/openscad-threads/), которые для метрической резьбы работают и дают проверенный результат, для трубных и всяких 55 градусов резьб - не работают, но этож опенсорс, надо брать и дописывать, если сильно надо.

Для фасок и приливов - печаль.

nikitos ★★ ()
Последнее исправление: nikitos (всего исправлений: 1)
Ответ на: комментарий от nikitos

Сильно не хватает ей быстродействия (как подсчета, так и рендера) на таких штуках как резьбы и всякие фаски/приливы.

Так и на этапе собственно написания кода. Мне очень нравится эта штука, но пришлось осилить мышевозительный CAD тупо из-за скорости разработки штук в нем.

derlafff ★★★★★ ()
Ответ на: комментарий от nikitos

Есть средства их создать, и есть примеры

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

Для фасок и приливов - печаль.

Да не то слово.

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

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

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

В своих моделях проходил после печати метчиком, съём был минимальный, можно считать что это «калибрование» резьбы. Есть и другие резьбо-билиотеки, но там не просто печаль а вообще рука-лицо :)

Все таки резьбы, шестеренки и прочее требует гораздо больше математики...

Считаю что в этой резьбо-библиотеке «математики» для печати из пластика достаточно для практического применения. Тут имею в виду все еще метрические резьбы, потому как British Thread в ней реализован лишь заменой миллиметров в дюймы, без внимания к профилю, а это - провал...

С увеличением количества «математики», например для постройки эвольвентных профилей зубъев, закругленных профилей резьбы (для трубной, G-типа) итд, только лишь наличие «полной математики» не решает проблему.

Появляется проблема: как это все отрендерить на экране, так как рендер убог, и надо треугольники (для STL тоже), а не так как там в математике все красиво с параметрическими поверхностями. STEP-формат программа не поддерживает, а могла бы, но это уже вопросы к более к геометрическому ядру, а не к OpenSCAD.

Насчет применения в кровавом ынтерпрайзе - согласен, не подходит, долго муторно и почти во всем «закат солнца вручную». Начинаю постигать SolidWorks.

nikitos ★★ ()
Ответ на: комментарий от nikitos

Насчет применения в кровавом ынтерпрайзе - согласен, не подходит, долго муторно и почти во всем «закат солнца вручную».

Что еще хуже, не всегда понятно, где будет полная остановка. Я окончательно слез в сторону солидворкса после того, как элементарная конструкция в виде конуса с вычитанием из него двух цилиндров (два отверстия под шурупы) вдруг развалилась на экспорте в stl. Вот хрен знает, что это было... В солидворксе без проблем эта геометрия построилась и распечаталась.

AVL2 ★★★★★ ()
Ответ на: комментарий от nikitos

STEP-формат программа не поддерживает, а могла бы, но это уже вопросы к более к геометрическому ядру, а не к OpenSCAD.

Насколько я помню, текущий воркэраунд — засосать файл опенскада во фрикад и сгенерить степ оттуда.

AP ★★★★★ ()
Ответ на: комментарий от AP

засосать файл опенскада во фрикад и сгенерить степ оттуда.

Это не совсем так. От STEP хотелось бы чтоб элементы вроде окружностей/цилиндров/конусов итд оставались окружностями/цилиндрами/конусами.

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

nikitos ★★ ()
Ответ на: комментарий от AP

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

nikitos ★★ ()
Последнее исправление: nikitos (всего исправлений: 1)
Ответ на: комментарий от Puzan

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

Deleted ()

А я правильно понял, что они свой говноязык велосипедят, вместо того, чтобы взять Lua, или Python, или еще что-то готовое встраиваемое с поддержкой редакторов, IDE, и всего на свете? Если да, интересно почему :-(

anonymous ()
Ответ на: комментарий от Deleted

Это пони.

translate([-20, 30, 0]) color("magenta") cylinder(40,3,3);
translate([20, 30, 0]) color("magenta") cylinder(40,3,3);
translate([-20, -30, 0]) color("magenta") cylinder(40,3,3);
translate([20, -30, 0]) color("magenta") cylinder(40,3,3);

translate([0,70,69]) rotate([90,0,0]) color("magenta") cylinder(40,5,5);


color("magenta") difference() {
    translate([0,33,50]) rotate([90,0,0]) cylinder(66,24,24);
    translate([0,35,58]) rotate([90,0,0]) cylinder(16,5,5);
}

translate([0,-21,40]) color("magenta") cylinder(70,12,12);

color("magenta") difference() {
    translate([0,-30,120]) sphere(25);
    translate([0,-50,110]) sphere(5);
}

translate([7,-45,130]) color("white") sphere(8);
translate([-7,-45,130]) color("white") sphere(8);

translate([15,-20,130]) color("magenta") cylinder(25,5,2);
translate([-15,-20,130]) color("magenta") cylinder(25,5,2);

Доф нервно курит в сторонке...

anonymous ()
Ответ на: комментарий от anonymous

DSL в общем случае лучше, чем готовый язык широкого применения, если только ты не макакич, который кроме одного языка ничего выучить не может (привет датамайнерам-питонистам).

с поддержкой редакторов

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

anonymous ()
Ответ на: комментарий от metaprog

Угу, ящитаю, любой контент должен быть опенсорсным, не только код; причём опенсорсным в том смысле, что тебе даётся полный разбор модели контента, а не сфоткали чего-то бинарно или звукозапись сделали бинарно — и на, жри дерьмо под CC-BY-SA, извращаясь при редактировании. Натуральную музыку ваще давно закопать пора, приличная музыка давно создаётся софтварно, а не лабается руками и записывается на звукосниматель. (Щя придёт файрстартер и полыхнёт).

anonymous ()
Ответ на: комментарий от anonymous

DSL в общем случае лучше, чем готовый язык широкого применения, если только ты не макакич, который кроме одного языка ничего выучить не может (привет датамайнерам-питонистам).

Утверждение вообще ни о чем - внедрение DSL никак не связано с разработкой под каждый чих своего родного синтаксиса и семантики, похожего на другие, но не такого в деталях, вместо того, чтобы взять готовый из нескольких подходящих по области применения и заменить библиотеку.

Этим занимаются такие же больные придурки, которые под каждый проект свой сраный формат конфигурации изобретают, вместо того, чтобы взять что-нибудь из существующего зоопарка YAML / toml / ini / whatever.

anonymous ()
Ответ на: комментарий от anonymous

похожего на другие, но не такого в деталях

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

и заменить библиотеку

И будешь ложить всё на парадигму языка, извращаясь со всякими чейнингами, избыточными методами вместо операторов, объектами-пустышками в рантайме, замедляющими рендеринг? На фига, объясни? Вон из JS сейчас модно лепить всё подряд, даже официальный стандарт уже ни фига не похож на JS, который был ещё лет 10 назад, а хипсторы вообще обмазываются кучей плагинов для бабеля, превращая код в ни на что не похожее чёрти-что — и при этом всё равно гордо рассказывают, что пишут на JS и им не надо учить ещё какие-то языки. Даже HTML и CSS закопали, сделав вместо них пародию, расширяющую JS.

anonymous ()
Ответ на: комментарий от anonymous

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

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

И будешь ложить всё на парадигму языка

О чем вообще этот крик души? Начался тред с моего вопроса о Lua, но вообще мне насрать, я был бы и S-выражениям рад.

anonymous ()
Ответ на: комментарий от metaprog

Сарказм сарказмом, а реальность такова, что с символьными форматами работать удобнее, несмотря на визги гуманитариев типа тебя, которые так и мечтают выкинуть текст и наконец перейти на прямой обмен мыслеобразами, наивно полагая, что безграмотный Маугли способен сформулировать что-то внятное. Вон растровую графику уже закапывают, ибо с бумом HiDPI оказалось, что растровая графика сосёт, а описание графических примитивов — практичнее.

Недалеки те времена, когда и в камерах мобилок будет зашита нейронка — типа той, что в сетчатке глаза — распознающая на ходу образы и сохраняющая картинку как набор примитивов; так эффективнее хранить картинку, чем выплёвывать огромный RAW, а уже потом жевать растр и пытаться распознать, где там чего было. И примитивы, конечно, будут векторные; можно будет при редактировании просто взять и подвинуть объект «солнышко» или объект «букашка», не заморачиваясь с выделением контуров или ненадёжной автоматизацией оного в фотожопе и аналогах.

anonymous ()
Ответ на: комментарий от anonymous

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

Причина кардинальна — различие между данными, где тьюринг-полнота не нужна, и кодом, где она нужна. Причём удобно, когда тьюринг-полноту можно применить при надобности, но в общем при работе с данными она скорее мешает. Поэтому рулят форматы, где работа с данными отдельно, программирование отдельно, и всё это органично смешивается. Типа макросов в офисных пакетах, HTML+CSS+JS, да даже LuaTeX, например. И сабж тоже в эту сторону клонит, он даёт программировать там, где это нужно, но язык больше описательный.

изменении смысла распространенных конструкций

Нет какого-то единого «смысла», рассчитывать на него вредно; чтобы понять это, достаточно поверхностно освоить хотя бы 3–4 мейнстримных языка программирования. Без различия в деталях никуда, ведь различия и определяют разделение между языками.

Начался тред с моего вопроса о Lua

Ну налабай себе враппер на Lua, вот только на хрена? Взлетит — докажешь, что правда твоя, а нет — ну и нечего бухтеть тогда, синтаксис ему не то, язык не эдак. Компутерщики зачастую болеют техноперфекционизмом, из-за чего не могут тупо пользоваться компутером, как нормальные люди; прежде чем что-то нахреначить — начинают думать, а как его лучше сделать, ещё и гордятся этим. Вот только мартыханы за это время уже пришли к результату, а технарь ещё сидит и думает. Жрычёдали и не выпендривайся; улучшать будешь, когда поюзаешь и поймёшь, что конкретно не так, и стоит ли овчинка выделки. Иначе получится именно что бесполезный велосипед, которых ты так боишься.

anonymous ()
Ответ на: комментарий от anonymous

Натуральную музыку ваще давно закопать пора, приличная музыка давно создаётся софтварно, а не лабается руками и записывается на звукосниматель.

Что же такое приличная музыка в твоём понимании? :)

AP ★★★★★ ()
Ответ на: комментарий от AP

Которую пипл хавает, а не полтора илитария (которых на самом деле тысячи, потому что Ълитарность заразна).

anonymous ()
Ответ на: комментарий от anonymous

Ну налабай себе враппер на Lua, вот только на хрена?

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

Нет какого-то единого «смысла», рассчитывать на него вредно; чтобы понять это, достаточно поверхностно освоить хотя бы 3–4 мейнстримных языка программирования. Без различия в деталях никуда, ведь различия и определяют разделение между языками.

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

Причина кардинальна — различие между данными, где тьюринг-полнота не нужна, и кодом, где она нужна.

Спасибо за лекцию на тему, я так понял про S-выражения ты намек не уловил?

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.