<JakeSays>
i don't notice any difference between the two options
<teepee>
no save at cancel
<ali1234>
i noticed that manifold creates non-manifold geometry on a lot of my stuff. slicer always fixes it though.
<ali1234>
cgal exports never had this problem
<InPhase>
ali1234: Well if you have examples that do this on the latest nightlies, those would be helpful issues to open. Especially if you can get it on simple stuff. But either way, a regression is something to post.
<InPhase>
I haven't seen a manifold failure in a while. But different people attempt different types of things.
<teepee>
also use 3mf, ideally with lib3mf-v2 (unfortunately not all builds have that yet)
<ali1234>
i use stl
<ali1234>
and nothing i make is ever simple by the time i export it :(
<teepee>
3mf can keep geometry intact, 3mf-v2 can additionally increase stored precision
<teepee>
stl will never work perfectly except for most trivial cases
<teepee>
it's mostly ok when squinting a bit
J25k47 has quit [Quit: Client closed]
J25k47 has joined #openscad
joso has joined #openscad
J25k72 has joined #openscad
J25k47 has quit [Ping timeout: 240 seconds]
<JakeSays>
teepee: what do you mean by "stl will never work perfectly"?
<teepee>
it does not strore geometry, it stores a list of triangles
<JakeSays>
teepee: so does that mean 3mf would be better for things like 3d printing?
<JakeSays>
would a slicer produce better results?
<teepee>
better results, no
<teepee>
less risk of "model needed repair" causing strange slicing results
<JakeSays>
ah okay
<JakeSays>
so under what circumstances should i see the perf benefits of using manifold over cgal?
<teepee>
also 3mf can store additional info like colors and multiple objects
<JakeSays>
storing colors could be useful for specifying filaments if a slicer supported it
<teepee>
I would guess manifold is better in all cases where the model is more complex than a cube ;-)
<JakeSays>
teepee: for previewing, right?
<teepee>
unfortunately slicers don't use colors for that, but the multiple objects work. you still need to assign extruders separately
<teepee>
also 3mf can define modifier meshes, which I want to try next when I get some time
<teepee>
no preview (F5) is independent of manifold and cgal (unless you use minkowski or resize which can't do "real" preview)
<JakeSays>
ah okay
<JakeSays>
explains why i'm not seeing a difference. lol
<JakeSays>
so has there been any more movement in supporting render() as a function? i used a build that supported it in some of my designs. it was very handy.
<JakeSays>
things like this is very helpful: dataInnerRing = render() { circle(r=ledInnerRingRadius, $fn=innerRingLedCount); };
<teepee>
no, that stuff needs some love to get going again
<teepee>
and I need some sleep :-)
<JakeSays>
then i would use dataInnerRing.points to position things around the ring
<JakeSays>
ub.scad is one of my favorite libs, but it can be difficult to use
<ali1234>
does stl realy just store a list of triangles, or does it actually store a list of points and then a list of triangles referring to those points?
<ali1234>
in which case i dont see why it would have a problem representing any closed object
<JakeSays>
isn't the end result the same?
<ali1234>
no
<JakeSays>
triangles made up of points should be equal to triangles made up of point references
<ali1234>
in the latter, connected triangles are unambiguous
<ali1234>
because two triangles can share a pair of points. they are unambiguously connected
<ali1234>
in the former, you have to compare the point values
<ali1234>
then you run into problems with float accuracy
<ali1234>
and you can't really know if the triangles are supposed to be connected or not
<ali1234>
they might just be equal by accident, which is probably what is happening
<JakeSays>
the same would hold with point references as well - two triangles could be equal just by accident
<ali1234>
if they are not connected, they will not share the same point references. they will refer to different points with the same positions
<JakeSays>
i see point references as not much more than a space optimization
<JakeSays>
not necessarily
<ali1234>
well yes, you could have a bug in your exporter
<ali1234>
that's the only way though
<JakeSays>
do you know that stl is designed to work that way?
<ali1234>
no
<ali1234>
hence why i asked
<JakeSays>
then a bug is not the only way
<ali1234>
okay i checked wikipedia and it is true - stl doesn't do this. it stores a flat list of triangles, repeating all vertices
<ali1234>
so you can never disambiguate it
<ali1234>
that really sucks. i guess i will stop using it
<ali1234>
if i untick that box that says "always show dialog" on the 3mf exporter, how do i get it back?
<ali1234>
oh, there is a setting for it in preferences. but it doesn't work
<ali1234>
you have to go into preferences, untick it, and then tick it again, then it shows
<JakeSays>
ali1234: which slicer do you use?
<ali1234>
superslicer
<JakeSays>
hmm. not heard of that one
<ali1234>
it is prusasplicer with experimental features
<JakeSays>
ah
<gbruno>
[github] ali1234 opened issue #5687 (Preference "Always show 3mf exporter dialog" doesn't update when you disable the dialog from its own window) https://github.com/openscad/openscad/issues/5687
<gbruno>
[github] ali1234 edited issue #5687 (Preference "Always show 3mf exporter dialog" doesn't update when you disable the dialog from its own window) https://github.com/openscad/openscad/issues/5687
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
stealth_ has quit [Quit: Leaving]
SamantazFox has quit [Ping timeout: 244 seconds]
misterfish has joined #openscad
SamantazFox has joined #openscad
<teepee>
ali1234: you can also press SHIFT when exporting, that will force the dialog
teepee_ has joined #openscad
teepee has quit [Ping timeout: 264 seconds]
teepee_ is now known as teepee
mmu_man has joined #openscad
guerd has quit [Read error: Connection reset by peer]
J25k72 has quit [Quit: Client closed]
J25k72 has joined #openscad
Guest5 has joined #openscad
<Guest5>
Hi, is it ok to just ask questions here, or is there some sort of initiation process :?
<feep>
it is basically always okay to ask questions
<feep>
except that question, never ask that question lol
<feep>
the thing is that irc is pretty asynchronous, you basically have to wait for somebody to see your question and reply, so asking "can I ask questions" just delays the entire process for hours to potentially days
<feep>
thus the general irc rule says "ask, don't ask to ask"
<feep>
so don't worry about it
<InPhase>
Also don't ask, "Is anyone familiar with [BLAH]?" or "Can anyone help me with [BLAH]?" for the same reason. ;)
<Guest5>
I have a problem with zero height object rendering. I'm importing an SVG with this: `import(file = "/Models/Ring Clamps/circle.svg", center = true, dpi = 72);` . When I click render the result looks like it has no height. When I try and export the STL I'm told "import(file = "/Users/hutch/Mere Development/Projects/3D Printing/Models/Ring
<Guest5>
Clamps/circle.svg", center = true, dpi = 72);"
<buZz>
2D objects indeed have no height
<buZz>
the F5 render adds a linear_extrude(1) before it, i think, the F6 render does not
<Guest5>
Amazing... thank you!
<buZz>
yw :)
Guest5 has quit [Quit: Client closed]
misterfish has quit [Ping timeout: 244 seconds]
misterfish has joined #openscad
lastrodamo has joined #openscad
J25k72 has quit [Quit: Client closed]
J25k72 has joined #openscad
hisacro has quit [Ping timeout: 260 seconds]
misterfish has quit [Ping timeout: 244 seconds]
hisacro has joined #openscad
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #openscad
arebil has joined #openscad
Guest55 has joined #openscad
kintel has joined #openscad
<kintel>
Preview renders objects 1 unit thick. This is just because the preview algorithm requires objects to have a volume. It might be possible to fix, but it hasn't been important enough :)
<ali1234>
it looks like it projects the shape down to 1d in each dimension, and then minkowskis all the results?
<ali1234>
but i'm having a hard time visualiing this
<ali1234>
i mean i can see how it would work in theory, but openscad doesn't support minkowski on 1d or 2d shapes to product a 3d result
misterfish has joined #openscad
<ali1234>
it also seems like it would be incredibly slow
mmu_man has quit [Ping timeout: 244 seconds]
mmu_man has joined #openscad
stealth_ has joined #openscad
snaked has joined #openscad
misterfish has quit [Ping timeout: 252 seconds]
L29Ah has left #openscad [#openscad]
LordOfBikes has quit [Ping timeout: 252 seconds]
L29Ah has joined #openscad
LordOfBikes has joined #openscad
teepee_ has joined #openscad
mmu_man has quit [Ping timeout: 272 seconds]
teepee has quit [Ping timeout: 264 seconds]
teepee_ is now known as teepee
mmu_man has joined #openscad
<InPhase>
ali1234: I can't promise you this is optimal, but I have this bounding box code I whipped up laying around in my files from some time ago: https://bpa.st/3K2A
<ali1234>
how does it work tho?
<ali1234>
this seems similar to the minkowski approach, except that it requires you to know how big the object is in advance, in which case you might as well just make a cube with the size
<ali1234>
obviously none of these are optimal: optimal would be just walking the csg tree and finding the maximal extents, and then creating a cube of that size
<ali1234>
i think this is approximately what bosl2 does: https://bpa.st/PE4Q
<ali1234>
however this results in a bounding box that is 0.2 bigger than the object in each dimension
<ali1234>
0.02 sorry. it depends what size you make the extrusions
<ali1234>
and despite theoretically being larger, the object still seems to fall outside it
<ali1234>
and you have to tweak the size depending on the size of the object, otherwise it fails to float precision
<ali1234>
however if you just want a bounding box that is x larger in every dimension then this is fine
<InPhase>
ali1234: It doesn't require knowing the size. I use a maxval parameter and intersections. So as long as the object is smaller than 1000 units, it works.
<ali1234>
so you have to know the size is less than 1000
<ali1234>
which means you have to know this size
<ali1234>
my implementation just crashed openscad, lol
<ali1234>
this really, really should be a built-in, like hull
<InPhase>
Well you can pick a very big number. :)
<ali1234>
it can't possibly be harder to implement than hull
Guest55 has joined #openscad
<ali1234>
picking very big numbers like this never ends well. it's the same as my version needing a very small number... but it fails if the number is too small in relation to the object
<InPhase>
ali1234: For user-level, it works really well.
<InPhase>
And for most practical purposes, works very well. There would be rare edge cases of failing.
<ali1234>
so mine doesn't actually crash openscad, it just takes a really long time to render
J25k38 has joined #openscad
<ali1234>
i thought manifold was supposed to be multithreaded?
J25k72 has quit [Ping timeout: 240 seconds]
<ali1234>
hmm okay your implementation also takes unreasonably long time to preview/render
<InPhase>
It goes in a split second for me.
<ali1234>
on your example object, sure
<ali1234>
on an imported stl it still hasn't finished
<InPhase>
With manifold?
<ali1234>
yes
<InPhase>
Projection should not be too expensive.
<InPhase>
It's like instantaneous almost.
<ali1234>
this is just the preview
<InPhase>
Well that can be more involved.
<InPhase>
Actually throwing in some render() operations might speed up preview.
<InPhase>
If they're put in the middle at the right parts.
<ali1234>
shouldn't the cache take care of that?
<InPhase>
Not on preview.
<InPhase>
render will force things into manifold, and remove some of the slowness of intersection for preview.
<ali1234>
i wonder who's is actually faster. can you make a preview on command line and save to image?
<kintel>
Actually, now that we have color support in render, we could, technically, start looking into caching some rendered subtrees and use those for preview. Especially if we could also cache the VBOs in question
<InPhase>
Also, somewhere I have a script to extract bounding box information from ascii stl files.
<gbruno>
[github] ali1234 edited issue #5687 (Preference "Always show 3mf exporter dialog" doesn't update when you disable the dialog from its own window) https://github.com/openscad/openscad/issues/5687
<kintel>
ali1234 If you have some suspiciously slow STL, feel free to drop it somewhere, just in case you hit some weird corner case
<ali1234>
^ just realised i am using an appimage, not a snap
<ali1234>
no other changes
<InPhase>
ali1234: There it is! Found it. 2017 perl script: https://bpa.st/W5AQ
<ali1234>
okay but making a bounding box should be trivial for any input
<InPhase>
That is why it is a short perl script. ;)
<InPhase>
Bounding boxes would be a natural feature to go along with the data = render() PR.
<InPhase>
Should we ever get that integrated.
<InPhase>
I think having a data = render() feature has gotten much more attractive since manifold.
<kintel>
--render=force will force your objects into the chosen renderer backend. Otherwise it may render trivial objects (STL import, primitives) directly from your data source
<kintel>
The latter is good for validating that your object can be converted to and represented by the backend. Good for catching non-manifold issues early and without performing dummy CSG ops
<ali1234>
i will upload all of this when i've checked it is actually doing what i think it is doing
<kintel>
--preview=throwntogether will, obviously, render the preview in throwntogether mode rather than regular preview mode
<ali1234>
what if i just want regular preview mode?
<ali1234>
no argument?
<ali1234>
and what does thrown together actually mean?
<kintel>
it just renders all objects as positive objects instead of trying to do a proper preview. Mostly for sanity checking/debugging
<ali1234>
hmm i need to put the mode and backend in the image output name, otherwise it's going to overwrite it every time
<kintel>
(same as Throwntogether in the GUI :) )
<ali1234>
i never understood what it does in the gui
<ali1234>
throwntogether previews mine in 3 seconds, and segfaults with inphase's implementation
<ali1234>
but --preview with no argument does the same
<ali1234>
but previewing it in the gui ... well it still hasn't finished
<kintel>
Any segfault deserves a GitHub ticket
<kintel>
There has been some deep rendering refactoring lately, so I can take the blame for that, just need a reproducible test
<ali1234>
hmm... i hope this isn't my ram playing up
<ali1234>
it's not segfaulting this run, just sitting at 100% CPU
<ali1234>
oh wait i changed the test order
<InPhase>
kintel: That's probably out of memory.
<InPhase>
Which will look like a segfault at user level if you're not monitoring RAM, but there will be an OOM-killer entry in the syslog.
<ali1234>
well... i have 192GB
<InPhase>
That sounds like an adequate amount of RAM for modest tasks. ;)
<ali1234>
no OOM killer in the logs but i have this: [1930119.847366] AppRun.wrapped[329559]: segfault at 335c70a1 ip 000061ce56806079 sp 00007fff63f57a70 error 4 in openscad[821079,61ce5607c000+8d3000] likely on CPU 29 (core 13, socket 0)
plasma41 has left #openscad [#openscad]
<ali1234>
i could be that my ram timings are too aggressive and i'm getting rare memory errors
<ali1234>
unfortunately that's a thing on ryzen
<InPhase>
ali1234: Is the stl file you're using posted somewhere?
<ali1234>
when i've got this working to my satisfaction i will upload the whole test dir
<ali1234>
the "big" i am testing with is STL is 16MB
<ali1234>
the "small" is like 1MB and seems to work okay
<InPhase>
I was just going to give the stl file a whir to see what this is like. I didn't really imagine it going as slow as what you're describing, but maybe the stl file is wild somehow.
<ali1234>
the stl is output from another openscad thing
<InPhase>
Just pointing the x toward the y with a rotate, and it explodes.
<ali1234>
my implementation takes 3 seconds with manifold, or forever with cgal
<ali1234>
re-running tests with a timeout now
<ali1234>
i can't reproduce that segfault though :(
<InPhase>
ali1234: Okay... Get this. XZExtent(100) rotate([0,0,90]) is very very slow. XZExtent(100) rotate([0,0,90.1]) is super fast.
<InPhase>
This has nothing to do with the bounding box. Instead this is something to do with points aligning weirdly, somehow.
<ali1234>
i mean, that's not surprising
<InPhase>
Well it's a little surprising.
<ali1234>
that's always what the problem is, lol
<InPhase>
Well okay, not surprising in that sense. ;)
<InPhase>
But if we ignore all the lessons learned that made me put that test in there...
<InPhase>
It's surprising that manifold is having difficulty like this.
<InPhase>
I assume manifold, because I put a bunch of render()'s in there.
<InPhase>
ali1234: BoundingBox() rotate([0,0,0.001]) ExampleObject(); This works in 0.8 seconds for me now.
<InPhase>
0.2 for render.
<InPhase>
But I'm concerned there's a bug behind this.
<InPhase>
I really didn't think that projection/extrude approach should be slow. I literally did it that way precisely because I expected it to always be fast.
<ali1234>
on other STLs, projection/minkowski seems about twice as fast
<ali1234>
but it doesn't make perfect sized boxes
<ali1234>
so maybe its just faster because i didn't account for that
<ali1234>
but that was my original question: how do you account for that?
<InPhase>
Account for what?
<ali1234>
welli still don't exactly understand how your implementation works
Murr has quit [Ping timeout: 245 seconds]
<ali1234>
nor the one from bosl
<ali1234>
i understand how mine works, but it is incomplete
<InPhase>
Well you can render the intermediate parts of mine.
<ali1234>
that... doesn't help me understand it
<InPhase>
They're all displayable modules.
<InPhase>
It just does projection and then linear extend in both directions for all 3 axes.
Murr has joined #openscad
Murr has quit [Changing host]
Murr has joined #openscad
<ali1234>
two projections right?
<InPhase>
Oh, well, little extra complication in there.
<ali1234>
so you end up with a line on the axis
<ali1234>
how do you get a rectangle from that?
<InPhase>
I did some funky rotate thing to make it a filled in box.
<ali1234>
mine does two projections and two extrudes to get a box that has the extent of the object along the axis, and it is "extra" in the other two dimensions
J25k38 has quit [Quit: Client closed]
<ali1234>
it does this for all three dimensions then minkoskis them all to get the actual bounding box, plus "extra"
<InPhase>
So the whole thing centers around XDimensionBound.
<InPhase>
It's just that, repeated.
J25k38 has joined #openscad
<ali1234>
but extra cannot be zero because that results in 1d objects
<ali1234>
mine needs 6 projections in total
mmu_man has quit [Ping timeout: 244 seconds]
<ali1234>
yours appears to do... 6 * 2 * 4?
<ali1234>
and i can see it results in 3 large boxes that all get intersected
<InPhase>
So it just does a z-projection, then extrudes, then rotates on x, projects again, and linear extrudes forward backward in y, then does projection, giving a 2D object. Because linear extrude upward makes everything equal z-height, the y-projection after the first extrude will always be a rectangle. That's the secret to making it a rectangle.
<ali1234>
ah i see
<ali1234>
so the second step produces maxsize by extent rectangle
<InPhase>
And once you have a 2D rectangle with one bound confined, you just do combinations.
<InPhase>
From there it's intersections all the way down, hitting every axis.
<ali1234>
idk, it seems like you have a lot of unnecessary steps if that's really what you are doing? i'll try to re-implement it this way myself, then i'll properly understand it
<InPhase>
I'm pretty sure this was a hacky first draft proof of concept, so there might be an optimization opportunity. :)
<InPhase>
It was 8 years ago.
<ali1234>
but this still leaves the question of how bosl is doing it, which uses minkowski, but claims to be able to have exact sized bboxes
<InPhase>
Yeah, not sure how to do minkowski for that. I'd have to check what they do later. afk for a bit
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ali1234>
InPhase: i found that hull() on the object also makes it fast
<ali1234>
and i came up with this for intersection approach: https://bpa.st/TJGA
<ali1234>
instead of making each extent object hold two extents, it just puts one in each. much more efficient, and intersection result is the same
<ali1234>
this is slightly faster than minkowski, but can't handle an "extra offset" parameter, and still requires user to know roughly how big the object is (and also where it is)
<ali1234>
like it's not just the size that needs to fit in maxval, it is also the position
J25k38 has quit [Quit: Client closed]
J25k38 has joined #openscad
<ali1234>
this gives a perfect sized bounding box, but having an offset is probably desirable most of the time (like if you're making a negative mould or something)
teepee_ has joined #openscad
<ali1234>
i still can't reproduce that segfault which is probably bad news for my hardware. otoh i still haven't seen it successfully complete a render or preview of your implementation
kintel has joined #openscad
<ali1234>
(with the original problematic STL that is - with the rotate/hull tricks it completes in normal time)
teepee has quit [Ping timeout: 264 seconds]
teepee_ is now known as teepee
<kintel>
Stack trace for the crash says it crashes inside the Clipper2 library
<kintel>
..when trying to union 16K polygons of various sized
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]