teepee has quit [Remote host closed the connection]
teepee has joined #openscad
RoyK has quit [Ping timeout: 276 seconds]
dinizex has joined #openscad
<dinizex>
Hello There!
<dinizex>
Im looking for one help!
RoyK has joined #openscad
<dinizex>
im going to send the problem later!
mmu_man has quit [Ping timeout: 268 seconds]
pa has quit [Ping timeout: 244 seconds]
mmu_man has joined #openscad
pah has joined #openscad
<church_>
InPhase: imho ideally would be to have openscad new built-in function to measure. After all, isn't capability for there already there? How otherwise resize() or textmetrics() can find out real sizes?
<church_>
technically one cal also use resize to always resize to specific preset size (probably with other dimensions left on auto, not not change relative shape), and then use that .. but still should work on theoretically random/unknown size imported objects
<ali1234>
playing around with the slow stl and i reduced it down to "projection() import(...);"
<ali1234>
i did this by pre-rotating the STL before exporting it
<ali1234>
however, projection() on the openscad code, without exporting, works okay
<ali1234>
next i'll try to simplify the STL further while still reproducing the problem
<ali1234>
it seems this operation isn't just slow - it never completes
<ali1234>
still not segfaulted again though
<church_>
ali1234: just for any case i'd check in parallel memory consumption of app
dinizex has quit [Quit: Client closed]
<ali1234>
the memory consumption does not seem particularly high
<ali1234>
about 700MB according to top
<church_>
sometimes with too detailed object computing it slowly creeps up for me, and at end of course dies when all memory filled up
<church_>
oh, 700, sounds reasonable. better then 15-25G in some case for me :D
<InPhase>
ali1234: projection() import(...) failing to complete is really wild.
<InPhase>
ali1234: But that sure sounds like something to make an issue.
<ali1234>
will do, just trying to make the simplest possible stl that reproduces it
<InPhase>
A worthwhile result. :)
<ali1234>
i have "timeout 3s openscad ..." running in a loop in shell window, while i repeatedly export different STLs, so i can immediately see if it reproduces
<InPhase>
lol. Nice.
<InPhase>
Are you bisecting the original? Or trying to generate simpler variations with the original script?
<ali1234>
trying to generate simpler versions from the original scad
<ali1234>
which is quite easy to do
<ali1234>
i found that $fa = 1; $fs=1; does not reproduce
<ali1234>
but $fa = 1; $fs = 0.2; does
<InPhase>
The best insights will probably come from commenting out features, like those holes and such.
<ali1234>
yes
<ali1234>
oh did i mention, the original uses roof() :)
<pca006132>
we can probably parallelize the projection function
<pca006132>
currently iirc it is just projecting each triangle into a plane and feed all of them to clipper
<pca006132>
clipper may not be too happy about this :)
mmu_man has quit [Ping timeout: 268 seconds]
<ali1234>
i reduced the STL down to 3000 triangles, 1MB ascii
<ali1234>
projection() render() { the bad geoms } can reproduce it!
<ali1234>
sort of... it takes 14 seconds rather than never finishing at all
<InPhase>
teepee: To the point where lots of things are just timing out.
<dinizex>
Could anyone help to develop that?
<dinizex>
help me*
<InPhase>
dinizex: Do you need the rounded edges like shown there?
<dinizex>
I think it will be better rounded
<dinizex>
what do u suggest?
<dinizex>
im going to use a double tape to fix it!
<church_>
rounded edges best way to make with rounded objects in corners that are hulled together
guerd has joined #openscad
<church_>
if it's large radius bend with rounded edges, then one can consider either with resize() or scale() squished sphere, or rotate_extrude small circle
<dinizex>
nice
<church_>
eg. cube - with rounded all the edges and corners - just 8 small spheres spaced their radius closer to supposed cube dimensions
<church_>
of course one can also use minkowski, but would advise not to, due it being computing intensive on anything but basic shapes
<ali1234>
how are you going to make the part?
<dinizex>
With PETG!
<dinizex>
it could be geometric?
<ali1234>
then make the cross section first and linear extrude
<church_>
if it's some wallhanger that will be 3d printed, suggest to pay attention to alignment on plate direction. as FMD 3d printed parts strengths greatly differ depending on layer orientation
<dinizex>
I got u
<dinizex>
but it will be for a device very light
<InPhase>
dinizex: I think with I'd do that with it laying down on the side in 2D, linear_extrude, then minkowski with a sphere.
<dinizex>
I agreee
<InPhase>
dinizex: The dimensions aren't super well marked, so it's not obvious what all the numerical values are, but it should be pretty straightforward to do that way. Working in 2D lets you take advantage of offset with both positive and negative values, which gets you that shape pretty easily. Also hull can be used in parts.
<InPhase>
dinizex: There's an alternative option of using the ClosePoints library here, which would give you that entire shape in one module call if you can write down code for the top and bottom paths of that shape.
<dinizex>
it could be potted instead of plastered where it goes on the wall
guerd has quit [Ping timeout: 252 seconds]
<dinizex>
it will save a lot of material
<dinizex>
could be hollow instead of solid where it goes on the wall**
<InPhase>
dinizex: When you decide you want it to not break, you should change the design. The most fragile part of that, as a wall shelf bracket will be the bend on the right side of that image.
<InPhase>
dinizex: It's fairly thin, and will get broken when someone bumps into the tip hard enough.
<InPhase>
dinizex: You could stylishly make that plastic thicker at that point, without making the whole thing any thicker.
<dinizex>
but will be to hold a very light device
<InPhase>
Yeah. It's when someone bumps the tip that it will snap. Not from what it's holding. It will be stronger for holding.
<kintel>
If anyone wants to troubleshoot or continue slimming down: This is the smallest crash without editing the STL: projection(cut = false) multmatrix([ [ 0, 1, 0, 0 ], [ 0, 0, 1, 0 ], [ 1, 0, 0, 0 ], [ 0, 0, 0, 1 ] ]) import("hingeplate.stl");
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
stealth_ has quit [Quit: Leaving]
SharpHammer has joined #openscad
<InPhase>
kintel: Crap. Heisenexportbug features. Apply the projection() multmatrix() original freezes. But save stl on multmatrix() original and then projection() savedstl doesn't crash.
<InPhase>
I was going to try to reduce the stl down to something inspection sized, but... exporting undoes the bug.
misterfish has joined #openscad
<InPhase>
Hmm... But maybe because the ascii export is less precise now.
<InPhase>
ali1234: How did you even make hingeplate.stl? All the versions of OpenSCAD I tested with save 32-bit float based stl files, but your stl is marked with "Solid OpenSCAD Model" while having 64-bit double precision.
<InPhase>
ali1234: What version produced this original file?
SharpHammer has quit [Ping timeout: 240 seconds]
dingodoppelt has quit [Read error: Connection reset by peer]
dingodoppelt has joined #openscad
aiyion4 has quit [Remote host closed the connection]
aiyion4 has joined #openscad
little_blossom has joined #openscad
misterfish has quit [Ping timeout: 252 seconds]
mmu_man has joined #openscad
misterfish has joined #openscad
mmu_man has quit [Read error: Connection reset by peer]
kasesag has joined #openscad
J25k70 has quit [Quit: Client closed]
J25k70 has joined #openscad
<JakeSays>
so does 'render' (F6) now render in colors other than yellow and green?
<JakeSays>
if so - very cool!
<JakeSays>
ah its only in manifold mode?
misterfish has quit [Ping timeout: 260 seconds]
<teepee>
yes and yes
misterfish has joined #openscad
Guest47 has joined #openscad
Guest47 has quit [Quit: Client closed]
<buZz>
JakeSays: btw, with the theming you could already change the yellow and green ;)
<buZz>
just wouldnt be inside the expot
<buZz>
export*
George has joined #openscad
George is now known as GeorgeDerII
<GeorgeDerII>
Hello!
<GeorgeDerII>
First of all thanks for OpenSCAD. But how can I create measure arrows to objects/modules?
J25k70 has quit [Quit: Client closed]
J25k70 has joined #openscad
GeorgeDerII has quit [Quit: Client closed]
<church_>
JakeSays: even more so, manifold for me often renders quicker then F5 (possibly also due caching though :) )
<church_>
i really want for next stable release to be pushed out, even if only addition to it would be manifold :)
snaked has quit [Quit: Leaving]
<buZz>
yeah manifold is a looooooot faster
<buZz>
i'v seen 'hours' render take less than seconds with manifold
<dTal>
what's the catch?
<buZz>
i havent found many
<buZz>
sometimes it behaves slightly different
<buZz>
like on 0.01mm differences in height
<JakeSays>
I am very impressed with the manifold performance
<dTal>
That seems quite large, what processes are that indeterminate?
<buZz>
no , i ment when i have two surfaces with tiny differences, you get those shady lines on CGAL?
<buZz>
on manifold they behave differently
<InPhase>
dTal: The main catch is that OpenSCAD has become a lot less effective for warming the room on winter days.
<dTal>
Hm, why is OpenSCAD trying to do an SSL handshake
<church_>
small differences somewhere more often may leave hairs with manifold imho. but then again, for performance increase i'm willing to forgive a lot.
<church_>
i'm not sure, but imho CSG F5 perf seems slower to me. Mostly, if i didn't prefix all intersection & intersection_for with render(). But it might also be placebo feeling, as back then with stable openscad i worked with other models & almost didn't use intersection at all
<dTal>
it's those damned minkowski fillets that are the killer for me
<buZz>
i moved to 2D and offset() for such stuff mostly
<buZz>
its sooooo much faster to do
<dTal>
2d no good
<buZz>
2d excellent
<buZz>
:D
<buZz>
also hull() is often much faster than minkowski()
<dTal>
...they're not at all similar?
<church_>
i try to not use them as much as possible. all the "basic" straight or simple-rounded surfaces i just do with adding for fillet extra object from cylinders or rotate extrudes, or create objects themselves. minkowski at most only for where it's hard to think of all the geometry to create shape .. though performance sucks so much, that i end up not using minkowski there too
<buZz>
depends how you're using them :D
<dTal>
picking my nose is faster than minkowski() too
<church_>
hull has big drawback - it fills all recesses if object is concave :(
<dTal>
whole point of fillet is that you have 3d blob A connected to 3d blob B and the interface between A and B needs to not be a sharp corner or you create a stress point that cracks
<dTal>
Yeah if A and B are planar then you can probably model it manually somehow but if either of them are a funny shape you're SOL
<church_>
but basic filletting, as i said - either object created from hulled rounded objects at corner, or where i need to carve fillet in object (eg. around bore), i create "negative object" to remove excess, and diff with it
<pca006132>
minkowski uses hull
<church_>
minkowski uses hull? i thought it just somehow internally sweeps around object
<dTal>
church_: a fillet adds material? you can't make a fillet by carving away excess
<dTal>
a round, sure
<pca006132>
it uses hull to implement the sweep thing
<church_>
dTal: + rotate_extrude
<pca006132>
and convex decomposition etc.
<pca006132>
but yeah, minkowski is really expensive
<pca006132>
InPhase: but I thought that with CGAL you can only use 1 core, but with manifold you can utilize all cores, giving you much more heat :P
<church_>
so wherever possible, i create rounded object (eg. cube from 8 hulled spheres), but where need to carve out with diff - create from square & circle carve shape, that i linear_ or rotate_ extrude to bore diameter
<dTal>
I spent a lot of time using OpenSCAD as part of an actual manufacturing pipeline and in the end I ended up writing all the geometry generation myself and just using OpenSCAD for unions and mesh output
<church_>
as you see here, i have lot of filleted surfaces here
<church_>
no minkowski on them
<church_>
eg. around those oval inlets - i diff with linear-extruded circle & square quarter sector difference. or with same difference, but rotate_extrude-d i do round ends of these holes
Smeef has joined #openscad
<church_>
problems come when parts of different concave radiuses meet and it's not that simple to compute needed object to fillet. or when some part is not simple straight or round, but constructed by trig functions segment by segment
<church_>
then it's everything but simple to fillet together
<InPhase>
church_: That looks like a fairly complicated shape to define in any system. It sure has a lot of nuanced features.
Guest51 has joined #openscad
Guest51 has quit [Client Quit]
mmu_man has joined #openscad
kintel has joined #openscad
<kintel>
InPhase Re. Heisenbug: Yeah, I suspect we found a bug in Clipper where lots of degenerate/self-touching/self-intersecting small polygons eventually cause it to roll over and die
<kintel>
..so if we manage to find a smallish example triggering the issue, that would help a lot for upstream reporting.
<kintel>
I would probably have to 1. reproduce it, 2. dump the raw data as C arrays, 3. write a clipper test case, 4. slim it down to its minimal reproducible case and then try to convince the upstream that this is worth fixing. Will take a while..
<kintel>
In terms of ascii stl export: I seem to remember there was some discussion and possible changes related to that recently
<guso78k>
kintel, my functions, which ended up in CGALRenderUtils are not for rendering only and not for CGAL only. they are versatile constuction functions. maybe append them to linalg.cc ?
<church_>
guso: those function faces?
<kintel>
guso78k yeah, I guess those functions are currently only used by the measurement tools, so they started out in CGALRenderer.
<church_>
InPhase: was just an illustration to filletting w/o minkowski to dTal
<kintel>
I'm working on pulling out all the PolySet/Polygon2d rendering code into a separate renderer. Refactoring the measurement tools should become part of that cleanup
<guso78k>
kintel yes, but i use them for constucting everywhere else, they just also fit well to measuring ...
<kintel>
Just calculateLinePointDistance() and calculateLineLineDistance(), or did you want to pull out more internal functions into a header file as well?
<guso78k>
BTW measuring. sometime highlight edges are way too thick. but this is due to my inability to do "good" opengl.
<guso78k>
thehighlight edge is basically a long thin rectangle directly facing the eye
<kintel>
Good OpenGL is hard, we really need an abstraction for drawing annotations
<guso78k>
AND: I got an idea to greatly improve the measuring and annotation performance everytime the user changes the viewing rot+trans, we could apply the transormation matrix onto the vertices and store them in a quad-tree. having that if will be way faster to hover and select points. but its indeed duplication of data
<kintel>
That could be a good optimization. I do think that usability is more important right now though, it seems the measurement feature can be a bit hard/unintuitive to use right now
<church_>
BTW: does idea of producing multiple referenceable objects from difference or intersection ops sounds stupid?
<kintel>
church_ Not sure I understand what you want to achieve..
<church_>
for example usage case - do common changes to parts to common single object. Then by difference get .. two objects. Each, that can be separately used/modified later on?
<church_>
or by intersection..
<guso78k>
yes for sure, my strength is functional programming, not intuitive or beautiful programming though ...
guso78k has quit [Quit: Client closed]
<pca006132>
I think this can be done with the geometry as data pr
guso78k has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
J25k70 has quit [Quit: Client closed]
J25k70 has joined #openscad
guso78k has quit [Quit: Client closed]
stealth_ has joined #openscad
J25k70 has quit [Quit: Client closed]
J25k70 has joined #openscad
stealth_ has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 272 seconds]
stealth_ has joined #openscad
stealth_ has quit [Remote host closed the connection]
stealth_ has joined #openscad
lastrodamo has quit [Quit: Leaving]
stealth_ has quit [Remote host closed the connection]
stealth_ has joined #openscad
dostoyevsky2 has quit [Quit: leaving]
dostoyevsky2 has joined #openscad
misterfish has quit [Ping timeout: 276 seconds]
SharpHammer has joined #openscad
mmu_man has joined #openscad
mmu_man has quit [Ping timeout: 268 seconds]
pah is now known as pa
mmu_man has joined #openscad
<gbruno>
[github] damienmarchal synchronize pull request #5630 ([UX] Add of the "Jump to..." navigation method and clean the "Window" menu of its duplicated elements) https://github.com/openscad/openscad/pull/5630
GNUmoon has quit [Remote host closed the connection]
lastrodamo has joined #openscad
<gbruno>
[github] damienmarchal synchronize pull request #5630 ([UX] Add of the "Jump to..." navigation method and clean the "Window" menu of its duplicated elements) https://github.com/openscad/openscad/pull/5630
<teepee>
guso78: did we keep cryptopp? i seem to remember we tried something different?
<guso78k>
can we change to nettle ?
<teepee>
yep, that was the one, just found it again
<guso78k>
(wanted to keep pr size minimalistic , so this change is not included)
<teepee>
I think that one makes sense to include as it would create another round of build issues
<teepee>
right now the cryptopp is not used in any of the official build
<teepee>
getting those updated just to switch to nettle later is probably not a good idea
Guest46 has joined #openscad
<guso78k>
nettle works better in my machine, but it has some issues in some of the ci's
<teepee>
I just checked again and nettle looks good, it's alive (commits from this year), it's available on debian, mxe and brew, so that seems good
<guso78k>
will integrate nettle in addition
<teepee>
cool, lets make small steps, to get this going finally
<teepee>
I'm still not great with spare time but if we can keep the PRs small, I'll try to keep up
<teepee>
also probably linux only first
<Guest46>
complete newby here. Is this software suitable to construct room plans. Like a room with 4 walls, a window, a door and some furniture. There should be a indication in what direction the door opens
<teepee>
I'd say not ideal, but people have used it for that
<Guest46>
i don't need fancy elements. mostly wall mounted boxes and 19 inch racks
<teepee>
I assume there will be challanges as OpenSCAD always handles closed polygons, so it's not possible to draw lines for example
<teepee>
but it's pizza time now :)
<Guest46>
enjoy the pizza and thank's for the input
<guso78k>
yep, i remember the issues with Nettle and CI, i could never proceed
Guest68 has joined #openscad
<Guest68>
Hi guys, do you know how can I make fillets for joints like this https://nopaste.net/etTc9CMssD I tried minkowsky approach but it's not viable due to slowness
L29Ah has left #openscad [#openscad]
<teepee>
huh, and as always, I've put waaaay to much stuff on it. well, we'll see how it looks in 20 minutes :)
<teepee>
Guest68: if possible, try the dev snapshot version, it has a much faster geometry calculation, maybe that already helps
<Guest68>
Interesting, I will try, thanks!
<teepee>
hmm, where is that generic fillet.scad
<teepee>
argh, how to find a 10 year old script :)
<guso78k>
how did you tell the script, which edges to fillet ?
<Guest68>
I tried it on OpenSCAD from git it took 5 minutes to render fillet and fillet was nice looking, I think that's acceptable for me I can use union instead of fillet and then only during final rendering replace with fillets
<teepee>
Guest68: also enable the manifold backend in preferences
<Guest68>
Oh I was rendering on old CGAL backend, now switched to mainfold :$
<Guest68>
WARNING: [manifold] Minkowski hard-crashed, falling back to Nef operation.
<teepee>
well, that was some time ago with manifold much more experimental
<Guest68>
it took the same 5 minutes, don't know what this warning means, but maybe it falls back to old rendering, I will try very latest now (actually I built on arch linux from AUR which has snapshot from 2024)
<teepee>
yeah, likely that warning means that happens
<teepee>
guso78: why is it not disabling python on apple?
<teepee>
when not finding nettle
lastrodamo has quit [Quit: Leaving]
<Guest68>
WOW! I built from git master, no more warning, and manifold changed rendering time from 5 minutes to 5 seconds!
<teepee>
yes, manifold does that :)
guso78k has joined #openscad
<guso78k>
I think the new code did not turn active. I think you relate to python used for image_compare.py
<teepee>
no, let me see if I can get a direct link