<JordanBrown>
PolyBytes: if you know how big the module is, just translate it. If you don't... then no, there is no general way.
<JordanBrown>
Usually the plan is to design your module so that it has its origin at a convenient point.
<JordanBrown>
Maybe you have it take an argument that controls where on the sub-model the origin is.
<JordanBrown>
PR#4478 would offer a general way to do it, at the cost of needing to fully render the object.
<JordanBrown>
It wouldn't be all that hard to have a general operator that could do it, using basically the same techniques used for the resize() operator. But that requires fully rendering the object.
<JordanBrown>
Why is it hard? It's hard to analytically find the center of an intersection or difference without actually *doing* the intersection or difference - and preview uses Black Magic(tm) to avoid actually doing the operation.
castawayc has quit [Ping timeout: 252 seconds]
califax has quit [Remote host closed the connection]
<UltimateCodeWarr>
So I am differencing about 400 cylinders with another threaded cylinder in order to make a kind of a mesh to allow air flow. Preview (F5) Works fine but Render Crashes and Burns Hard, exits the program.
<InPhase>
System RAM?
<UltimateCodeWarr>
16GB
<UltimateCodeWarr>
Window 11
<UltimateCodeWarr>
I7
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
snaked has quit [Remote host closed the connection]
<peepsalot>
might need to reduce number of segments on your cylinders
<peepsalot>
/ threads
<InPhase>
UltimateCodeWarr: It takes some work to go over 16GB, but I've done it plenty of times.
<InPhase>
UltimateCodeWarr: Mixing numbers like "400" with threading can very likely do it.
<InPhase>
Yeah, this has already gone past 32GB for me.
<InPhase>
And climbing.
<peepsalot>
don't do this: this is bad
<InPhase>
Maxed out at 43090.223 MB of RAM.
<peepsalot>
ack, messed up my copy/paste: $fn = $preview ? 64:360;
<InPhase>
But completed fine at that.
<peepsalot>
especially right after setting $fs and $fa at the top level
<InPhase>
Yeah, setting $fn to 360 when you're making 400 2mm diameter cylinders makes a whole lot of faces for nothing. :)
<InPhase>
Those faces are going to be 16 microns long in your print. Exactly how good is your printer? ;)
<UltimateCodeWarr>
Sounds like I made a lot of Rookie Mistakes
<UltimateCodeWarr>
The Goal is to create some sort of screen like structure to allow air to be sucked in to an enclosure, but not allow a bunch of bugs in.
<InPhase>
Mistake one, getting 16GB of RAM instead of upping the RAM investment at computer purchase time. RAM is great and relatively cheap. :) But setting top level $fn is almost always a mistake too. Trust $fs and $fa, and tweak $fn manually only in special cases.
<pca006132>
there will be work to improve memory usage, but that will probably take months to pull off
<InPhase>
pca006132: Is there identifiable waste?
<pca006132>
yes, our code to detect collision reports many false positives
<pca006132>
but that is not easy to fix
<pca006132>
(we know how to fix it, theoretically, but takes time to do it)
* InPhase
nods.
<InPhase>
And there are heavy allocations then to track the combinations of mutual collisions?
<InPhase>
Does that mean I can make RAM usage get worse with manifold if I do something pathological like criss-cross a whole lot of long slender faces?
<pca006132>
yes
<pca006132>
well, cylinders are typically like that when not axis aligned
<InPhase>
Oh, hmm, yes.
<pca006132>
we know it for quite a long time, but busy working on other things first
<InPhase>
Maybe we should use peepsalot's peppermint stick model from the 2019 calendar as a RAM tester. ;)
<pca006132>
and existing users rarely encounter this issue... e.g. for openscad, existing scripts don't do this because they cannot get the thing rendered with CGAL in a reasonable amount of time anyway
<peepsalot>
lol was it that bad?
<InPhase>
peepsalot: Well if you're trying to figure out intersecting faces by a grid or something. ;)
<InPhase>
What could be worse in RAM per facet than a disordered pile of peppermint sticks?
<peepsalot>
ah, yeah i missed the context of the rest of the discussion
<pca006132>
it depends, it can get to n^2 in the worst case
<pca006132>
you need some high resolution sticks though
<InPhase>
pca006132: Well, you're still beating CGAL on the peppermint sticks. I don't know what it's going to climb to, but it's already 3 times what Manifold needed.
<InPhase>
CGAL might take a while on this one.
<pca006132>
did you try fastcsg?
<InPhase>
Nope.
<pca006132>
I guess nef polyhedron is using a rather large data structure for each facet...
<pca006132>
so it probably uses a lot more memory per mesh already
<peepsalot>
nef allocates 2 multiprecision integers (to form a single rational value) for each component of each point
<peepsalot>
and all the damn pointers to go with that insanity
pca006132 has quit [Remote host closed the connection]
<peepsalot>
so every operation is just constantly allocating and deallocating millions or billions of (for the most part) 8byte chunks
pca006132 has joined #openscad
<InPhase>
Wow, I really don't miss these CGAL runtimes. I almost forgot what this was like waiting so long at 999. :)
<InPhase>
I was just trying to get it to finish so I can report the max RAM ratio.
PolyBytes has quit [Quit: Client closed]
J24k43 has joined #openscad
J24k92 has quit [Ping timeout: 256 seconds]
<pca006132>
InPhase: how long does it take?
pie_ has quit []
pie_ has joined #openscad
misterfish has joined #openscad
misterfish has quit [Ping timeout: 265 seconds]
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
misterfish has joined #openscad
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
misterfish has quit [Ping timeout: 246 seconds]
Yasmin has joined #openscad
Yasmin has quit [Client Quit]
misterfish has joined #openscad
misterfish[x] has quit [Quit: Gateway shutdown]
arogora has joined #openscad
killjoy has quit [Ping timeout: 252 seconds]
arogora is now known as killjoy
killjoy has joined #openscad
killjoy has quit [Changing host]
misterfish[x] has joined #openscad
misterfish[x] has quit [Client Quit]
misterfish[x] has joined #openscad
J24k35 has joined #openscad
J24k35 has quit [Client Quit]
J24k has joined #openscad
J24k43 has quit [Ping timeout: 256 seconds]
mmu_man has joined #openscad
misterfish has quit [Ping timeout: 252 seconds]
misterfish has joined #openscad
L29Ah has quit [Read error: Connection reset by peer]
L29Ah has joined #openscad
<InPhase>
pca006132: Turned out to be 71 minutes with CGAL as opposed to under a minute with Manifold, and 27366 MB with CGAL, while 1262 MB with Manifold.
misterfish has quit [Ping timeout: 260 seconds]
greenbigfrog has quit [Ping timeout: 252 seconds]
greenbigfrog has joined #openscad
<pca006132>
wow
<InPhase>
Yeah...
J24k has quit [Quit: Client closed]
J24k has joined #openscad
ccox has joined #openscad
ccox_ has quit [Ping timeout: 264 seconds]
misterfish has joined #openscad
<InPhase>
pca006132: FYI, my script to launch openscad does: log_scad_mem "$OPENSCAD" "$FILE" "$@" where log_scad_mem is: https://bpa.st/QUTOW
teepee_ has joined #openscad
<InPhase>
pca006132: This is how I both extract and keep track of the max memory consumptions. I get a nice datestamped log over time of every run I did, including which executable I ran (repos in different directories), which model, and how much RAM it used.
<InPhase>
pca006132: Obviously there's going to be variability based on things like whether or not I even pressed render. But this is still very handy.
<InPhase>
One could also automate this sort of thing for command-line testing if one were going to be playing around with memory improvements in Manifold. :)
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
<pca006132>
I see
<pca006132>
I typically just `time` it, for a rough idea of how the timing and memory consumption is
<pca006132>
if I need more detailed results I typically just open my profiler
<Scopeuk>
I guess there may be value in running the core test suite with that sort of instrumentation to observed if anything has cause a massive change in memory/throughput
<pca006132>
yes, but the core test suite is typically not too time consuming, so it cannot reveal issues unless the issue is very obvious...
mtm has quit [Ping timeout: 246 seconds]
<pca006132>
and the problem with CI is that the spec of the machine is inconsistent, so timing results on those machines differ from run to run, and the only way to get a more consistent timing is to run the old and new code together for comparison
<pca006132>
for manifold it may be fine, but for openscad this will make the build time even longer
UltimateCodeWarr has quit [Quit: Client closed]
<pca006132>
InPhase: do you have the data for fastcsg? I think fastcsg should use less memory than nef
mtm has joined #openscad
<InPhase>
pca006132: I'll try it.
<InPhase>
Popping lots of errors though: ERROR: [fast-csg-remesh] Failed to collect path around patch faces, invalid mesh!
<InPhase>
pca006132: 47 seconds, 1897 MB for fastcsg.
<InPhase>
pca006132: I went back to check the Manifold time because I didn't remember it. It was actually 0.37 seconds
<InPhase>
0.37 seconds vs 71 minutes is one hell of a performance difference ratio.
<InPhase>
14200 times faster. lol
<InPhase>
I've seen amazing differences, but that's the first ratio I remember seeing with 5 digits.
<InPhase>
Especially considering this was not a rigged design, but just picked off of the calendar (with some selective thought).
<pca006132>
true, pretty crazy
<pca006132>
fastcsg is pretty good, we are only 127 times faster :P
<InPhase>
lol, right.
<InPhase>
peepsalot: ^ You might be amused by those numbers on your model.
<pca006132>
I think when we were comparing manifold against CGAL, we typically compare fastcsg
<pca006132>
nef just makes everything boring, and for anything that requires more than a fraction of a second in manifold, it will at least take several minutes with nef
<pca006132>
in fact, when I was testing for regression previously, I didn't even bother running with fastcsg...
<pca006132>
the entire benchmark suite already takes half an hour or something, and running fastcsg will increase that time to something that takes an entire afternoon
<pca006132>
so I just compare against the previous version with manifold enabled
Virindi has quit [Ping timeout: 252 seconds]
myosotis has joined #openscad
greenbigfrog has quit [Ping timeout: 246 seconds]
greenbigfrog has joined #openscad
Virindi has joined #openscad
mmu_man has quit [Ping timeout: 246 seconds]
<InPhase>
pca006132: Yeah, that certainly makes sense. And it's better to give yourself a more aggressive target to beat. For OpenSCAD purposes we also have a benefit of comparing against old-style CGAL, because this reveals the amount by which users will be blown away by the comparison between last release and the coming release.
<InPhase>
pca006132: I'm also particularly interested in the weirder comparison of OpenSCAD preview times and Manifold render times, because I want us to be able to purge the entire preview subsystem. Even though these do not do the same thing, and thus it's not a "fair" comparison, it is still a pragmatically useful one for this purpose.
<pca006132>
J24k: I guess this depends on how you wrote it
<InPhase>
pca006132: I'm pretty pleased with these comparisons so far, and think it's at the right level to justify such a purge. But I also think we should keep watch for pathological cases where Manifold might be much worse than preview, so that we can assess if any of them are easy enough to hit to need addressing.
<pca006132>
InPhase: yeah definitely interested in that as well, it would be nice if you can find such a case
<J24k>
it is a 2D extrusion that is intersected with a rotate_extrusion
<pca006132>
I would expect disabling top-level union can make preview much faster than manifold in some cases
<pca006132>
but it is a really special case, and not the general preview...
mmu_man has joined #openscad
<pca006132>
we can purge preview while keeping lazy union, the shader should happily accept multiple meshes
<InPhase>
J24k: ? What do you mean by a 2D extrusion? It doesn't look like a linear extrusion was used there.
<pca006132>
I'm trying to think of a case where manifold can be much slower than preview, but I feel that it is probably always faster... manifold rendering time is roughly proportional to the number of faces, but the same is probably true for opencsg as well
<pca006132>
maybe when there is a large mesh that is flat (2 faces for any rays from the camera), the preview can be a lot faster?
<J24k>
interesting only the difference renders in about 40sec or so - but reports Total rendering time: 0:00:00.974
califax has quit [Ping timeout: 260 seconds]
califax has joined #openscad
<pca006132>
J24k: this sounds weird...
<J24k>
the linear extrusion runs under a second .. but removing the spehere takes much longer but only reports 1second
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
greenbigfrog has quit [Ping timeout: 252 seconds]
greenbigfrog has joined #openscad
<pca006132>
J24k: apparently there is a huge boolean thing, and it took some time to allocate memory and sort things
<pca006132>
I guess you are hitting the issue I mentioned yesterday :)
<J24k>
so this https://bpa.st/U2KHS (the part on the image) need ~ 50sec but says 1sec render time if done with ! modifier .. but separated in code it gives the correct 52.823 seconds
<J24k>
putting a "!" in front of the difference - changes the render time displayed
<pca006132>
not sure why, in fact I am not familiar with how the render time is measured
<pca006132>
J24k: did you flush the cache?
<J24k>
as you said 1.108 sec is the render time but other things need to calculate before and with the "!" they are excluded from time measurement as it seems
<J24k>
yes .. flushed
<J24k>
without flushing you have a result instantly
<pca006132>
weird, render statistic starts to measure the time when it starts to compile
<pca006132>
which line did you add the ! modifier?
<J24k>
the first toplevel difference
<J24k>
so it doesn't change the object at all
<J24k>
it is the extrusion minus the sphere
<J24k>
line 30
<pca006132>
I see, weird
<J24k>
(just tried with CSG .. bad idea, guess with manifold you easy have designs that are not usable without anymore)
<J24k>
on the other hand in my early days i made designs that rendered over several days (like you do with video rendering 20yr ago)
<pca006132>
for some reason with !, it immediately triggers actionRenderDone
<pca006132>
but it still keeps evaluating other parts in the background for some reason
<J24k>
and only if on the difference.. putting it on the intersection (of the original complete design) or the color/union - the time is correct
<pca006132>
oh ok I think I understand now, probably because manifold is lazily evaluated
<pca006132>
and some not-yet-evaluated csg term is thrown out of the worker thread
ecraven has quit [Remote host closed the connection]
ecraven has joined #openscad
<Scopeuk>
teepee I think intel currently have some sku's which have the max voltage incorrect in microcode and they overvolt to the point of damage under high load. not sure exactly which sku's are affected
<Scopeuk>
no idea if amd also currently have issues, wouldn't be surprised
<UltimateCodeWarr>
is this the I9 chipset?
<teepee>
I only read about the security issue linked above
<teepee>
which sounds not so nice, I did not hear about the intel issue until now
<teepee>
so I'll stick with the raspis ;-)
<teepee>
I still ordered one of the new picos though, which also has a bad hardware bug but IIRC it's mostly when doing analog stuff so hopefully not a big deal
<teepee>
also it's 7€
<Scopeuk>
the new rpi micros was some weird bug with input resistance/capacitance related to the pull ups or similar. was really odd
<pca006132>
oh, the intel situation was pretty bad... if you look at their stock price
<pca006132>
iirc 13th and 14th gen were affected, and not only i9, but i9 were easier to brick perhaps due to more extreme voltages
<pca006132>
J24k: 7600X3D sounds good
<UltimateCodeWarr>
Crap, I just ordered the I9-13900 HP Elite Mini 800 G9 Computer
<pca006132>
hmmm... RIP
<pca006132>
but Intel released 2 microcode updates that hopefully fixes the issue by lowering the voltage limit
<pca006132>
(the first one didn't work so they released a second one a few days ago)
<pca006132>
be gentle to your PC I guess :P
<UltimateCodeWarr>
I can always return it to amazon, but it had the best config for the price. 64GB DDR5, 4TB SSD Drive
<InPhase>
J24k: First, I want to note that's a brilliant use of linear extrusion with scale to approximate a spherical mapping. Obvious in retrospect I guess, but that particular one never occurred to me.
<J24k>
Thanks, it is how you get a lens hood for cameras or these projection lamps
<InPhase>
J24k: Your model took me 14s to render.
<InPhase>
J24k: Which I guess isn't too shocking, given the nature of it. Smoothed interactions across multiple axes.
<othx>
J24k linked to YouTube video "Turning Spheres Into Squares—Stereographic Projection" => 1 IRC mentions
<J24k>
works also as colander if you like to sort small chips out - Ü
<InPhase>
J24k: The children do that for me. All the small chips are left in the bags on the shelf.
<J24k>
But did you get the chips or the kids?
<J24k>
i assume you are left with the crums
<pca006132>
UltimateCodeWarr: I thought buying different parts and build your own will be better than buying the whole PC from OEM
<J24k>
But in fact bowls with holes are nice for keys or stuff so they can't collect dust / debris
<pca006132>
J24k: it may be possible to use some manifold's features to speed up the rendering of this, but it may change the result...
<pca006132>
manifold supports mesh refinement and smoothing, which may allow you to do things in lower resolution and refine it later
<pca006132>
and there are ways to retain the sharp edges
<pca006132>
but probably not in openscad, and may require some experiments I guess
<J24k>
i am happy with 1minute render ( at least if that is not replacing preview)
<InPhase>
J24k: I've been thinking about the merits of a fruit bowl, with holes, to promote ripening without molding. I have a space for one. But also molding would happen, so I need one I can also clean. :) But I was just contemplating I could maybe print a nice one like your pretty design and then give it a good enamel spray coating.
<InPhase>
Printing and coating in black would probably work really well.
L29Ah has joined #openscad
J24k has quit [Quit: Client closed]
J24k has joined #openscad
<J24k>
or ASA and vapor smoothing (propanon or etylacetate) also NaOH is a great cleaning solution
<pca006132>
J24k: if you change fs and fa to the default preview setting and do render, it is still pretty fast
<pca006132>
probably the quadratic behavior
<J24k>
probably just the detail of that sphere
<InPhase>
Oh wait, do $fs and $fa impact that design, J24k?
<InPhase>
I actually ran it in my dev branch of master that has those defaults already changed.
castaway_ has quit [Ping timeout: 248 seconds]
<J24k>
sphere with $fa=3 is only ⅙ of the time
<J24k>
InPhase my lib is changing those
castaway has joined #openscad
<J24k>
if you set hires=true it will use $fa=0.5 and $fs=0.1
L29Ah has quit [Ping timeout: 255 seconds]
<J24k>
else 1 and 0.2
<J24k>
for that bowl size the sphere will have fn 360 segments
<J24k>
^2
<J24k>
or is it 360×180 probably
L29Ah has joined #openscad
<InPhase>
J24k: Ok.
<JordanBrown>
pca006132 you said "I would expect disabling top-level union can make preview much faster than manifold in some case..."
<JordanBrown>
Preview doesn't need to do any real work on union. It just throws triangles at the GPU.
<JordanBrown>
I don't think it can even have the concept of not-unioning, because it doesn't do any specific work *to* union.
kintel has joined #openscad
mmu_man has quit [Ping timeout: 246 seconds]
mmu_man has joined #openscad
L29Ah has left #openscad [#openscad]
mmu_man has quit [Ping timeout: 265 seconds]
mmu_man has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JordanBrown>
J24k note that typical 3D printers have a horizontal resolution of 0.1mm, so they can't even draw anything smaller than that - and a 0.2mm feature will always be represented as accurately as possible.
<JordanBrown>
I'd think that you'd need a magnifying glass to see an artifact caused by $fs = 0.5.
<JordanBrown>
If you could see it at all.
teepee_ has joined #openscad
<J24k>
JordanBrown please note that your math is wrong
<JordanBrown>
hmm?
L29Ah has joined #openscad
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
<JordanBrown>
What are you seeing that I'm not?
<J24k>
check what XY resolutions printer have
<J24k>
0.1 is maybe a full step - nobody is using that anymore
<JordanBrown>
OK, maybe my info is dated.
<JordanBrown>
Now you're going to make me go look it up :-)
<J24k>
slicer calculating with 0.012mm or 12μm resolution
<J24k>
accuracy is around .1 on a bigger part but that is a different story
<J24k>
you also have slicer converting to G2/G3 arc moves for max resolution - therefor you need higher resolution
<J24k>
"precision" is what comes out of your printer - after the slicer and mechanics .. it doesn't mean you can put something that rough into the slicer
<JordanBrown>
I'm still dubious that you can tell the difference between $fs=0.1 and $fs=0.5, but if the printer is stepping smaller than 0.1 I can't show it analytically.
<J24k>
Think about printing with a 0.2 nozzle .. that would mean half the nozzle is off
<J24k>
I had several prints where i was wondering about the ridges and facets .. turns out it came from the geometry not the printer
<J24k>
and DLP printer are in a much finer range too
<JordanBrown>
I'd blame inconsistent feed control before I'd blame the geometry per se. My (admittedly not all that extensive) experience is that my printer over-extrudes at the ends of segments.
<JordanBrown>
But finer geometry makes everything be an endpoint, so would be more consistent.
<JordanBrown>
If you've done print experiments that show that it helps, I sit corrected.
<JordanBrown>
It's unfortunate that we have to turn arcs into segments only to have the slicer turn them back into arcs. But I get that the Boolean ops are hard for segments and Really Hard for arcs.
<othx>
InPhase linked to "Fabric Weave Library by rcolyer" on thingiverse => 6 IRC mentions
<InPhase>
But yours with that curvy path should have enhanced flex.
<InPhase>
I was thinking TPU because it's basically unbreakable.
<InPhase>
Like if you made a TPU fruit bowl, picked it up, and slammed the whole thing on the floor, nothing would happen. And you don't have to make TPU very thick before you can't even break it with your hands.
<J24k>
for TPU bowl you need thicker struts to keep shape when filled with fruits
<InPhase>
Very nice in the video. Those are good properties.
<InPhase>
The reason I was contemplating "not quite a bowl" is because sometimes I try to keep fruit spaced out, so that mold doesn't jump between them. But the reason I was thinking a bowl was to keep the fruit from getting knocked onto the floor.
<InPhase>
I haven't mentally sorted out what the right balance between these is. :)
<InPhase>
Maybe a grid of recessed mesh areas with a rim? :)
<J24k>
knocked off .. sounds like an educational thing
<J24k>
stop playing ball in the kitchen!
<InPhase>
One of my aims is to reduce the number of things I have to repeatedly remind my children to do or not do. The mental load is a lot. :)
<UltimateCodeWarr>
-What about some hanging deep baskets, high enough where they have to ask you to fetch something for them?
<InPhase>
I prefer to encourage the consumption of fruit. :)
<J24k>
the fruit that lands on the floor needs to be eaten .. can't have both
<InPhase>
There was a stretch of time where my youngest, at 6, was eating about 2 pounds of cherry tomatoes a week.
<InPhase>
At that point I was concerned maybe it had gone too far. ;) But he was in good health.
<J24k>
evolution works fine if you don't add processed food .. i loved raw vegetables as a kid
paddymahoney has quit [Ping timeout: 276 seconds]
mmu_man has quit [Ping timeout: 244 seconds]
<gbruno>
[github] kintel pushed 19 modifications (Address some long-tail missing std::* includes (#5346) * Include `<variant>` in files missing it.