<JordanBrown>
InPhase: I think we should figure out how to get CGAL involved on *every* F6 render, not just when there's two or more objects, so that at least we get the errors when the bad object is by itself.
<InPhase>
Well I wouldn't want to slow things down needlessly.
<JordanBrown>
Shrug. How much would it really slow down a case that nobody really uses anyway?
<InPhase>
But checking at import is doable with CGAL allegedly.
<InPhase>
I use it a lot with models that are only a single polyhedron call.
califax has quit [Remote host closed the connection]
<JordanBrown>
Yeah, true. I was thinking of imported STLs.
califax has joined #openscad
<JordanBrown>
Still, how much does a CGAL render of a single polyhedron cost?
<JordanBrown>
Data tidbit: a CGAL render of the Menger sponge demo (example024) unioned with a cube took 13s. But how much of that is the union?
<JordanBrown>
(That is, I rendered the Menger sponge into an STL, then imported the STL and unioned it with a cube(1).)
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<InPhase>
Menger sponges tend to take a lot longer to compute than to render.
<InPhase>
It's one of the few cases where our compute times can get significant.
<InPhase>
Although maybe that's better now. I haven't checked in a while.
<InPhase>
Where you really get a difference is very smooth polyhedrons with many faces.
<InPhase>
It's easy to get 100x the runtime or more by dropping in a cube.
<InPhase>
Now I will note that master does this example in 1.5s even with the cube.
<InPhase>
This might be because of lazy unions
<JordanBrown>
Adding the cube is taking a long time on my system.
<InPhase>
Nope, seems to be fast-csg. Well, turning off lazy union took it to 3s. Most of the gains were fast-csg.
<JordanBrown>
It happens that the OpenSCAD that I have running at the moment is 2021.01.
<InPhase>
So theoretically it might be more practical now. But I'm not sure if we have fast-csg and lazy union on if it will even catch those stl errors in an identical case.
<InPhase>
Yeah, 2021.01 is what I meant when I said 2022.01
<JordanBrown>
If it doesn't catch the error... is it an error?
<Friithian>
switch to eevee for visual rendering :D
<InPhase>
JordanBrown: Yeah, because then it will just show up later when something intersects. :)
<JordanBrown>
3m26s with the cube, vs 5.5 without.
<JordanBrown>
5.5s, that is.
<InPhase>
Yeah. Steep ratio. And we could make it worse by just adding more faces.
<JordanBrown>
180K faces is a lot.
<InPhase>
Pretty normal for the smooth stuff.
<JordanBrown>
One of the big questions is how much of that render time is the polyhedron and how much is the union.
<JordanBrown>
Trying a test right now where the cube is out at [100,0,0] so the bounding boxes don't overlap. Seems to be taking just as long, which is kind of sad because in that case the union is easy.
<JordanBrown>
Even I can union polyhedra where the bounding boxes don't overlap :-)
<JordanBrown>
That one actually took longer, 3m59s. Maybe there was something (other than the union) cached.
<JordanBrown>
The first time, that is.
<JordanBrown>
Unfortunately, I haven't found any way to trick OpenSCAD into getting CGAL involved without also causing a union. (Or, presumably, other booleans.)
LordOfBikes has quit [Ping timeout: 252 seconds]
LordOfBikes has joined #openscad
qeed_ has joined #openscad
qeed has quit [Ping timeout: 268 seconds]
J1A8435366 has joined #openscad
J1A843536 has quit [Ping timeout: 252 seconds]
J1A8435366 has quit [Ping timeout: 252 seconds]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
J1A84 has joined #openscad
aiyion1 has quit [Remote host closed the connection]
aiyion1 has joined #openscad
califax has quit [Remote host closed the connection]
<J1A84>
?? ERROR: Rendering cancelled by exception std::bad_alloc
<J1A84>
would be nice if i get some more info what caused it Ü
<InPhase>
Running out of RAM, presumably.
<InPhase>
Most often from mashing together things with too many facets, and the top level union fails out on a tight-RAM system.
<InPhase>
Lately I give OpenSCAD about 120GB to play with, so I don't ever hit that scenario. But I do consequently see the points that would fail out on a system with less capacity.
<J1A84>
still 8GB available
<InPhase>
J1A84: For example, my openscad maximum memory consumption log reports 3GB were consumed when I was running that wavy donut merged with a cube the other day: "2022-08-18 20:41:22 2972.785 MB, openscad test.scad, ~/3DP/RC/closepoints"
<InPhase>
I generated a file related to a trinket from my previous job last month, and the log says that one took 8.5GB at peak.
<J1A84>
oh what is that scad suddenly took additional 7GB
<InPhase>
What OS are you running on?
<InPhase>
My memory log script is very nice, but is written for Linux.
<InPhase>
One of the larger entries in my log is the 2021 advent calendar entry Tree.scad by that Ulrich Bär guy. :)
<InPhase>
That was 14GB.
<J1A84>
seems that guy has no clue how to code memory efficient ..
<InPhase>
I have a 20GB entry for the temp file /tmp/filea6e9gs.scad. But I have no clue what that was.
<J1A84>
but i think something goes awry with roof ..
<InPhase>
Ah. Might. That's still experimental.
<InPhase>
I guess the next is to figure out if that's necessary or a bug.
<J1A84>
normally i see issues "not closed" or "skeleton.. " but not these RAM usage peaks
<InPhase>
My OpenSCAD peak RAM consumption per design, over 412 entries for the last 8 months, ranged from 1.5MB to 20GB, with a standard deviation of 1.6GB, a mean of 558MB, and a median of 173MB.
<InPhase>
9 months I suppose.
<InPhase>
I started the log Dec. 7th, 2021.
<InPhase>
My goal of which is to build up a record in the background that can be used for regression testing of RAM consumption.
<J1A84>
Some kind of error msg translation would be useful like " not enough memory" instead of std::bad_alloc
<InPhase>
That would be platform specific anyway.
<InPhase>
You'll never see that error on most Linux systems. It will just unceremoniously crash when the oomkiller gets rid of it.
<J1A84>
oh .. okey - i wonder if that usage is caused also by fast CSG as normally it reduces RAM usage drastically
<J1A84>
.. i rendered this with .5 wide walls .. changed to .6 and that seems to hit a very bad spot
<InPhase>
Did that trigger any weird intersections that weren't there before?
<J1A84>
no shouldn't but using offsets with roof is very sensible if you hit a bad range
ur5us has joined #openscad
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
<J1A84>
haha without the problem part it only uses 300mb .. and that problem part are just 18 small notches
<J1A84>
seems there was a very small residue that caused problems
<InPhase>
Well now there's a wishlist item that's never going to get implemented. :)
<teepee>
not the first part anyway. the last tree structure thing might be useful
<InPhase>
Could be, although that's probably why I already write my code that way.
<J1A84>
InPhase .. that is exactly what i thought .. "good luck with that one"
<J1A84>
sometimes you wouldn't want the consequences if wishes were granted.. however if we could have some realtime code highlight when moving over the geometry - could be nice
ur5us has joined #openscad
aiyion has quit [Ping timeout: 268 seconds]
aiyion has joined #openscad
ur5us has quit [Quit: Leaving]
ur5us has joined #openscad
ur5us has quit [Ping timeout: 256 seconds]
<InPhase>
Well we have # highlighting for going the other direction.
<JordanBrown>
There is the right-click mechanism for giving the source lines for a particular pixel.
<InPhase>
JordanBrown: Yeah, that's the one. I can never remember what clicky-magic that is, because I never use the editor in everyday use.
<JordanBrown>
InPhase: a good first step on memory benchmarking might be to have the test suite record memory usage. It probably doesn't do much with complex modules, but detecting *any* growth might be a good first step, and it has the advantage of running a repeatable set of models on a regular basis.
<InPhase>
JordanBrown: Well, I know how to do it for Linux runs.
<JordanBrown>
That's a start.
<InPhase>
It's possible there would be a way to do it portably within code, but someone would have to hunt for OS-specific routines for that.
<JordanBrown>
And if one platform starts consuming more memory, the others *probably* do too.
<InPhase>
Yeah, probably the case.
<JordanBrown>
But yeah, you could have an abstract "get me memory usage for this process" function, with the option that a platform-specific implementation would say "don't know".
<InPhase>
I really just do /usr/bin/time -v -o "$TEMPF" -- openscad blah.scad and then I post-process that temp file for "Maximum resident set size (kbytes)" and crunch the numbers to megabytes and log it.
<InPhase>
Probably macos could do the same, but I haven't tried it.
<JordanBrown>
Automated performance testing might be interesting too. Would want to measure CPU time, if possible, rather than wall clock time, so that it isn't affected by competition from other processes.
<InPhase>
The nice thing about that approach is it specifically obtains the maximum size the program had at any point during its run, and doesn't check the amount at any specific check time.
<Friithian>
why use the time binary instead of the keyword?
<InPhase>
Friithian: Because that's the one that gives the information. :)
<InPhase>
I want the memory info under verbose, rather than the time itself.
<Friithian>
oh resource usage, I feel like there'd be better things to get than
<JordanBrown>
I haven't looked at what resource statistics are available to the process, but it wouldn't be surprising if it included peak usage. Also, few C programs ever reduce their memory usage during a run, because malloc implementation don't usually release pages.
<InPhase>
OpenSCAD is pretty good about letting go of memory when it is done with a render.
<InPhase>
At least, since we fixed that function literals bug.
<JordanBrown>
Good for it. Uses something other than malloc/free?
<InPhase>
It mostly has to do with the order of acquisitions.
<InPhase>
But also, it is now using a custom malloc. But it has always been good about this. render basically steals everything the program is doing, and then finishes.
<InPhase>
Which is bad, but good for memory cleanup. :)
<peeps[zen]>
wasn't there an openscad issue opened about that alternative geometry library made for parallel processing that used CUDA etc? I can't find it at the moment
<JordanBrown>
rendering in a separate process might be a good mechanism.
<JordanBrown>
requires file-based caches, though.
<JordanBrown>
but makes cancel semantics a lot easier.
<JordanBrown>
I should go back to pretending to do work that I get paid for ... later
<peeps[zen]>
ah I found the project link, but i guess there wasn't an issue created about integrating it? https://github.com/elalish/manifold
qeed_ has quit [Quit: qeed_]
qeed has joined #openscad
<teepee>
not sure, maybe it was discussed in one of the fastcsg issues
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
ghee has joined #openscad
ghee has quit [Quit: EOF]
teepee has quit [Remote host closed the connection]