<kintel>
In the above case, the golden files were created on macOS
J25k22 has joined #openscad
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
J25k26 has quit [Ping timeout: 240 seconds]
Guest71 has joined #openscad
Guest71 has quit [Client Quit]
mtm has quit [Ping timeout: 265 seconds]
mtm has joined #openscad
raydenuni has joined #openscad
little_blossom has joined #openscad
<gbruno>
[github] jordanbrown0 synchronize pull request #5750 (Ranges where start is "after" end (whichever way that is) yield nothing. Fixes #5721.) https://github.com/openscad/openscad/pull/5750
<pca006132>
probably not across platforms and compilers
<pca006132>
we tried but we haven't really tested that, and it is difficult to test with
<pca006132>
but do you have the specific case that we can look into later?
raydenuni has quit [Quit: Client closed]
<pca006132>
oh, and one thing we haven't yet tested is color :P
<pca006132>
or properties
<pca006132>
that may be the issue
<pca006132>
and for face normal computation it is not probably not deterministic across platforms due to the use of trigonometric functions
<pca006132>
we don't want to bundle a high precision acos implementation...
<pca006132>
ah, face normal should be fine, vert normal is the issue... I should probably look into this later
stealth_ has quit [Quit: Leaving]
<cbmuser>
teepee: Ping
<teepee>
moin
J25k22 has quit [Quit: Client closed]
J25k22 has joined #openscad
<cbmuser>
teepee: Can you come to Matrix chat?
VW21 has joined #openscad
VW21 has quit [Client Quit]
VW78 has joined #openscad
ToAruShiroiNeko has quit [Ping timeout: 272 seconds]
ToAruShiroiNeko has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 264 seconds]
teepee_ is now known as teepee
J25k22 has quit [Quit: Client closed]
J25k22 has joined #openscad
snakedGT has quit [Quit: Leaving]
VW78 has quit [Ping timeout: 240 seconds]
L29Ah has joined #openscad
mmu_man has joined #openscad
aiyion4 has quit [Ping timeout: 264 seconds]
<church_>
hmm, what you guys think if it would make sense to add to argumentless builtin functions argument perform=boolean ?
<church_>
as in to perform something like hull/difference/intersection and alikes 1) by default, 2) if perform=true, and treat as union() otherwise?
<church_>
otherwise sometimes to not hull means either argument objects code duplication or imho redundant children or extra module usage
kintel has joined #openscad
<kintel>
pca006132 Face normals is expected to be tricky, I was mostly curious about tessellation and vertex+triangle order
<kintel>
Tessellation is the critical one as everything else can be postprocessed to ensure deterministic output
<kintel>
For testability, cross-platform determinism is necessary, but even ensuring deterministic behavior across multiple runs on the same machine is valuable to some (but we probably won't spend resources validating that behavior)
<kintel>
church_ Are you switching between union and hull in the same design often enough for this to be a pain point? Curious about what kind of designs you're creating..
<church_>
kintel: union was mentioned as "no action performed" except to refer all objects otherwise passed to hull for other transformation commands preceding it
<church_>
with "for" cycle i generate few objects .. some are concave and i DON"T want for hull to mess them up :)
<kintel>
This does sound like a very specific use-case, and it feels like you'd be better off writing your own "MaybeHull" module or smth.
<church_>
so i thought that hull(perform=somecheck?true:false) might be simpler then to rewrite all after as separate module or duplicate in another for cycle
<kintel>
..and if it's too hard to implement MaybeHull, that's an indicator that OpenSCAD should look into improving lower-level tools
aiyion4 has joined #openscad
<kintel>
In the future, we may support modules as first-class objects, in which case you could write a generic perform function: module perform(realmodule) perform ? realmodule() children() : children()
<kintel>
^ + a boolean argument to the perform() module of course, to turn it on/off
<kintel>
gotta got offline for a bit, others may chime in as needed
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<church_>
btw, what is argument against adding "case" ? just because multiple if-s can do/replicate same? but shouldn't more readable code also be of slight value?
Murr has quit [Ping timeout: 268 seconds]
Murr has joined #openscad
Murr has quit [Changing host]
Murr has joined #openscad
Murr has quit [Ping timeout: 252 seconds]
Murr has joined #openscad
Murr has quit [Changing host]
Murr has joined #openscad
Guest70 has joined #openscad
kintel has joined #openscad
<kintel>
church_ a case construct could be valuable; someone just needs to design it :) I haven't thought about it though, so I cannot say off hand what challenges may arise apart from floating point comparison being suboptimal for case statements.
L29Ah has quit [Ping timeout: 248 seconds]
stealth_ has joined #openscad
L29Ah has joined #openscad
gehel has joined #openscad
mmu_man has quit [Ping timeout: 248 seconds]
Sam20 has joined #openscad
Sam20 has quit [Client Quit]
<pca006132>
we should already have run to run deterministic behavior
<pca006132>
at least I don't have test cases to suggest otherwise
<pca006132>
church_: We need argument for adding new features, instead of asking others to give arguments against it. Each LoC is maintenance burden, apart from things like a clean language design.
mtm has quit [Ping timeout: 244 seconds]
mtm has joined #openscad
mmu_man has joined #openscad
VW66 has joined #openscad
<kintel>
pca006132 Gotcha, so to clarify: triangulation may differ across platforms/cpu, but is stable from run to run on the same machine/arch?
fling has joined #openscad
Guest70 has quit [Quit: Client closed]
Joel has quit [Quit: ZNC 1.8.2+deb2ubuntu0.1 - https://znc.in]
Joel has joined #openscad
Joel has quit [Quit: ZNC 1.8.2+deb2ubuntu0.1 - https://znc.in]
killjoy has joined #openscad
killjoy has joined #openscad
killjoy has quit [Changing host]
bertronika has joined #openscad
J25k22 has quit [Quit: Client closed]
J25k22 has joined #openscad
Joel has joined #openscad
mmu_man has quit [Ping timeout: 268 seconds]
Guest88 has joined #openscad
Guest88 has quit [Client Quit]
mmu_man has joined #openscad
fling has quit [Remote host closed the connection]
VW66 has quit [Ping timeout: 240 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 264 seconds]
teepee_ is now known as teepee
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bertronika has quit [Quit: Konversation terminated!]
J25k22 has quit [Quit: Client closed]
J25k22 has joined #openscad
nomike has joined #openscad
<nomike>
Hi
<nomike>
I'm trying to integrate OPenSCAD with PrusaSlicer, but I'm getting "Unknown error". As PrusaSlicer is a flatpak application nowadays, I wanted to simplify the issue and configured `/usr/bin/gnome-text-editor` as local 3d-printing app. But I'm still getting "ERROR: Could not start Slicer '/usr/bin/gnome-text-editor': Unknown error". So it seems to be something else.
<ali1234>
use flatpak-spawn
<teepee>
not needed
<ali1234>
oh, nvm
<nomike>
It doesn't even work with gnome-text-editor. So I can rule out an issue with flatpak. I guess the issue is more likely due to OpenSCAD being a snap...
<teepee>
I'll have a screenshot eventually...
<teepee>
right, I don't know if snap can start external stuff
<teepee>
I suppose there has to be some way of doing that
<teepee>
well, I take that back
<nomike>
I prefer the flatpak version anyway. But that gives me an error during `flatpak install --user flathub-beta org.openscad.OpenSCAD`:
<nomike>
error: The application org.openscad.OpenSCAD/x86_64/beta requires the runtime org.kde.Platform/x86_64/6.8 which was not found
<teepee>
I guess you have to add the normal flathub repo too
<ali1234>
it can't if it is confined, which openscad is
<teepee>
flatpak has more of that portal stuff, it might have some option
<ali1234>
flatpak has flatpak-spawn for this
<ali1234>
snap has... nothing apparently
<teepee>
ah, so if openscad is a flatpak that flatpak-spawn should be available
<ali1234>
yes
<ali1234>
you might have to give it a permission to use it with flatseal, idk, i don't use flatpaks much
<teepee>
nice, I'm starting to like flatpak so much more, it's always a struggle with Snap
<teepee>
confusing docs
<ali1234>
snap is way better when things are classic. they just work
<teepee>
unclear errors
<ali1234>
flatpak doesn't have a classic mode so you always have to make affordances for the container
<ali1234>
all the snaps i use are classic, because they are IDEs
<teepee>
but it seems you at least can do it
<nomike>
8-tack vs. Compact Cassette, VHS vs. Betamax. DVD+r cs. DVD-r, HD-DVD vs. BlueRay, snap vs. FlatPak.... What we need right now is another format war....NOT!
<teepee>
I had to beg for 2 weeks on the snap forum to get access to the XDG dir of the app
<ali1234>
flathub isn't going to accept IDEs going forward just because of how difficult it is to make them work
<ali1234>
unless they're specifically designed and fully patched for the container
<ali1234>
which basically none are, nor ever will be
<teepee>
anyway, nomike if you keep the default /tmp folder, you need to give the prusa flatpack acces to that folder
<ali1234>
manifold is enabled. i've been waiting half an hour already
<teepee>
nomike: do you have dark mode as system default?
<nomike>
Ah....yes. That could be it.
<teepee>
looks like it's picking that up only partially
<nomike>
Yes. Seems to be a bug with dark mode. Should I create an issue on github for that?
kintel has joined #openscad
<teepee>
nope, I have no idea how to fix that
<teepee>
;-)
<teepee>
well, sure, but in the flathub repo, not the main openscad
<kintel>
ali1234 If the STL is concave, it will take time to decompose it into convex subparts. After that it should be reasonably fast. If you share a design I could give it a sanity-check
<ali1234>
kintel: the STL is a 3d scan of a person's head
<ali1234>
the goal is to make a hat that perfectly fits the head
<kintel>
You might be able to subtract a bunch of stuff first, to make the minkowski cheaper. e.g. places where hat wouldn't go.
<ali1234>
yeah, i did that already
<kintel>
..but you might also have run in to a corner case we don't know about : /
<kintel>
If you clip it down to something non-identifiable, you might be able to share it
<ali1234>
oh the head i'm using is just an example it's on thingiverse, i can link it no problem
<teepee>
if it's a very rough surface that could decompose into thousands of separate objects
<ali1234>
problem is, if i trim first, then i don't get an open hat, it has a bottom
<ali1234>
but i guess i can trim it twice
<kintel>
Hmm, I tried an extreme case: Render this and do a minkowksi: difference() { import("v17_head.stl"); translate([0,0,50]) cube(120, center=true); }
<kintel>
Rendering yields 344 triangles, but it gets subdivided into 190 convex parts (!)
Ekho- is now known as Ekho
<ali1234>
trimming unused geometry first didn't seem to help
<kintel>
If you could find a place to strategically hull stuff, that would help
<ali1234>
although i just noticed this model seems to have the entire inside of the mouth modelled
<ali1234>
that probably isn't helping at all
<kintel>
Based on my test, you have big issues way before dealing with the mouth :/
<ali1234>
i decimated it down to 6k verts in blender
<ali1234>
still taking ages
J25k22 has quit [Quit: Client closed]
J25k22 has joined #openscad
<kintel>
Yeah, it's most likely the convex decomposition