<OlivierChafik[m]>
teepee: oh, a chapter about openscad 🤗
<OlivierChafik[m]>
> Skipping remeshing of patch with 364 faces as it seems to have holes.
<OlivierChafik[m]>
These are not real 3d holes, just 2d holes on the face. I have ideas on how to slice patches to avoid sending a hole to CGAL to triangulate but didn't take the time to implement this yet. In the meantime it safely skips these patches
<OlivierChafik[m]>
> one case of ERROR: [fast-csg-remesh] Failed to collect path around patch faces, invalid mesh!
<OlivierChafik[m]>
This one I haven't got to the bottom of it yet, I make it fail the remesh completely, which is a shame but is safe.
<OlivierChafik[m]>
> slightly longer time needed
<OlivierChafik[m]>
I've already identified some ways I can speed the algo further (do less coplanar tests), testing it now.
<OlivierChafik[m]>
(but it's probably gonna be slower in general, still, except for the complex cases in which it brings exponentially slower models back in check)
ur5us has quit [Ping timeout: 240 seconds]
<OlivierChafik[m]>
J2222: I don't understand yet how it's all interplaying, but I would expect rands to affect things up to the csg tree generation, *then* fast-csg wouldn't have behaved differently than normal rendering
<M6piz7wk[m]>
is there something like OpenSCAD, but for PCB development?
<M6piz7wk[m]>
Like functional Electronic Computer Aided Development?
<buZz>
M6piz7wk[m]: kicad uses openscad for 3d renders, i think :P
<J22>
hmm customizer doesn't like ranges a=[0:1:2];
Junxter has joined #openscad
ccox_ has joined #openscad
<peepsalot>
ranges go in comments to tell the range of acceptable values. how would you expect an interface to look like for editing a range directly?
ccox has quit [Ping timeout: 240 seconds]
<peepsalot>
J22: anyways, just build a range from vector components if you really want a = [0,1,2]; r = [a[0]:a[1]:a[2]];
<J22>
the interface should treat them like vector as echo (range) = [ 0:1:2];
<J22>
and yes i just put the range as vector for the customizer to work
<J22>
a nice way to display a range could be a dual slider with start ,advance and end value
<peepsalot>
no idea what that means. how does "dual" map to 3 values?
<J22>
You have the "from" slider on that bar and the "to" slider. The advance (range[1]) value give the granularity to move the sliders (yes you can not change this via the customizer or would require a second slider for this)
<peepsalot>
J22: also, any use of a slider implies that there are already limits to your range values, then how would those be specified in a comment?
<J22>
via a range range=[10:20];// [0:1:30]
<J22>
same like single value .. just to get a second slider on that bar for ranges
<peepsalot>
this concept has so many flaws I'm tired of thinking about it
<J22>
using two ranges as comment to differentiate from and to value range seems to be too confusing - if someone needs this he need to spit into several values
<J22>
what flaws?
<J22>
i could use two values for that at the moment - so you just need to put two slider together
<OlivierChafik[m]>
J22: thanks for filing the bug!
<J22>
u're welcome
ur5us has joined #openscad
<J22>
when giving a seed (i) (or use any rands with seed anywhere ) it will render fine - interestingly you don't need to use F5 first in every case but only for some
<OlivierChafik[m]>
That file also crashes my local Release build in a way that I'm struggling to repro with Debug & RelWithDebugInfo builds :'-( (also not sure if it's because of other local changes)
<OlivierChafik[m]>
lots of debugging fun ahead :-D
<J22>
with seed i got onetime a very large multiple lines warning - but rendered - when i tried again but with preview no warnings (maybe something was in cache )
<J22>
i also had one where SCAD crashed and closed .. but these are very rare cases
<J22>
have fun Ü
arebil has joined #openscad
GNUmoon has quit [Ping timeout: 240 seconds]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
TheAssass1n has joined #openscad
TheAssassin has quit [Ping timeout: 240 seconds]
GNUmoon has joined #openscad
TheAssass1n is now known as TheAssassin
lastrodamo has quit [Quit: Leaving]
<OlivierChafik[m]>
teepee: I'm hitting the debug/release differences of corefinement with my remeshing stl test cases :-(. I end up doing different remeshes (e.g. same square patch with two different sets of triangles), just because the input meshes have vertices in different orders. Maybe also different on different platforms / different CGAL versions.
<OlivierChafik[m]>
(the good part is it's with simple enough models that I can file bugs to cgal :-D )
<teepee>
:(
<teepee>
that's annoying. maybe we need to find a way for better comparison
<teepee>
the image tests also allow for some limited fuzzy compare
<OlivierChafik[m]>
I'd just need to print the # of faces in some echo
<OlivierChafik[m]>
J22: I've seen one crash that happened in the Nef, way after corefinement. Somehow I'm getting unclosed meshes down the line, haven't pinpointed the issue yet
<InPhase>
Wasn't there a discussion earlier about sorting the triangles? Is that not happening?
<OlivierChafik[m]>
Sorting is of now use if the meshing is different :-(
<InPhase>
I suppose some tests might have slight sorting instabilities.
<OlivierChafik[m]>
I could sort it before remeshing it but that would be costly and only for the purpose of diffable tests
<InPhase>
Nah, that should be an output thing if anything.
<OlivierChafik[m]>
I could also make the remeshing predictible (on the fly sorting) but it's gonna be slower for sure
<InPhase>
Or maybe we just need a Python-based stl differ that checks for what we really consider to be "different".
<InPhase>
Ideally it would even ignore small floating point errors.
<OlivierChafik[m]>
given how debug/release is messing up some models (e.g. repairs on GEB work in Debug and not Release) I'll focus on reporting these discrepancies as bug to cgal, maybe there's something obvious to fix there
<InPhase>
They will want small testcases. They are allergic to outside programs. :)
aiyion has quit [Ping timeout: 240 seconds]
<OlivierChafik[m]>
I have one with two cubes :-D
teepee has quit [Ping timeout: 240 seconds]
teepee_ has joined #openscad
teepee_ is now known as teepee
<InPhase>
That should do it.
<OlivierChafik[m]>
just need to figure the exact sets of compilation flags
<OlivierChafik[m]>
(the bottom faces are meshed differently, no stl sort can fix that :-( )
aiyion has joined #openscad
<InPhase>
Oh.
<InPhase>
Well yeah, that's weird.
<InPhase>
Clearly they are mathematically equivalent, but consistency sure would be convenient.
<OlivierChafik[m]>
it all depends on which face I start from first, and on the order of halfedges around a vertex, etc. If the input mesh has slight differences in order it's all gonna be impacted.
<OlivierChafik[m]>
but I wouldn't expect a different order in release vs debug anyway
<InPhase>
Are those oriented at right angles and integer sizes?
<OlivierChafik[m]>
not sure what you mean? (This is an orthographic projection)
<OlivierChafik[m]>
yes actually
<InPhase>
I mean the numerical values for the vertices.
<InPhase>
That would guard against floating point issues with the most straightforward edge length minimization algorithm.
<OlivierChafik[m]>
I've looked into normalizing -0 vs +0 but it's not in play here
<OlivierChafik[m]>
cube(1);
<OlivierChafik[m]>
cube(1);
<OlivierChafik[m]>
translate([0.5, 0, 0])
<InPhase>
And if that is translate by 1 does it still happen?
<InPhase>
(Instead of 0.5)
<OlivierChafik[m]>
hah, that's risky territory with shared edges, which corefinement sometimes explodes on, lemme try
<InPhase>
Oh. I don't want that then.
<InPhase>
I'm just trying to get it to be the integer. :)
<InPhase>
So not vertices of 0.5 1.5, but 2,3 perhaps
<OlivierChafik[m]>
could it explain different debug/release behaviour?
<InPhase>
Maybe.
<InPhase>
It depends what flags and what operations they're actually doing to determine which one to slice across.
<OlivierChafik[m]>
> So not vertices of 0.5 1.5, but 2,3 perhaps
<OlivierChafik[m]>
hehe give me the model and I'll try. Just with `cube(1); translate([1, 0, 0]) cube(1);` it gives th esame output, it didn't have to create new vertices so that probably helped
<InPhase>
Yeah, then try translate([2
<InPhase>
If translating by an integer differs from a float, then you have release-only floating point optimization instability. That might end up a won't-fix, but at least you'd understand it.
<OlivierChafik[m]>
that doesn't corefine anything, no diffs
<OlivierChafik[m]>
interesting!
<InPhase>
Do you need it overlapping?
<InPhase>
cube of 3, offset by 1?
<OlivierChafik[m]>
I would have hoped this doesn't impact the exact gmp numbers we use in the geometric operations tho
<OlivierChafik[m]>
yes that diffs
<InPhase>
Maybe show the whole model you're using. At this point I've lost the mental mapping between your code and the image. :)
<peepsalot>
OlivierChafik[m]: I wouldn't think -0 vs +0 floats would make a difference in any situation. they are literally equivalent are they not?
<OlivierChafik[m]>
initially I thought it could mess up the stl sorting (if, say, -0 < +0 ?) but that was a red herring
<InPhase>
Not on x86.
<OlivierChafik[m]>
good to know
<InPhase>
There are rumored architectures with that problem, but I'm not sure if any are still around.
<OlivierChafik[m]>
this is `cube(1); translate([0.5, 0, 0]) cube(1);` without remeshing. Its mesh comes in a different order in release than debug https://pasteboard.co/LgYIKjkXx71s.png
<peepsalot>
i wonder if PMP does its own sorting in some way, which uses an unstable sort algorithm, and the unstable behavior optimizes differently?
<peepsalot>
OlivierChafik[m]: have you noticed many cases where the PMP code generates meshes with T-junctions? (non matching half-edges)
<OlivierChafik[m]>
I haven't. My remeshing code was generating such T junctions until recently (realized I had to introduce a check that patches on both sides needed to agree on which vertices to collapse)
<OlivierChafik[m]>
but that would definitely count as unclosed meshes
<peepsalot>
well i was curious how it handled a bit of rotation, and it doesn't look so good https://bpa.st/P3WA
<OlivierChafik[m]>
peepsalot: oh! nasty non-exact transforms... I could introduce non exact coplanarity tests, but will have to fine-tune the threshold