teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | Website: http://www.openscad.org/ | FAQ: https://goo.gl/pcT7y3 | Request features / report bugs: https://goo.gl/lj0JRI | Tutorial: https://bit.ly/37P6z0B | Books: https://bit.ly/3xlLcQq | FOSDEM 2020: https://bit.ly/35xZGy6 | Logs: https://bit.ly/32MfbH5
<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
ur5us has joined #openscad
<OlivierChafik[m]> 6piz7wk: could kicad python scripting be the closest thing to what you're looking for? https://docs.kicad.org/6.0/en/pcbnew/pcbnew.html#scripting
<M6piz7wk[m]> <OlivierChafik[m]> "6piz7wk: could kicad python..." <- it would be closer, but i don't want to use python
<M6piz7wk[m]> <buZz> "6piz7wk: kicad uses openscad for..." <- eh? that's just for the models no?
LordOfBikes has quit [Ping timeout: 245 seconds]
<M6piz7wk[m]> also the API is severely outdated and obsolete https://github.com/KiCad/kicad-python
<M6piz7wk[m]> ah nwm just moved
LordOfBikes has joined #openscad
<buZz> ok
ur5us has quit [Ping timeout: 240 seconds]
J222216 has joined #openscad
J2222 has quit [Ping timeout: 256 seconds]
sinned6915 has quit [Ping timeout: 240 seconds]
J222216 is now known as J22
<J22> OlivierChafik[m]  here https://bpa.st/LQ7A  i tried without fast-CSG which worked, but with ends in "mesh not closed" version is 2022.02.18
sinned6915 has joined #openscad
ccox has joined #openscad
ur5us has joined #openscad
ccox_ has quit [Ping timeout: 252 seconds]
<J22> https://bpa.st/MCBQ   same problem but looks nicer - Ü
lastrodamo has joined #openscad
<gbruno> [github] UBaer21 opened issue #4148 (fast-CSG fails without preview data) https://github.com/openscad/openscad/issues/4148
<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
<J22> here with the use of it https://bpa.st/IMMQ
<J22> range=[from:sign(to-from):to];  if  "from" is bigger than "to"
ur5us has quit [Ping timeout: 272 seconds]
ali12341 has joined #openscad
ali1234 has quit [Remote host closed the connection]
<gbruno> [github] threed-factory-store opened issue #4149 (Preview won't show an item that touches a hole(), but render works fine.) https://github.com/openscad/openscad/issues/4149
ferdna has joined #openscad
paddymahoney has quit [Ping timeout: 240 seconds]
Guest76 has joined #openscad
Guest76 has quit [Client Quit]
<gbruno> [github] printerderby opened issue #4150 (Incomplete render with fast-csg-trust-corefinement and fast-csg being set) https://github.com/openscad/openscad/issues/4150
<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
<OlivierChafik[m]> Can you add that one to the thread in https://github.com/openscad/openscad/pull/4117 so I don't forget it later?
epony has quit [Quit: QUIT]
<peepsalot> ok. does the corefinement/remeshing only output triangulated faces?