<InPhase>
dalias: I suppose technically all we would need is data = render() getting merged and a better text printing function, plus someone crazy enough to write it.
<dalias>
given that a dumb test i just did threw an assertion failure trying to project benchy at z=20, i think we have a way to go... :-p
<InPhase>
Has anyone ever checked if the famous benchy is actually manifold?
<dalias>
lol i dunno :-p
<peepsalot>
teepee: gcc version doesn't matter much to me, i thought the older versions were removed in latest mxe or something
<dalias>
btw this is somewhat OT but too cool not to post: someone actually built the "inverted delta" printer i proposed as a joke: https://youtu.be/DXxFBjXW8SI
<othx>
dalias linked to YouTube video "9:46 Benchy on !Delta (quantum Delta) #speedboatrace" => 1 IRC mentions
<peepsalot>
teepee, i think the OOM issues on my PR are mainly because I do RelWithDebInfo, which i asssume uses much more ram (the exe filesize is many times larger anyways)
<dalias>
it shouldn't use more ram
<dalias>
the debug info is not part of the program load segments
<dalias>
so it's not mmapped as part of execution and thereby won't be demand-paged in
<dalias>
unless RelWithDebInfo also has additional introspective debugging functionality enabled
<InPhase>
It does. It turns on the stuff that lets you do stack traces during execution.
<dalias>
ah
<InPhase>
Although I think peepsalot was facing OOM only during build.
<dalias>
ohhh
<dalias>
yeah during build -g will definitely cause OOM
<dalias>
like 90+% of the link-time memory usage of a moderate to large c++ program with debug info is the debug info
<InPhase>
And that info for stack tracing really shouldn't be too big in a modern system. We're talking probably about 1MB at most for something like OpenSCAD.
<dalias>
i dont think just stack tracing loads the debug info
<InPhase>
Just don't try it on a C-64. :)
<dalias>
it just uses the unwind tables and the dynamic symbol table
<dalias>
which are part of the loaded program segments
<InPhase>
Yeah, there are multiple pieces of this, mapped up to different flags depending on the compiler.
Guest96 has joined #openscad
Guest96 has quit [Client Quit]
<teepee>
peepsalot: no, they just switched default, there's quite a number of old gcc versions available as plugin still
<teepee>
I though gcc8 might help with that missing dll issue but it seems it's not gcc version, but mingw version
<teepee>
by accident I found that the SoapUI application, which is shipping a JDK actually includes a huge bunch of those libraries
<peepsalot>
well, i've already expressed why i'm personally not losing any sleep over it, but on the other hand I wouldn't stand in the way of anyone still working to resolve it
ur5us has joined #openscad
<teepee>
yeah, I don't want to spend huge amount of time on it, just trying some things if I find pointers
<peepsalot>
btw, tangentially related, but the only objection i might have had to gcc8 would be if it slowed transition to c++17. but checking the compatibility tables, gcc8 definitely fully supports c++17, so no issue there. so are we at a point were we can officially use c++17 yet?
<teepee>
well... I sort-of mentioned that in the readme already ;-)
<teepee>
although I think that means dropping 18.04 which I guess we maybe should wait 2 month :)
<teepee>
but gcc8 did not help with mingw anyway, so we can just keep gcc11
LordOfBikes has quit [Ping timeout: 256 seconds]
<peepsalot>
i also just noticed that support for qt5 ended in may last year. those guys are brutal with their release schedule
<peepsalot>
has anyone attempted builds with qt6 yet? does it mean much for our project at the moment?
<InPhase>
Seriously? Already?
<InPhase>
No, May was the last "LTS" release.
<InPhase>
Surely "LTS" means something.
<InPhase>
Or that was May of 2020. The years blend.
<peepsalot>
and open source support ended may 2021
<InPhase>
So 5.5 months after Qt6 was released?
<InPhase>
I really need to find myself a new gui library...
<peepsalot>
from your link "Regular releases are supported for one year. Starting from 5.15, LTS releases are supported for three years but only for commercial license holders. For open source users, they are same as regular releases."
<teepee>
open source supported ended when Qt6 was not even fully released
<teepee>
they released "something" called Qt6
<peepsalot>
i haven't been following closely enough to know what any of the Qt6 issues you guys are referring to are about
<teepee>
I just know that the first "release" did not include all modules, including some we use
<teepee>
because they seem to care mostly about mobile lately
tachoknight has joined #openscad
tachoknight has quit [Ping timeout: 240 seconds]
ur5us has quit [Ping timeout: 240 seconds]
<InPhase>
peepsalot: I'm mostly furious for some work projects because they disabled all centralized exception handling for events. Centralized top-level exception handling is an extremely important concept in reliable programming, and they just decided to flat out break it and declare no one should do such a thing.
<InPhase>
It has been one of the cornerstones of my Qt architectures for about 15 years.
<ccox>
InPhase - holy backward progress Batman!
<InPhase>
OpenSCAD actually makes use of this, but not for too much.
<ccox>
I guess someone heard that exceptions were bad, and didn't bother learning the details.
<InPhase>
peepsalot: In summary, OpenSCADApp.cc line 52's notify function is invalid in Qt6, and there is no replacement.
<InPhase>
We are not really using this though, because we barely use threads in the first place.
<ccox>
cgal and some libs use threads (which lead to some unhandled exception crashes)
<InPhase>
One of my important programs at work using Qt however has something like 30-40 threads, all of which use exceptions for error reporting like they are supposed to.
<InPhase>
The whole threading architecture needs to be rewritten within the next year or so now to not even use Qt, at which point I'm not sure why I'm using the full weight of Qt just to throw some gui elements up when it hasn't even been doing a particularly good job of arranging elements since they keep messing with how that's done too (for the mobile focus, presumably).
<InPhase>
With C++ having expanded a lot lately, I feel now like I should have a gui system which is focused on just being a gui system, and that likes to play friendlier with the open source community.
<ccox>
No, GUI on multiple platforms is a LOT more work than the C++ committees want to take on.
<ccox>
heck, many of them are working full time to support GUI on a single platform
<teepee>
yep, it would be nice to stop this "yes, we have a string class too"
<ccox>
yes, but there are only about 50 definitions of what a string class should be...
<InPhase>
ccox: I wasn't saying a gui system should integrate with the C++ stdlib. :)
<ccox>
InPhase - sorry, that's how I read your comment.
<InPhase>
ccox: I was saying that since C++ handles so much else now, like threads, filesystem support, etc, that it doesn't make sense to have all that stuff that's in Qt carried around just to do a gui.
<InPhase>
We need a good open source gui option that works WITH modern C++ instead of tries to supplement it.
<ccox>
But yes, having a decent open source GUI / app framework makes a lot of sense. And Qt trying to reproduce it doesn't make sense.
<ccox>
true.
<InPhase>
supplement? Replace
<InPhase>
I remember the historical context of how Qt got to where it is. When it started, that was all needed.
<InPhase>
But we're not there now.
<ccox>
agreed
<InPhase>
QVector and QString should have been removed long before exception support.
<teepee>
yep, copperspice tried to move to more native c++ features, but I don't think it's widely used
<ccox>
(of course, even when it started, it was 20 years behind commercial app frameworks)
SamantazFox has quit [Remote host closed the connection]
<teepee>
"...with a goal of providing a first class GUI library to unite the C++ community." :)
SamantazFox has joined #openscad
<ccox>
ROFLMAO!
<InPhase>
I haven't looked into CopperSpice much, but maybe that's a place to start out. It seems small in activity so far, but not impossibly small.
<InPhase>
It's at least not a dead project. :)
<ccox>
give it time :-)
<teepee>
true, although I don't remember seeing new videos coming out
* teepee
goes checking if yt did the automatic unsubscribe again
ur5us has joined #openscad
<teepee>
hmm, 1 month ago, I missed that
<teepee>
at least they also removed that moc nonsense and have c++ signals
<ccox>
yay, that's a start
<teepee>
oh! CsPaint - not so good name, but it's a Vulkan API
<InPhase>
Ah, no moc sounds great.
<InPhase>
cmake takes a lot of the moc edge off, but I'd be very happy to never see it again.
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #openscad
GNUmoon has quit [Ping timeout: 240 seconds]
ur5us has quit [Ping timeout: 240 seconds]
GNUmoon has joined #openscad
J2257 has joined #openscad
J22 has quit [Ping timeout: 256 seconds]
ferdna has quit [Quit: Leaving]
gunnbr__ has quit [Quit: Leaving]
KimK has joined #openscad
Administrator_ has joined #openscad
Administrator_ has quit [Read error: Connection reset by peer]
Administrator_ has joined #openscad
Administrator_ has quit [Client Quit]
Junxter has joined #openscad
peeps[win] has joined #openscad
<peeps[win]>
jesus, the windows exe with debug symbols is 1GB
snaked has quit [Ping timeout: 240 seconds]
<Junxter>
amen to that
ur5us has joined #openscad
ccox has quit [Ping timeout: 250 seconds]
ccox has joined #openscad
KimK has quit [Quit: Leaving]
ToAruShiroiNeko has quit [Remote host closed the connection]
snaked has joined #openscad
ToAruShiroiNeko has joined #openscad
KimK has joined #openscad
ur5us has quit [Ping timeout: 240 seconds]
YASS has joined #openscad
YASS has quit [Client Quit]
<J2257>
https://bpa.st/LWUA right click doesn't work for intersections .. and if a difference is there it stops working for other
<J2257>
( and in complex scenes the view messes up beyond recovery as invisible differencing and intersecting geometry is suddenly displayed)
Junxter has quit [Quit: Leaving]
Junxter has joined #openscad
Junxter has quit [Remote host closed the connection]
Junxter has joined #openscad
<J2257>
hmm wireframe F11 is not working anymore
<J2257>
(with fast CSG)
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<InPhase>
J2257: Probably due to the representation change not being handled by wireframe. Sounds like something to add as an issue.
<J2257>
fast CSG is not CGAL ? thought it is just a newer version of it .. however i get wireframe but not if fast CSG is active
<teepee>
it is cgal, but not the NEF stuff used before
<InPhase>
teepee: Good call, that does look like it might be the same. So I guess that could check off an old problem. :)
<teepee>
well, it might be still new code with the new hybrid objects, but same effect that the wireframe only supports the NEF stuff
<InPhase>
And conversion ability exists.
<teepee>
yes either that, or extending the renderer
<InPhase>
Yeah. I know OlivierChafik[m] spoke of removing the old form entirely, which looks like the right goal, but maybe it takes a bit to build up certainty in doing so.
<OlivierChafik[m]>
actually the CGALHybridPolyhedron (fast-csg) uses preferentially a Surface_mesh + corefinement operations, and as a fallback it uses the Nef_polyhedron_3, but with a different kernel than the Nef used in the rest of OpenSCAD. So even after a fallback (e.g. when we have a nef result) I convert the result to polyset instead of to the standard OpenSCAD nef
<OlivierChafik[m]>
could either convert meshes to legacy nefs to reuse the same code, or convert the old code to use new nefs and ditch legacy nefs
<J2257>
maybe we should just remove the wireframe option .. is it any use at all? As you can use show edges with color(alpha=0) for that
<InPhase>
Wireframe is more of a low risk thing to mess up. Clearly it has been messed up for a while and only caused minor issues.
<OlivierChafik[m]>
InPhase: part of the uncertainty comes from the lazy behaviour of the kernel used by the hybrid (Epeck). As it turns out, I've been toying with the idea of caching numbers... no clue if it could help haha
<J2257>
and F11 only works on render with two objects
<InPhase>
Which is another way of saying it could be reasonable to opt for the bolder future-focused fixes to the wireframe code.
<OlivierChafik[m]>
(by caching I'm thinking both normalizing input numbers and transitions from these numbers along the arithmetic operation trees; how many truly different numbers does one render need anyway?)
teepee has quit [Ping timeout: 240 seconds]
GNUmoon has quit [Ping timeout: 240 seconds]
aiyion has quit [Ping timeout: 240 seconds]
TheAssassin has quit [Ping timeout: 240 seconds]
<OlivierChafik[m]>
Is the only benefit of the nef for wireframe to detect "true" edges of coplanar patches?
<OlivierChafik[m]>
The remeshing code I'm working on could get us that, i.e. create meshes with more-than-triangles, then we could update the rendering logic to use them
<InPhase>
I don't know that. peeps[win] might have insight.
<OlivierChafik[m]>
(rn I'm asking CGAL to triangulate those faces after I fused all the neighbouring coplanar faces together, and manually collapse collinear edges around those patches)
<OlivierChafik[m]>
the hybrid could keep a flag saying whether its mesh is triangular or not, so the remeshing would have less work to do (we'd only ever triangulate meshes just before feeding them to corefinement), and non-triangular meshes would just bubble up to the top-level, ready to render (lazy union or not)
<InPhase>
At one point I started a code-dive into your corefinement stuff, but never got through it before life called me away. So the hybrid type is doing the primary number crunching on fully triangularized meshes?
<OlivierChafik[m]>
(and hates self-intersections, and moderately dislikes unclosed meshes)
<InPhase>
And then at the end you undo the triangles?
<InPhase>
As like a final step?
<OlivierChafik[m]>
yeah it creates way too many of them so I'm trying to patch them back up together, remove unneeded vertices in the border around said patches, then let cgal retriangulate the patches
<OlivierChafik[m]>
yup, need a corefinement visitor to keep track of the original patches
<OlivierChafik[m]>
(each time a face is split or copied over between meshes, it inherit the original patch id)
<OlivierChafik[m]>
this allows avoiding coplanar tests, but if we also do exact coplanar tests for neighbouring faces (doing a flood-fill patch propagation) that didn't come from the same patch then we get optimal remeshing
<OlivierChafik[m]>
(as in, `cube(1); translate([0.5, 0, 0]) cube(1);` remeshed as 12-faces instead of 44)
<OlivierChafik[m]>
Oh, just realized I skipped the problem of patches with holes in them, haha!
<OlivierChafik[m]>
(might have to skip them for now :-( )
<teepee>
I've seen one case where a difference between a sphere and a cube actually worked and that had some ugly mesh deformations in the sphere at a point where there's no overlap
<OlivierChafik[m]>
eeesh
<teepee>
not sure if that's caused by the missing rounding-math flag, I would have assumed that's not critical for most models
<OlivierChafik[m]>
oh yes I was wondering about that too
<OlivierChafik[m]>
for every infinitesimal difference between two builds, there's a model out there that breaks with one and not the other
<OlivierChafik[m]>
we're be less sensitive to doubles if we carried exact numbers from parsing to transforms and ditched polyset in favour of Surface_mesh
<OlivierChafik[m]>
we'd*
<OlivierChafik[m]>
#daydreaming
<OlivierChafik[m]>
(also we'd need to make minkowski use exact numbers)
<OlivierChafik[m]>
(and hull)
epony has quit [Ping timeout: 240 seconds]
paddymahoney has joined #openscad
epony has joined #openscad
Junxter has quit [Read error: Connection reset by peer]
<Scopeuk>
OlivierChafik[m] I tried running the deep linked model from the issue on my android device and it went out with a cgal assertion
<OlivierChafik[m]>
Scopeuk: thanks for trying it! Yes same on mine, but also it throws a weird exception that is only visible in the javascript console (well, I also print it in the last scrollable line of the log but it's just a number so a bit unconspicuous)
<OlivierChafik[m]>
which means maybe there's a segfault on top of the cgal assertion (assuming that number exception means segfault, didn't investigate further yet)
<Scopeuk>
Yeh I saw the number on second attempt
ur5us has joined #openscad
<OlivierChafik[m]>
my iphone won't run the demo and I don't know why yet :-(
<Scopeuk>
Looking at he wasm docs you can bind an exception handler in the is, not sure if we could catch from there
<OlivierChafik[m]>
I'm hoping for a debug build to come with debug symbols that will help break on an uncaught exception
<Scopeuk>
That would certainly help
<Scopeuk>
Hmm emscripten docs seam to suggest there is one flag to add debug information but also that the exception number is a memory pointer to the exception information which must be decoded in js
<OlivierChafik[m]>
yeah I tried modifying the docker build to have everything in debug but there's probably something I missed.
<OlivierChafik[m]>
also should probably make sure we have options like -s ASSERTIONS=1 -O0 -gsource-map --source-map-base=...
<OlivierChafik[m]>
(I think there's two debug formats, sourcemaps are deprecated but still worked better than the native symbols version in chrome last I checked)
<Scopeuk>
It looks like it is preserve debug info but depends on optimisation level. Hopefully the emscripten is snippet for handling a c++ exception thrown in transcribed implementation could be added more easily, on mobile right now so can't easily fudge the is console
<Scopeuk>
Hmm it at the -g switch from that messge
<Scopeuk>
S/at/ate
<OlivierChafik[m]>
s/S/s/?
<OlivierChafik[m]>
<entering ascii art haiku challenge>
<Scopeuk>
Silly tablet auto capitalisation is for kids. My tablet failed a few days ago so I'm on my old one and there are bits of config catching me out, took a day to remember how to turn the tab key on
<OlivierChafik[m]>
Never ending fight against technology
<Scopeuk>
Yup
<peepsalot>
OlivierChafik[m]: i'm all for replacing Polyset with something better. i'm curious with the remeshing you're working on though, how would rendering to opengl work on non triangular faces?
<OlivierChafik[m]>
Haven't looked into it yet but we'd probably use the non triangular faces for the edges, then ask glew or cgal to give us proper triangles to render
<OlivierChafik[m]>
same as happening today w/ the nef i presume
<OlivierChafik[m]>
teepee: on a separate note, I ended up doing more changes than I expected in https://github.com/openscad/openscad/pull/4132 . I swear I thought I had my tests green locally before the last push but it's already turning red in the cloud, looking!
tachoknight has joined #openscad
<OlivierChafik[m]>
teepee: when do we use polysets in the 2d case btw?
<peepsalot>
OlivierChafik[m]: you have to navigate to the "Summary" page, from the left menu, and then scroll to the bottom where the Artifacts are
<teepee>
OlivierChafik[m]: no problem, that's one of the big points of those CI runners, catching stuff across platforms
<teepee>
2D uses a different data structure yet again, basically nested directional outlines
<OlivierChafik[m]>
peepsalot: thanks!
<teepee>
yes, test html is available, I have no idea why they removed that convenient direct link
<teepee>
i only know that lots of clicking way peepsalot mentioned
<teepee>
also still hoping they eventually allow to upload html directly and serving that
<teepee>
but maybe there's security concerns
<peepsalot>
can we make it a gist or something like that?
<OlivierChafik[m]>
convert to md maybe
<teepee>
not sure how to handle inline images then
<teepee>
or do they support that with their markup too?
<teepee>
I don't really want to setup too much external stuff that requires extra tokens, but everything github should be fine automatically
<teepee>
including runs by pull requests, problem with those is that everyone could push extra code for extracting secrets
<OlivierChafik[m]>
data uri for images (Base64) each
<OlivierChafik[m]>
s/each//
noonien has joined #openscad
<peepsalot>
yep the images are already embedded in html using data uri. i would assume it works fine with markdown but haven't tested that
<teepee>
home sweet home, I could try to make run a wasm debug build
<teepee>
should be enough for just the openscad part?
<OlivierChafik[m]>
🤗
<OlivierChafik[m]>
mmh not sure what boost does to its headers
<OlivierChafik[m]>
could it be writing some headers that define release vs. debug stuff?
<OlivierChafik[m]>
other than that yes, I don't plan on debugging gmp haha
<OlivierChafik[m]>
(although... really wanna put my ideal of wrapping gmpz into a smart transition graph to a test to that could come in handy at some point)
<OlivierChafik[m]>
*idea
<teepee>
well, I can try what we get with just changing the cmake params
<teepee>
also argh! I think I deleted the local build folder
<teepee>
Debug or RelWithDebInfo?
<OlivierChafik[m]>
oopsie
<OlivierChafik[m]>
Not sure what the difference is tbh
<teepee>
I would assume relwithdebinfo is optimize + debuginfo where debug is no optimization
<OlivierChafik[m]>
Debug probably more useful
<OlivierChafik[m]>
(at this stage :-D )
<OlivierChafik[m]>
re/ test artefact, another option would be ctest --output-on-failure
Junxter has quit [Ping timeout: 272 seconds]
KimK has quit [Ping timeout: 240 seconds]
<teepee>
heh, UAE seems to use $fn = 20 for all statues ;-)
extor has joined #openscad
GNUmoon has joined #openscad
<OlivierChafik[m]>
maybe they need good openscad consultants
<OlivierChafik[m]>
hah, I might try and modify the service worker hack to do that, but later in the week I think
<OlivierChafik[m]>
thanks!!
<teepee>
firefox does not seem to like the page
<OlivierChafik[m]>
I apparently have to import the wasm module with an explicit import to please chrome, and firefox doesn't honor new Worker(..., {type: 'module'}) yet :-(