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?