<linext>
also, how does an advent calendar numbering work>?
<linext>
25- days till xmas?
x__ has quit [Read error: Connection reset by peer]
<InPhase>
24
x__ has joined #openscad
<linext>
i saw someone posted about using chatgpt3 to write openscad code
<linext>
for the email mailing list
<linext>
i'm against promoting gpt3 because it's by a company called "openai" which is totally closed source
<linext>
openscad wouldn't be anywhere near as useful if it was written by a closed source private company
<InPhase>
linext: I tried to use opengpt to write an entry for the calendar. The only reason I didn't include the result is because it couldn't produce anything coherent.
<linext>
changing the incrementBy and spirals makes the biggest difference in style
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
omegatron has joined #openscad
<InPhase>
linext: Does your site no longer work in chromium?
<InPhase>
I was pretty sure I was mostly using chromium for it before, but now the render only happens on firefox for that link.
<L29Ah>
doesn't work in palemoon either
<L29Ah>
SyntaxError: await is a reserved identifier
<L29Ah>
The Web Console logging API (console.log, console.info, console.warn, console.error) has been disabled by a script on this page.
<L29Ah>
huh
<InPhase>
Well at least I didn't break my browser.
feuerrot has quit [Ping timeout: 246 seconds]
fling has quit [Ping timeout: 255 seconds]
feuerrot has joined #openscad
<JordanBrown[m]>
Does anybody know what the render progress reporting numbers *mean*?
<JordanBrown[m]>
(And yes, I know that all too often the step from 999 to 1000 is the longest.)
x__ has quit [Ping timeout: 255 seconds]
x__ has joined #openscad
<InPhase>
I did at one point, when I tried to fix that problem...
<InPhase>
I succeeded at leveling it out a lot, but then on complicated designs it would just go from like 0 to 10, and then pause a long time and jump to 1000.
<InPhase>
I decided that was even worse. :)
<InPhase>
All I remember at this point is that there was a count of actions to call, and the last one was top level union.
<InPhase>
I remember two problems with leveling it. One was that ultimately it would require something like counting the number of faces involved at each calculation step before performing the calculation to get there. The second was that it would require a separate thread that increments the progress bar as a theoretical guess based on this number that is impossible to calculate.
<InPhase>
The other option would be to do that separate thread, and update the heuristic guess as you go, which has the wonderfully confusing property of moving the progress bar backwards sometimes.
<InPhase>
At which point I abandoned ship and decided to not update the progress bar.
J22358929 has joined #openscad
<InPhase>
Although one thing I didn't think of at the time, which could be viable, is swapping the progress bar for a display like: "0:34 / 1:54" and just update the estimated time with a heuristic guess of how long it should take, updating that as we go. This could reasonably go upward without being jarring.
<InPhase>
The left number would just tick upward by a timer.
J223589 has quit [Ping timeout: 260 seconds]
<JordanBrown[m]>
Yeah, but can you get anything like a realistic guess, before you're done?
<JordanBrown[m]>
I suppose that a not-totally-stupid guess would be to retain the results from the previous render as a measuring stick, somehow. But that doesn't help on the first render, which is the one where you're saying "how long is this going to take?".
<InPhase>
Yeah, it would be tricky at the start. But presumably you'd actually have a really good estimate by the moment of the top level union that takes long enough to distress people.
<InPhase>
That'd be the only hope of such an approach to add value. It would require a lot of testing though to hammer out the right heuristic.
<ali1234>
hmm... i reduced the example down further and now i have something that renders a mesh with different polygons missing each time and only asserts some of the time. so this looks like memory corruption or something
<J22>
ali1234 roof can not deal with near points and while a negative offset shouldn't change the number of points it does something .. check this roof_for_height(1) offset(-0.03,$fn=50) circle(d=30);
<J22>
so just ran with $fs=2 and it works .. roof get problems if you are over 60 fragments but it depends on the size of the object too
<J22>
funny even an offset (0) is causing a render error
peepsalot2 has quit [Read error: Connection reset by peer]
castaway has quit [Ping timeout: 272 seconds]
snaked has joined #openscad
la1yv has quit [Ping timeout: 256 seconds]
la1yv has joined #openscad
<InPhase>
ali1234: Before concluding it is inconsistent, make sure it is inconsistent with a flush each time.
<ali1234>
what do you mean?
<ali1234>
if i don't flush the cache it never re-renders
<InPhase>
If you do not flush the cache, then one run and the second run are not identical.
<InPhase>
We have lists of issues where cached items cause unexpected problems. It's rare, but one can design to hit it.
<ali1234>
it is actually reproducible quite easily: start openscad, load the example, render, flush cache, render
<ali1234>
the first render is different. after that it is always the same