teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | https://openscad.org/advent-calendar-2021/ | 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]> (turns out you can ask chrome for a per-domain exemption of that security enforcement, fyi: https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md#valid-until-feedback )
<teepee> you are still running that ancient 2019 version, that certainly has no fast-csg :)
<OlivierChafik[m]> ah yes! I failed to apply the patch to master
<OlivierChafik[m]> did you manage/
<OlivierChafik[m]> ?
<OlivierChafik[m]> So now we can send direct links to model renderings :-D https://tinyurl.com/2zx9bn3f
<teepee> cool
<teepee> manage?
<teepee> you could just drop in the released version :)
<OlivierChafik[m]> teepee: : to build off of HEAD rather than the commit that's pinned in the build scripts
<OlivierChafik[m]> oooh you mean he has downloads? didn't see that
<OlivierChafik[m]> will do now
<teepee> it should not be pinned anymore
<teepee> my PR was merged, so that wasm master branch should build openscad master
<OlivierChafik[m]> hah awesome, putting this hopeful statement to a test rn ✌️
<teepee> it should be enough to just drop the libs/openscad
<teepee> and: make libs/openscad to fetch again
<teepee> that boost git fetch is horrible
<teepee> it really likes to asser that: e_below != SHalfedge_handle()
<OlivierChafik[m]> haha yeah I've been trying to wrap my head around cgal failures for the entire week (made lots of progress with remeshing but on small models... bigger ones still mess things up :-( )
<OlivierChafik[m]> the shalfedge thing should be Nef-only so we'd get different errors with fast-csg+trust
<OlivierChafik[m]> one thing that's made me sad is that I somehow get different corefinement results in Debug than in both Release & RelWithDebugInfo
<OlivierChafik[m]> makes debugging... hard
<OlivierChafik[m]> (debug builds are better at repairing GEB.scad for instance)
<OlivierChafik[m]> I've realized CGAL tests for NDEBUG directly in some places (instead of just relying on CGAL_DEBUG and what it defines), but couldn't find any way to bring release to the same behaviour
<teepee> hmm, that's really annoying
<teepee> slower seems acceptable, different results are bad
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
LordOfBikes has quit [Ping timeout: 240 seconds]
tachoknight has joined #openscad
LordOfBikes has joined #openscad
linext__ has quit [Ping timeout: 240 seconds]
linext has joined #openscad
linext has quit [Ping timeout: 256 seconds]
linext_ has joined #openscad
linext_ has quit [Read error: Connection reset by peer]
linext_ has joined #openscad
<gbruno> [github] jmerc77 opened issue #4130 (Dark mode plz.) https://github.com/openscad/openscad/issues/4130
<peepsalot> OlivierChafik[m]: that sounds like a bug if there are places in code that ignore CGAL_DEBUG
J2277 has joined #openscad
J22 has quit [Ping timeout: 256 seconds]
ferdna has quit [Quit: Leaving]
arebil has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<gbruno> [github] t-paul closed issue #4130 (Dark mode plz.) https://github.com/openscad/openscad/issues/4130
Junxter has joined #openscad
J2277 has quit [Ping timeout: 256 seconds]
J22 has joined #openscad
arebil has joined #openscad
<J22> OlivierChafik[m]  is it possible that fast CSG get problems with nonplanar faces - maybe as i found out that faces constructed by leaving points and so maybe creating  "not closed" meshes?
<J22> maybe a fall back would be good in case fast CSG fails
<J22> if i twist a polyhedron there shouldn't be a difference in direction - but face generation  is working differently https://bpa.st/OATA
<J22> even more disturbing for some fragment number the preview differs from the render
<J22> this is the same Geometry  .. one perview the other half of the composit image is rendered
<OlivierChafik[m]> J22: that model doesn't seem to render without fast-csg (tested w/ last week's dev snapshot), fails with
<OlivierChafik[m]> There actually is a fallback to nefs in case corefinement fails, but sometimes failures happen upstream in the model. In any case, corefinement is more forgiving with unclosed models than Nefs, and maybe less so with self-intersections. I've been experimenting with repairing meshes in case of failures but it's a bit of a messy business haha
<OlivierChafik[m]> ERROR: The given mesh is not closed! Unable to convert to CGAL_Nef_Polyhedron.
<OlivierChafik[m]> > sometimes failures happen upstream in the model
<OlivierChafik[m]> What I mean by that is sometimes an existing topological issue is exacerbated differently with fast-csg than with nefs in intermediate operands and the final operation can no longer proceed, whether with corefinement or nef.
<J22> I assume these issue have to do with  auto face generations if  4 instead of 3 points for a face are given
<OlivierChafik[m]> triangulation occurs early when converting from polyset to nef/mesh, then it stays in triangulated meshes throughout
<J22> yes but is it possible that a problem there would end in different results - i just don't understand why my module `Gewinde()`  is working fine ( although there is some alternate construction du to nonplanar faces)  but with fast CSG i get  "mesh not closed"
<J22> and i  just assume that using 3 point faces could solve this
<J22> however it doesn't solve that there is a problem with 4 point faces
<J22> with low fn it is  even more visible that  there is something off https://pasteboard.co/ahkql3d3vXQ1.png
<OlivierChafik[m]> Looks like a off-by-one error in the user library that generates that polyhedron?
<OlivierChafik[m]> oh got it it's working fine without (sorry didn't read)
<peepsalot> teepee: are MXE builds in a usable state currently? I am getting some problems with it bootstrapping cmake, which I don't understand at all
<peepsalot> here is the tail of the build log: https://bpa.st/XR2Q
<OlivierChafik[m]> fast-csg uses CGAL::triangulate_faces, which maybe isn't as lenient with nearly coplanar faces as the tessellate_faces function we have in polyset_utils.cc
<OlivierChafik[m]> *polyset-utils.cc
<peepsalot> it looks like cmake depends on Qt5Core for cmake tests? ... and Qt5 requires library "mpr" which is not found?
<OlivierChafik[m]> J22: what is the $fn value of the latest example you posted?
<J22> 6
<J22> twist 60 and - 60
<J22> (rot = 60  and rot =  -60)
<peepsalot> teepee: i don't even know what mpr is
<OlivierChafik[m]> J22: I might need to reinstate some of the code I naively thought I could bypass (the one that tries to detect non coplanar faces using CGAL error strings https://github.com/openscad/openscad/blob/master/src/cgalutils.cc#L85 )
<OlivierChafik[m]> J22: those polyhedra are clearly not closed, which is the root issue https://pasteboard.co/vJ7n6OyUm0bs.png ; A good test case for repairs.
<OlivierChafik[m]> (the non-coplanar faces only bother the nef, that seems to be a red herring)
<OlivierChafik[m]> the ub.scad code is a bit dense but maybe this warning is related to the missing face(s):
<OlivierChafik[m]> WARNING: variable endPoint not specified as parameter in file non-coplanar-faces-bug.scad, line 8
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<J22> i added an optional  parameter .. without that  you need  to use  fn+1  as loop
<OlivierChafik[m]> J22: yup that one is closed
<J22> else you can use this https://bpa.st/35PQ
<OlivierChafik[m]> J22: so there's no bug I can see, is there? the rendering in the UI with a nef shows edges but with fast-csg it doesn't, I should write this down as a known issue (didn't make the renderer mesh-aware, and I don't have the topological information the nef has anyway)
<OlivierChafik[m]> (but after remeshing I wonder if we could show non-triangular planar faces in the renderer to come close to the current rendering)
<J22> i think the error with different preview than render was due to a caches problem.  Still the faces are calculated different depending on the rotation (cw or ccw)  but that is not a fastCSG problem   ..   probably i should not use  4 points for a face , this seems to cause  some undefined behavior.
<peepsalot> teepee: nevermind, i guess i just had some broken mixed up config. i wiped mxe and re-ran mingw-x-bnuild-dependencies and it looks like it got past cmake this time
fmlatghor has quit [Remote host closed the connection]
fmlatghor has joined #openscad
<peepsalot> ack, now when i run release-common.sh i'm getting multiple definition linker errors for a bunch of DoubleConversion functions from libQt5Core
<OlivierChafik[m]> Does anyone know if there's a way to validate the syntax of a script without interpreting it? like --export-format=none or something
<peepsalot> OlivierChafik[m]: --export-format=AST might do it
<OlivierChafik[m]> oh cool, thanks!
<peepsalot> or just "... -o foo.ast" of course
<OlivierChafik[m]> peepsalot: using that to add syntax highlighting to https://ochafik.com/openscad/
<peepsalot> nice!
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<OlivierChafik[m]> Just pushed a big update: autorender, syntax highlighting, persistence of camera angle across refreshes, and... proper yellow for solids ✌️
<OlivierChafik[m]> (also added button to kill a pending render, and that's done automatically if auto render is switched on anyway)
<peepsalot> speaking of camera angle, i think that stl viewer has Z and Y axes swapped or something, camera orbit is weird. easier to notice with "sphere($fn=36);" for example
<OlivierChafik[m]> ugh that would explain the mixed up keys too
<OlivierChafik[m]> (it has arrow keyboard shortcuts if you bring the focus to it)
<OlivierChafik[m]> I took the first viewer I could find haha
<peepsalot> yeah we do z=height, but a fair number of graphics apps do y=height, and z=depth
fling is now known as swing
<OlivierChafik[m]> (ugh syntax highlighting works fine locally and not on the site, classic)
<OlivierChafik[m]> (aaand... that's because I've uploaded the most recent release of openscad-wasm in which error messages are formatted subtly differently
LordOfBikes has quit [Read error: Connection reset by peer]
LordOfBikes has joined #openscad
LordOfBikes has quit [Remote host closed the connection]
arebil has joined #openscad
<OlivierChafik[m]> Added the experimental features + render time to the Web UI: think I'm done here, now back to remeshing :-D
<InPhase> Nice. :)
<OlivierChafik[m]> (I'm even parsing --help to get the actual features that are in the WASM binary)
<OlivierChafik[m]> emscripten is so magic
<OlivierChafik[m]> (oh and I've moved the WASM execution to a worker so I can afford to run auto-render and dry-run AST checks for syntax in parallel without slowing down the editor - in theory)
<OlivierChafik[m]> Next thing you know, actual OpenSCAD multithreading will happen in the browser first
<InPhase> It sure ate quite a lot of cpus when I tried testing it.
<InPhase> I think it peaked at Chrome filling up 4 of them.
<OlivierChafik[m]> haha oops
<OlivierChafik[m]> ok I'll add a checkbox to disable the compilation errors
<InPhase> It also didn't work on my elaborate test model, but I tested at an intermediate state. :)
<OlivierChafik[m]> (I mean, the auto-dry-runs)
<OlivierChafik[m]> ah yeah i wonder what can be causing these, but then I'm also trying to figure out simple debug vs. release discrepancies
<OlivierChafik[m]> (that model was https://tinyurl.com/99xftu64 btw; lots of complex models do break this is the smallest I could find that doesnt)
<InPhase> Makes sense. I was pushing it pretty hard just to see.
<peepsalot> i can't even verify if CI servers get same linker error that i'm getting locally, because OOM killer i guess?
<peepsalot> i'm in build hell :(
<J22> OlivierChafik[m]:   is there i trick .. if i add objects in front it seems to work but when adding lines after it doesn't
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
swing is now known as fling
ubitux has quit [Quit: WeeChat 3.3]
<J22> and as soon i adding spheres  it is starting to stop working
<J22> and F1 or command palette  is giving an empty window that doesn't fit
ubitux has joined #openscad
<InPhase> peepsalot: I see "NUMCPU=4" at the top. Can you drop that number to try to avoid the memory issue?
<InPhase> I'm not certain if that's in use at the fail point or not, but that was the first place my head went for a solution path so I went to check if there was any sign it was parallelized.
Administrator_ has joined #openscad
<InPhase> Somebody made the "smallest periodic table". When a reply pointed out Calcium was misprinted, the creator replied, "Probably did a typo when programming the structure in OpenSCAD."
<InPhase> It's from a while ago, but got linked on another channel and I caught OpenSCAD in there in the comments. :)
<InPhase> Good evidence that we cannot hard code the size units. :)
<InPhase> The entire periodic table appears to be about 0.6mm wide.
<InPhase> It looks like the recent posts on that twitter account are about Zero-G 3D printing being tested out in one of those Zero-G planes.
<teepee> heh, nice, and tiny :)
<InPhase> They're doing the metal sintering approach to make metal parts in space.
<InPhase> As soon as OpenSCAD gets used by an astronaut on the ISS we can declare victory.
<InPhase> It certainly makes sense though. Parametric adjustment is I think how you should handle that scope of problems. Professionals on the ground can make the base design, and astronauts can tweak if something isn't perfect under their print conditions up there.
<teepee> interesting point, might be easier to type instead of working with a mouse :)
<peepsalot> do astronauts use spacenav devices?
<InPhase> In any environment for people with the typical astronaut background, but yeah, probably moreso in space. :)
<InPhase> I guess there's a reason the dragon capsule is all touchscreens.
<teepee> elons ego?
<teepee> scratch that, current world is too scary for that :/
<teepee> but yeah spacenav devices would work I suppose
<teepee> that said, I've never used one of the bigger ones, to see how to grab stuff
<teepee> the small one I have is really not usable for full GUI cad work, only for navigation
<teepee> also by random luck, I'm just watching Marcus House on youtube ;-)
<teepee> who just said they may use a joystick to move in the russian cargo capsule
<InPhase> The joystick is the classic control mechanism for this sort of thing in space.
<teepee> yeah, also trackball should be fine
<InPhase> A spacenav gives very nuanced control, and could work well for things in space that you can walk back. It might be too complex for things like docking procedures though. You don't want to accidentally twitch your hand and move an entirely different dimension that you already stabilized.
<InPhase> They are very slow and meticulous about that sort of thing. :)
<teepee> sounds like a sensible strategy
<teepee> peepsalot: does it build now? mxe can be a bit angry depending on parameters given for MXE_TARGET and some others. I had similar issues after just running make without giving a special target
<peepsalot> teepee: looks like it succeeded on circleci, after cutting numcpu from 4 to 2. still not sure why my local build fails
<teepee> oh my, so Zelenskyy is in Munich, crossing fingers that is going to end well
<teepee> peepsalot: did you fetch the latest openscad-snapshot-build branch from the mxe repo?
<teepee> I'm rebasing that for updates, so maybe git is not always catching updates
<peepsalot> yes it is freshly updated and rebuilt from scratch
<peepsalot> the build-dependencies script clones the repo on its own
<Scopeuk> I imagine dragon is all touch screen becouse the crew don't fly it and touch screens let you itterate fast without worry about recertifying your flight electronics
<Scopeuk> not that space x bother with that safety stuff
<Scopeuk> there is a reason they don't hire in people with an avionics background
<teepee> I would assume touch screens have a big plus in not having lots of mechanical parts
<Scopeuk> EXCUSE CAPS**
<teepee> moving on ground yes, in space there should not be many road bumps :)
<Scopeuk> you will still get aceletation deltas between craft and cargo
<Scopeuk> but yes fewer bumps
zauberfisch has quit [Read error: Connection reset by peer]
<J22> InPhase  why  not  hard code the size units  as mm ..    font size would be  0.01  if  he export this as 3mf  it is already mm
<teepee> I think it would be better to allow setting the unit on export instead
<teepee> some language support would be neat but that's probably a big can of worms
<teepee> and insects and spiders and ....
<J22> The Thing is .. if  you design something - it should be an absolute design .. if  i want that part bigger i scale it .. but getting a different size by selecting a different Unit is IMHO very bad
<teepee> it's still absolute if there's no unit
<J22> We already see this in 3D printing when US user print STL files that are opened  with wrong unit  or  something - not sure what they do but often end up with super small prints
<teepee> if you model a town, why pretend to build in mm and then scale?
<J22> yeah well  no relation  is also bad for a design
<J22> I am fine with  different  unit sets   ( you don't want a solar system in mm)
<J22> but it should be in the script
<teepee> yep, especially when using doubles
<J22> .. the was a case  from Airbus where they used different Software and all cables were  20cm too short
<J22> imagine  scripts are exchanged  and  it  is just not defined what is the unit size
<teepee> yeah, it would be nice to have that as option
<teepee> blender does that
<teepee> you get virtual blender units as default, just like openscad, but you can define actual units too
<J22> like  default  mm  but you can define  $unit=inch  or  fathom
<Scopeuk> I suppose there is nothing stopping anyone adding //All units in this scad file in mm. obviously at the moment that doesent go anywhere
<Scopeuk> part of me would like a Metadata function to allow us to add key value pairs at file or module scope
<teepee> sure, you can add comments, but that's a different story
<Scopeuk> initially for humans (maybe display static in customiser?) and then eventually feeding into the export engine
<teepee> the point of actual unit support is that you can convert and handle them in combination
<Scopeuk> certainly doeesnt hurt
<teepee> e.g. this is quite cool in C++20 - https://www.youtube.com/watch?v=mpteQ9wWOQA
<othx> teepee linked to YouTube video "A Crash Course in Calendars, Dates, Time, and Time Zones - Marc Gregoire - CppCon 2021" => 1 IRC mentions
<J22> my lib has a function to use "inch"  Ü
<teepee> actual C++ code: auto t { hours { 1 } + minutes { 23 } + seconds { 45 } };
<Scopeuk> that just a stack of c++ type initialisations but I guess it works
<Scopeuk> nested {} always makes me twitchy
<teepee> I suppose 1h + ... with chrono literals would work too
zauberfisch has joined #openscad
<J22> hm dxf can have units ..  i assume SCAD ignores that for import
<J22> in opposite to 3mf  SCAD  dosn't write the  $INSUNITS value to dxf exports
<J22> so guess what teepee said would be best .. setting the unit in SCAD preferences for export  and also to  import accordingly
<InPhase> J22: It would be easy to define a special $unit or something which gets checked at output.
<InPhase> That's in like with the camera variable usage. And a dynamic variable is a decent solution because maybe at some point certain modules could be designed to respond differently to different units.
<InPhase> s/in like/in line/
<J22> leaves the question if "$unit"  would be  mm or millimeter .. or should be a scaling factor  like  25.4 if working with inch
<InPhase> teepee: It seems that time management stuff is finally getting somewhat usable in C++20. It was pretty poorly designed in the first rounds of this, and very difficult to do basic things with.
<teepee> InPhase: I don't think time stuff was changed, it's adding date + timezone
<InPhase> Well your godbolt example doesn't compile in C++17.
<teepee> hmm, so the literals are new?
<InPhase> Well it's the output that fails.
<InPhase> The 1h was present, but using it was very challenging.
<InPhase> Defining a time was a whole lot easier than converting it out of the type chaos into something that you can work with externally.
<teepee> right, the formatting stuff
LordOfBikes has joined #openscad
<J22> OlivierChafik[m]  found  out that the "open mesh" issues i had also coming from the issue if the render was done without a preview first with the same values.  Also  it seems that fast-CSG is not ignoring % geometry
<InPhase> Most of that structure has been an extremely overengineered solution to a problem that isn't quite that challenging at its core. If you define a duration as a double offset from 1970-01-01, for all execution through 2070, 100 years from the epoch, the precision of a double gives us duration precision down to about 350 nanoseconds.
<InPhase> Linux responds to durations on the timescale of microseconds through a few microseconds. Windows responds to durations on a timescale of millseconds through tens of milliseconds. So 350ns precision on durations counts as an already solved problem.
<InPhase> All the stuff about hours, minutes, an so on, are I/O questions, and are not required for internal representation.
<teepee> but it gets messy as soon as you have timezones. I like the type safe handling very much. although I'm saying that without having it really used, so things may change ;-)
<teepee> not quite looking at the horrible details in date handling, like leap years
<InPhase> When you need to calculate durations across dates it can certainly be more challenging. This requires something with awareness of calendar structure.
<teepee> e.g. that talks shows an example where using the serialized date representation adding 1y means "add mean number of seconds of a year"
<InPhase> Timezones are a very challenging problem to standardize, as it must grab the information from system files which are kept up-to-date with the laws about this that are constantly in flux.
<InPhase> I own a nice watch which no longer does Daylight Savings Time right. Thanks Bush.
<teepee> I hope we really stop doing daylight saving
<InPhase> Very much agreed.
<J22> +1
<J22> i already stopped  .. all my clocks  running GMT+1  (winter and summer)
<J22> also annoying   that  microsoft  (exchange)  thinks  in summer  the timezone is  GMT+1 summertime  DST   and not GMT+2
<InPhase> I would prefer to just use UTC for everything, but it would get harder to track the times of all the meetings I have to go to unless everybody else starts doing it.
<J22> swatchbeat
* J22 wishes everybody would start using his 3digit date format
tachoknight has joined #openscad
<J22> haha fast-CSG removes  some objects when they are not unioned (lazy u)  - no error, they just vanish
<teepee> yep, I have seen that too
<J22> it is a reality feature ..  oO( i was sure i had these screws placed here - well works fine without them )
<J22> or how many manager you can remove from a company until somebody notice it  or it causes problems
<teepee> peepsalot: do you think it would be ok to go back to gcc8 on MXE for a while?
<InPhase> J22: In the case I spotted, the object is still there, it's just invisible.
<InPhase> J22: As in, you can still export it.
<InPhase> I have no mental concept for how that happens...
<OlivierChafik[m]> J22: oops, a tiny reproductible bug report would help. Maybe I'll have to look at the rendering / preview code again to see what's what
<J22> inphase  what .. the list says there are only  x objects .. and you say when exporting i get x+1 ?
<InPhase> J22: You can add a case to here if it is the same behavior: https://github.com/openscad/openscad/issues/4109
<InPhase> J22: Well try an export and see what you have come out. :)
<OlivierChafik[m]> (hah I had almost forgotten about that existing bug :-D )
<InPhase> It smells to me like a one line fix that is primarily about sorting out which one line.
<InPhase> So extra test cases might help.
Junxter has quit [Read error: Connection reset by peer]
<InPhase> Especially a minimal test case.
<InPhase> Mine was a particularly complicated case that is not really appropriate for minimizing.
<J22> found out why ..   all objects that are in union with another  vanish
<teepee> oh, top level union?
<InPhase> Well not always.
<J22> here
<InPhase> Okay, that's small. Let's see...
<OlivierChafik[m]> wow, thanks!!
<J22> if you remove the first two objects so only the union is left .. the union gets rendered
Administrator_ has quit [Ping timeout: 256 seconds]
<J22> and i was wrong they are listed  as objects  .. i just counted wrong as the two vanished objects are in a union so count as one
<OlivierChafik[m]> looks easy to debug thanks to that small case! I won't be able to take a look tonight, can you add it to https://github.com/openscad/openscad/issues/4109 ?
<J22> also if removing one from the vanishing union  . .let the other reappear
<OlivierChafik[m]> (it's a very disturbing bug hahaha)
<InPhase> This is so small and robustly a bug, how did fast-csg work at all? lol
<InPhase> I'm trying to find the edge case of this...
<OlivierChafik[m]> I'm really wondering now
<InPhase> Just putting two cubes inside of a translate makes them disappear, whether they are touching or not.
<OlivierChafik[m]> I was afraid you guys would finally find out the secret that makes fast-csg fast
<InPhase> "Delete everything"
<OlivierChafik[m]> (just not everything so that only few people notice)
<InPhase> :)
<InPhase> Now I need a working example just to bisect this sensibly.
<teepee> added another one to the ticket
<teepee> it might be a cache issue
<InPhase> I'm flushing caches while testing.
<teepee> removing the mirror() makes it appear too
<teepee> I mean cache while one calculation runs
<InPhase> Oh.
<InPhase> Well changing the sizes to mismatch didn't change it...
<OlivierChafik[m]> Mmh and now I can't repro anymore
<teepee> in my example it happens with and without lazy union
<OlivierChafik[m]> Ah ok w/ the one from above I can definitely w/ lazy unions
<J22> oh  i thought it is the lazy union that  caused it .. but  then it is how Hierarchie is displayed
<InPhase> :( I tried to pull and rebuild, and it fails on CGAL version.
<OlivierChafik[m]> (alright, good night folks!)
<InPhase> Requested version is 5.0, but I'm using 5.0.2?
<teepee> InPhase: maybe it does not detect the version at all?
<teepee> why such a horribly old version? :)
<InPhase> 20.04, and 22.04 didn't come out yet because it's not 22.04 yet.
<teepee> 20.04 has 5.0?
<teepee> oh, hm
<J22> ..  i think my other issue with the  changing behavior depending if you previewed the geometry before  is  also somehow cache related .. at least you need to flush cache and preview with the render settings to remove the issue
<InPhase> 5.0.2
<InPhase> But apparently my cmake files are reporting "version: unknown"
<teepee> yep, that's what I meant, I thought that was with even older versions
<teepee> you can try https://download.opensuse.org/repositories/home:/t-paul:/cgal/xUbuntu_20.04/ if you don't need the official version
<InPhase> I tried updating that 5.0 to 5.0.2 on line 306 of the file, but it did not alter the behavior.
<teepee> you can just remove the number
<InPhase> I can. But do we want to be supporting out of the box build on 20.04 before I do manual tweaks?
<InPhase> (Removing the number does make it succeed.)
<teepee> not sure we can do much
<teepee> I think we are using the cmake file installed by libcgal-dev
<InPhase> It looks like the reported version is 5.00 according to the output...
<J22> teepee your example can be  boiled down to https://bpa.st/PJDQ
<J22> so the difference could be replaced by a union ()  and probably a intersection or translate
<teepee> but only with lazy union
<teepee> the original one happens also with lazy union disabled
<J22> ah ok
<InPhase> teepee: This works. What do you think about this? https://bpa.st/QHTA
<InPhase> (Without the extra spaces that are a copy/paste error.)
<teepee> hmm, not a huge fan of making it more complicated for old distros, but I guess 20.04 will be around for a while
<teepee> maybe with a note why it's needed
<InPhase> Well it's technically not old yet, as it's the most current stable Ubuntu release.
<InPhase> In a few months we could tell a different story. :)
<teepee> yeah, in calendar terms it's old :)
<InPhase> I mean, 2019 was just last year, right?
<teepee> yes
<teepee> hopefully that changes in the next couple of years
<InPhase> std::duration::covid
<teepee> I hope that's not an alias for inf
la1yv_b has quit [Read error: Connection reset by peer]
la1yv_b has joined #openscad
<InPhase> Probably ratio<1,0>
<InPhase> I suppose this check can be switched back to a 5.x REQUIRED as soon as the minimum gets bumped up. It seems this is probably only a 5.0 bug with the minimum value currently supported.
<teepee> yeah, we'll see what happens with newer releases of CGAL, suggested version is >= 5.4 anyway
<teepee> but it would be useful to keep the simple compilation for a while longer, even it if needs to special case a small number of improvements
<InPhase> So we want my edit as a PR?
<InPhase> Halfway through typing it. :)
<InPhase> You have the better vantage point for the assortment of build issues across many platforms, so I defer to your more diverse experience on it.
<teepee> well, it's not needed for the official builds as we try to follow the latest cgal, but I think it's still useful for some people who want to compile themselves on 20.04
<teepee> so I'd say it's good to have
<InPhase> Ok.
<gbruno> [github] t-paul pushed 1 modifications (Merge pull request #4131 from rcolyer/CGAL5Compat Switch to an afterwards check for CGAL version.) https://github.com/openscad/openscad/commit/d9b00721d71e9caaa1be880e2ff2faa10c16981c
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gbruno> [github] t-paul closed issue #3983 (Error with Command Line .png export in a Docker container) https://github.com/openscad/openscad/issues/3983
<dalias> cursed idea: slicer implemented in openscad
<dalias> i.e. in the openscad language