hypera1r has quit [Remote host closed the connection]
LordOfBikes_ has joined #openscad
hyperair has joined #openscad
<linext>
i ordered 8 leatherman free p2 thumb studs in stainless steel from JLCPCB
<linext>
$8 each + shipping
<linext>
hopefully will sell for $20 + shipping
califax has quit [Ping timeout: 255 seconds]
califax_ has joined #openscad
califax_ is now known as califax
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
hyperair has quit [Quit: Segmentation Fault]
hypera1r has joined #openscad
ur5us has quit [Ping timeout: 260 seconds]
J233179 has joined #openscad
J2331 has quit [Ping timeout: 260 seconds]
ur5us has joined #openscad
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #openscad
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #openscad
RichardP_ has quit [Ping timeout: 255 seconds]
ur5us has quit [Ping timeout: 260 seconds]
guso78 has quit [Ping timeout: 260 seconds]
splud has quit [Quit: Leaving]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
snaked has quit [Quit: Leaving]
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
<lkcl>
oh! does openscad have python bindings now? if so that's absolutely fantastic!
<lkcl>
julia longtin, when working on ImplicitCad, ended up with the most spectacular fragmentation explosions :)
aliervo[m] has joined #openscad
<teepee>
just in a very lovely Haskell field :)
<lkcl>
teepee: yeess.. :)
<lkcl>
i did Functional Programming in 1989, we used Hope - a parallel programming language specifically developed by Imperial College (!)
<lkcl>
i could barely get my head round it but remember the basics (forward and backward induction)
<lkcl>
it's extraordinarily powerful but hoo-boy
<lkcl>
julia solved the "corner rounding" problem by adding it as an extra parameter to cube()
<teepee>
SDF does give that feature relatively automatically
<lkcl>
and also solved the "these two objects are butted up against each other precisely and exactly but FP64 rounding determines otherwise, oops"
<lkcl>
niiice.
<lkcl>
btw for context i am a 10+ year user of openscad and the de-facto maintainer of pyopenscad
<teepee>
greetings :)
<lkcl>
it was very unfortunate that i discovered pyopenscad just literally as its developer was carrying out (but had not released) a rewrite, known as "SolidPython"
* lkcl
salutes teepee :)
<lkcl>
so i ended up with far too much effort invested in pyopenscad (3 3D printers and a Category L7e Hybrid EV of dimensions 1.5 x 3.1 x 1.2 *metres*)
<lkcl>
and can't now switch without one hell of a lot of work
<teepee>
ah, yes, that's why we need more new languages every year :)
<lkcl>
direct python bindings to openscad's *full* capabilities (except for functions, loops, and modules) are therefore a "high priority interest" to me.
<teepee>
I think the way this code works is very neat as at the core it can work without any boiler plate code
<teepee>
well, except the single "output()" currently, maybe there's a way to even around that one
<lkcl>
well with 1/3 the world's programmers knowing python, it's the highest bang-per-buck, but to be absolutely honest pyopenscad and SolidPython do a damn good job, freeing you up from any "urgency" to focus on "doing one thing and doing it well"
<teepee>
keeping the spirit of the openscad hello world: cube()
<lkcl>
yeah.
<lkcl>
from pyopenscad import cube, union, scad_render_to_file
<lkcl>
the other one that tends to go down well in the embedded world is lua, because it is so tiny and self-contained
<lkcl>
but, again, just like pos/SP, you can treat SCAD as a machine-code-target, so why add {insert-language-here}-bindings again?
<lkcl>
oh pyopenscadobj auto-generates a BOM CSV file btw
<teepee>
simple open source answer - because someone wants to do that
<lkcl>
if anyone is ever thinking "damn that's something i really need"
<lkcl>
yes. because need.
<lkcl>
and because easy [for me]
<lkcl>
like julia, doing ImplicitCad.
<teepee>
one of the goal of openscad is: start typing - get 3d model
<teepee>
for *everyone*
<lkcl>
is SolidPython and pyopenscad on the list of "alternative ways to use openscad", on the website?
<teepee>
if we can make that happen with the new python bindings, I think that's a great addition
<lkcl>
please please if you are going to spend the time do look very closely at pos and SP
<lkcl>
pos does not generate loops, does not generate functions. it outputs the *primitives* and...
<lkcl>
are you familar with assembler "loop-unrolling"?
<lkcl>
that's what pos does.
<lkcl>
you use a *python* for-loop, a *python* function, a *python* module, a *python* object
<lkcl>
and you add cubes/spheres/cylinders/STLs/polygons to a difference() object or a union() object
<lkcl>
where the "+=" operator has been *overloaded* on the union object to *return another union object*
<teepee>
that's probably a discussion for guso78
<lkcl>
it's extremely elegant and natural, you just do:
<teepee>
who's not here at the moment
<lkcl>
u = union()
<lkcl>
u += cube([1,2,3])
<lkcl>
u += translate([3,4,5]).add(cube([9,10,11]))
* teepee
does not like that at all
<lkcl>
etc.
<lkcl>
ok
<lkcl>
it's extremely natural and obvious to any experienced python programmer
splud has joined #openscad
<lkcl>
because it is an accepted OO paradigm that is *already established* as a convention / standard, within the *python* community
* lkcl
been using python since 2000. holy cow 23 years
<lkcl>
existential moment :)
<teepee>
I don't like most of OO stuff either, it has proven to be very annoying in code maintenance
<InPhase>
lkcl: And what about d = difference()?
<InPhase>
lkcl: Always evaluate the awkward case rather than the clean case.
<lkcl>
InPhase, ah, there the first thing that is added is as you would expect, and the second (and subsequent) begin the actual "removal"
<teepee>
I suppose that could have a single initial parameter?
<teepee>
and overload -= ?
<lkcl>
teepee, yes i believe -= returns a difference()
L29Ah has quit [Read error: Connection reset by peer]
<lkcl>
you do actually have to inspect the resultant openscad the first time you use it, because it is not entirely obvious when it comes to color() and so on
<lkcl>
it took me about a year to work out why i had some mistakes in my use of pyopenscad, during a particularly complex project (a 15in Laptop casework made from *36* separate parts). 18 months work (!)
<lkcl>
in the end i stopped using the "-=" and "+=" operators and just used "add"
<lkcl>
u = union()
<lkcl>
u.add(cube([1,2,3])
<lkcl>
d = difference()
<lkcl>
d.add(...) # the main object
<lkcl>
d.add(...) # the first thing to subtract from the main object
<lkcl>
d... etc.
<lkcl>
that then became my default usage style for the next 6 years
<aliervo[m]>
I don't really python, but wouldn't it make more sense if ".subtract" was used for difference?
<aliervo[m]>
Like 3dthing.subtract(...)
<InPhase>
lkcl: One option is += as "union this" and -= as "difference this", except that then you don't even want union() and difference() to form the starting point. You would want something more like c = cube(...); c -= cylinder(...)
<InPhase>
lkcl: This is why u = union(); u += ... might not be intuitive, if it collides with intuition on the other operators.
<InPhase>
Under this thinking, I'd rather something like a difference take a list parameter. Like difference(*objs)
<InPhase>
And then you could optionally do difference([main, sub1, sub2])
<InPhase>
Or maybe difference(main, [sub1, sub2]) would be clearer.
<InPhase>
Yeah, the second is clearer.
<InPhase>
But I wouldn't commit to that until seeing the full set of operations written out for cross-comparison and self-consistency.
<lkcl>
line 308, that's exactly the syntax supported!
<lkcl>
union(*objs) or difference(*objs), through an overload of __call__,...
<lkcl>
oh wait
<lkcl>
it's:
<lkcl>
u = union()
<lkcl>
newobj = u(obj1, obj2, obj3)
califax has quit [Remote host closed the connection]
califax has joined #openscad
<InPhase>
lkcl: That was also developed so far without the sort of broad community discussion that really benefits language development.
<InPhase>
(Which is not a criticism per se. It was rapid development of an interesting new feature. And maybe a feedback stage should be happening now/next.)
<lkcl>
InPhase, pyopenscad was abandoned 10+ years ago when its original authors were converting/renaming to SolidPython. i am trapped as the only user and de-facto maintainer!
<lkcl>
so it's not that there's been *any* kind of community discussion because it's literally a community of qty one (1) person - me! :)
<lkcl>
but the sheer astounding size and complexity of the designs i have been developing with pyopenscad gives some extremely useful - community permitting and willing - insights
<InPhase>
Oh. That's not the thing I thought it was. Sorry, I was busy with work and only quick glanced at it.
<lkcl>
i mean for goodness sake is there anyone else in the world that has constructed a *6* cubic metre 3D CAD design with openscad, comprising 500+ parts? :)
<lkcl>
ah you mean the openscad python bindings?
<InPhase>
Yeah. I thought you were linking to an example of that.
<lkcl>
if that's what you meant, i've only just found out about them 1 hour ago (and am delighted to hear they exist)
<InPhase>
Perhaps you should join forces on that PR.
<InPhase>
Then your community size would at least double!
<InPhase>
There might be elements mergeable or lessons convertible.
<InPhase>
Although you'd have to accept that the final syntax will probably differ in breaking ways. But the usage could end up very nice.
<lkcl>
well an adapter/converter is always possible.
<lkcl>
but there are two mitigating factors (unfortunately): 1. i am a Libre Developer. i closed my github account after my debian dev friend told me i was being hypocritical, i agreed with him and immediately terminated the account
<InPhase>
Oh. Well, most of the open source world remains on github, so that's where we need to do our business.
<lkcl>
and 2) i am extremely happy with pyopenscad, and how pyopenscadobj auto-generates the BOM, which saved huge amounts of work for the three (very complex engineering-wide) 3D printers i designed
<lkcl>
indeed.
<InPhase>
I do generally love Python. I prefer to avoid it for 3D model design primarily because I like the security benefits of a domain specific language being able to promote unrestricted sharing of designs and libraries.
<lkcl>
converting would involve re-reading some fantastically-complex OO python that in the case of the 15in laptop was 18 months work, in the case of the Hybrid EV it is... 6-8 months work
<lkcl>
well you can always share python libraries the same way
<lkcl>
and you have the added bonus of access to scipy, numpy etc.
<InPhase>
Yeah. I do a lot of data analysis at work with those, so I'm an advocate in other areas. :)
<lkcl>
i have a spline-surface-generator for example, you give it a 2D array of 3D points, tell it to spline first along the rows and second along the columns
<lkcl>
and a thickness "normalisation" vector - i pieced it all together from stackexchange recipes :)
<lkcl>
sshh, don't tell anyone
<InPhase>
It's just that there's an element of trust required, and most 3D modellers are not equipped to do code review for security issues. So it's a different development target I think, to build up a large safe sharing community.
<lkcl>
indeed.
<lkcl>
there is a similar "problem" (wrong word: "mindset / training" would be better) in VLSI (hardware design)
<InPhase>
I like them enough that I introduced numpy into our OpenSCAD testing suite for image comparison.
<lkcl>
both VHDL and Verilog, the primary languages, are approximately 30 *years* out-of-date. VHDL is actually ADA, and Verilog was developed initially for test suite purposes
<InPhase>
It's a different target when we're sharing code to be run by other developers.
<lkcl>
yes
<lkcl>
yes, very much so. i love but also despair of thingiverse :)
<InPhase>
There will be another thingiverse I think. Several are trying.
<lkcl>
you know what i mean. i absolutely love the herringbone gears scad libraries, used them for building a circular compact direct-drive extruder (pure PLA, no metal)
<lkcl>
oh good to hear
<linext>
can i get some help simplifying a design so that it can be printed on JLCPCB stainless steel?
<lkcl>
argh that is so simple to use and gets almost precisely the results i need
<lkcl>
that's really funny and annoying at the same time. annoying because 1 *week* of printing 5+ kg of PLA i only then learn of this useful primitive, ah c'est la vie
<linext>
yea, if you get stuck you can post an image or the code in this chat and get some help
<teepee>
there are literally books on how to use python and openscad :)
<teepee>
but I do like your way of integration as it brings a simplicity most other solutions can't easily provide
<guso78>
teepee, very interesting. i dont know any. i know that there many openscad-pthon- "wrappers" ...
<teepee>
which does not make them bad or anything, just more targeting people who know programming
<guso78>
teepee,i used ths feature previsouly. i know that openscad automatically re-renders when the source file change. that means, another tool can create the openscad in background and openscad just shows the new object
<guso78>
teepee, haha, didnot know that. would you still reccommend to me when i have coded the python bindings ?
<teepee>
it's vastly different from those generators and like I said, in some aspects much better (obviously in my personal opinion ;-)
<guso78>
consider getting one of them
<guso78>
but my main goal with openscad is rather "more features" than "write it down simple/intelligent"
<guso78>
teepee, you won't believe it, but the main reason i did the python bindings was the fact, that i was not able to reassign variables in openscad. i did understand the recursive approach to circumvent it , but IMHO is still a hack.
<teepee>
that's fine, I see quite some potential in having those different options
<teepee>
plus sharing and hopefully extending the geometry engine will benefit both ways
<teepee>
which is why I believe this could be one of the cases where the result can be much more then just the sum of it's parts
<guso78>
teepee, yes, once the python is somehow established, you can use callback-functions for the extrude. the cross section will change along its way
guso78 has quit [Quit: Client closed]
guso78 has joined #openscad
<guso78>
and once the offset is there, you can round any object by offset(-x) then offset(+x, round=True)
<teepee>
the framework for that exists in openscad scripts too now
<teepee>
it probably should be an expression as parameter, implictcad shows how that can work and be very powerful
<teepee>
same is possible with python too of course
<guso78>
teepee, yes i learned, but the framework is based on openscad(with openscad the expressions might be longer than needed and as an interpreted language not as fast c)
<teepee>
for most operations the geometry stuff is slower by many orders of magnitude
<guso78>
yep, unfortuntely
<teepee>
if the mesh calculation takes 5 minutes, it does not really matter if you script ran in 0.1 or 0.0001 seconds
<teepee>
on the plus side, there's possible ways there too, with fast-csg and maybe even Manifold + GPU support
<guso78>
teepee, you are right here.
<guso78>
i have looked in the BOSL2 code and i had some issues to read the code.(but this is probably true for any foreingn code)
<teepee>
yeah, it has some very cool and complicated stuff, and has to do lots of things in awkward ways due to missing lower level geometry support
<teepee>
that does not have too much to do with the language used
<guso78>
two days back i was able to successfully walk a octaeder and a cube in parallel" with my facetracer script in python. i am wondering if i will ever reach quality of CGAL here(and how speed compares with CGAL)
<guso78>
no, the two objects did not yet interact
<guso78>
next is to calculte cuts between edges and faces
<guso78>
teepee, did you succeed in using manifold for a simple application ?
<teepee>
I'd need at least a quiet block of time more than 2h
<teepee>
right now it feels more like being the white rabbit always jumping into the next rabbit hole
<guso78>
teepee, was able to create a Manifold::Cube but i was not able expport it to something i could see
<teepee>
I'd love to have a look, but probably some of the PRs should have higher priority
<guso78>
teepee, it appears you do not even have bandwidth to grab the low-hanging fruits ...
<guso78>
teepee,whats the openscad native function to calculate the cross product vector?
<teepee>
right now, no, except very low hanging stuff like new (human) language support and such obviouls things
<teepee>
cross()
<guso78>
ah, its an eigen function
<teepee>
they have a test folder in the Manifold repo, I might be able to give that a try at least
<teepee>
but first, dinner :)
<guso78>
have a nice dinner
<guso78>
teepee, they have a great test suite, which says "pass" to all their tests, but i was not able to output to see myself ...
<teepee>
the test folder seems to have some SDL based examples, I would expect those to show some window at least?
<guso78>
teeepee, i dont know, i did not focus on the SDL ...
<teepee>
haha, no, misread SDF :)
<teepee>
cool, that's also in there?
<guso78>
SDF counds familiar, not SDF
<guso78>
i believe they export in another 3d fomat which was not common to me and i did not easily find converters
<teepee>
yes, glTF
<guso78>
hmm, sorry, cant recall
<teepee>
oh, my, using assimp library
<teepee>
which in theory is great with lots of formats supported, but I did have some problems reading even simple files with that (some time ago)
<lkcl>
the only reason the rest of vehicle_3d looks "more" is because i have evolved waaaay beyond even 1,000-line programs, into 10k LOC
<guso78>
lkcl1 , yes, both is python syntax, but my approach does one execution per line, where you rather fill in a database and output the result in the end
<lkcl>
i was not the initial author of pyopenscad, but i think what they do is accumulate an internal Abstract Syntax Tree data structure, which is then parsed (node-walked) by the scad_render_to_file() function, to generate the ASCII text which oh look! the ASCII text happens to be SCAD!
<lkcl>
iow pyopenscad is actually a language-translator, technically speaking