<lf94>
All right, day 7, let's see what you've got!
<InPhase>
:)
<lf94>
Hm
<lf94>
Interesting shape
<lf94>
I feel curv will be strong here
<lf94>
I just don't know what I'm twisting lol.
<lf94>
Could maybe twist two cylinders and smooth union to a sphere.
<InPhase>
This was definitely the most "wait... how did you do that?" one for me of this year's set.
<lf94>
Yeah I looked at the openscad code and it's pretty much non-sense to me
<lf94>
circle and square are 2D operations right?
<InPhase>
Yes.
<lf94>
I forget so much of openscad. I can't believe I was making stuff like L-Systems in the language
<InPhase>
Jack21 likes to hide the key steps with a lack of whitespace. :) In this case, the rotate_extrude is hiding to the right of the rotate([-90])
<Jack21>
not intentional
<lf94>
I need to implement `spiral` or something
<InPhase>
Jack21: :)
<lf94>
What's the render time on this one - instant?
<lf94>
I would even be stuck if using cadquery for this one.
<Jack21>
for me the amount of space other use makes it confusing - but i am sure i can adapt
<lf94>
My brain just can't imagine how the very nice merge between the swirl and sphere happens.
<InPhase>
Preview 0.115s, Render 1 min 42s with 2.3GB.
<InPhase>
Yeah. That superb alignment is why my brain couldn't parse how it was done. But it falls out naturally from the symmetry of the 2D input.
<Jack21>
without the offsets for rounding it is probably much faster
<Jack21>
sphericon may help to understand
<lf94>
I'll look
<lf94>
I'm literally at a loss for what to do
<lf94>
Mapping things onto spheres breaks my brain
<dTal>
I take it you've already done them all? I can contrbute this year if you'd like
<Jack21>
dTal yeah we need to start earlier next year .. i think this is so much better if more and different styles are represented
<Jack21>
maybe teepee or inphase are taking registration offers?
<teepee>
I have no problem creating a repo for next year already :)
mhroncok has quit [Quit: Leaving.]
mhroncok has joined #openscad
Guest82 has joined #openscad
Guest82 has quit [Client Quit]
<Jack21>
maybe not a bad idea
<teepee>
so who want's an invite for that? :)
* Jack21
is winking
* teepee
goes fiddling with the user access setup...
<teepee>
ok, I hope I did not mess up the access, now going via a team/group list
<lf94>
I find this year has been very christmasy
<lf94>
Except day 2. XD
<lf94>
Jack21: the inner radius is rounded?
<Jack21>
So my lib documentation is mainly finished - maybe a wiki would be needed for more
<Jack21>
lf94 ok - looks a bit weird on the image like a big outer radius and a very small inner
<Jack21>
ah no it is where both radii meet that doesn't look smooth
ToAruShiroiNeko has quit [Ping timeout: 256 seconds]
ToAruShiroiNeko has joined #openscad
<Jack21>
teepee great naming !
<InPhase>
We could make a calendar reservoir, and then select from it aiming for diversity of content come the season's time.
<teepee>
right, good idea, if it turns out the thing is going to overflow, we can create a reservoir repo
jkent3 has joined #openscad
<InPhase>
Reflecting on the nature of git history, maybe we should rename the one you just created into a reservoir, and select out of it in the other direction?
<teepee>
done
<InPhase>
*thumbsup*
snakedGT is now known as snaked
<JakeSays>
whats a reservoir repo?
<teepee>
a place to stash designs until they may be used in some other place, specifically for next years advent calendar
<JakeSays>
ah ok
<InPhase>
That word choice flows from me automatically from my physicist training. :) teepee's choice of "-designs" in the repository name is probably more standard.
<InPhase>
It hits both ways. Once while using "implement" as a verb in ordinary speech a physics prof called me out on it as not making sense. :)
<Jack21>
open the gates and flood the reservoir - Ü
mhroncok has quit [Quit: Leaving.]
<teepee>
but first we admire the cool stuff from this year
<teepee>
didn't I count 25 directories already, so maybe there's already one entry that could move into the pool
<Jack21>
( took ages to render so i thought i should change something for a better UX )
* teepee
feels watched now for some reason
lagash has joined #openscad
jkent3 has quit [Quit: jkent3]
jkent3 has joined #openscad
* Jack21
unwatches teepee
GNUmoon has quit [Ping timeout: 276 seconds]
linext_ has quit [Read error: Connection reset by peer]
jkent3 has quit [Quit: jkent3]
jkent3 has joined #openscad
<Jack21>
maybe only loop 10 times ending with eyes closed - Ü
lastrodamo has quit [Quit: Leaving]
GNUmoon has joined #openscad
<ccox>
profiled the F6 render of SphereEquation.scad. Literally 2 minutes out of the 6 minute time is spent calling "free".
<ccox>
unfortunately it's all inside CGAL and gmp libraries.
juri_ has quit [Ping timeout: 252 seconds]
ur5us has quit [Ping timeout: 252 seconds]
<InPhase>
ccox: Well that's why peeps is trying to swap in that custom malloc.
<ccox>
yep
<InPhase>
(If you didn't see that PR yet.)
<ccox>
I've seen a lot of discussion about it. Hmm, the pull request hasn't been update in 22 days.
<InPhase>
CGAL is extra wasteful because it was built by mathematicians around rationals which fundamentally require excessive allocations and can blow up on you in size. I really think the whole thing could be written with doubles if you just designed each operation a little differently.
<InPhase>
I bet CGAL with all doubles all the way through would run many times faster.
<ccox>
Yes, it could be written with doubles, but the edge cases that result would be insane.
<ccox>
yes, it would be quite a bit faster (50% maybe).
<ccox>
There are a few cases where it could be faster than that, but for most of what I've seen, the gmp and related allocations aren't more then 50%.
<InPhase>
Well it's not just that. There's a massive cache overhead on the rationals.
<InPhase>
This is harder to profile, but can be a massive impact.
<ccox>
yes, and on all the bad data structures used in CGAL and gmp. That time is accounted for in a sampling profiler, within some statistical limit.
<InPhase>
The cache effects can be leaky though, as they can drive out all the other things one wants in the cache, which in a profile can look like the other aspects slowing down.
<InPhase>
It requires some significant data size to do that, but we're totally on that scale.
<ccox>
No, it's not that simple. For a particular workload, the sampling process adds some time and some cache pressure, which is shown as extra time in the profile, plus any instruction waiting on cache data is shown as a slowpoint in the sampling.
<ccox>
Eh, you're on the small side of data for modern processors (a few Meg). I'll spend more time worrying about cache and TLB issues when you reach Photoshop/After EFfects size data sets (GB++).
<InPhase>
The Ornament.scad from last night was 2.3GB.
<InPhase>
I think it will take 20 minutes to measure the memory consumption of tonight's (which should be just in time for when it goes live).
<InPhase>
This is the sort of design that I expect to take very little memory for a while, and then explode in memory consumption toward the end. But I will try and see. (I just have to not forget and look away.)
<ccox>
It's only reporting 11 Meg in geometry cache, 80 Meg in CGAL cache, 2.4 GB total usage while rendering with CGAL.
<ccox>
OK, that's approaching Photoshop memory usage... in 2000.
<InPhase>
Does your report say what the bulk of that 2.4GB is?
<ccox>
yeah, the transient usage is insane. Worse is that it is scattered, so a lot of the pages are kept even after rendering, causing a little TLB thrashing.
<ccox>
Nope, I haven't done a breakdown by allocation size/location yet.
<ccox>
(save all the sampling profiles, restart with leak/memory profiling...)
<ccox>
(hold crap memory profiling slows this down)