<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]
<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>
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
<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
<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?
<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
<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
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
<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?
<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.
<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>
OFFSET BY BEING AWFUL TO WORK WITH IN A MOVING VEHICLE
<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
<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 ?
<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"
<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