00:03 <gbruno> [github] t-paul pushed 1 modifications (Merge pull request #4051 from ChrisCoxArt/master

00:03 <gbruno> [github] t-paul closed issue #4050 (Error highlight not cleared after fixing error in documents with unicode text before the error location). https://github.com/openscad/openscad/issues/4050

00:35 <Jack22> teepee sorry to hear ..  hope i got the tolerance right

00:43 <teepee> spiel = 0.2 seems a bit too sloppy, just trying some versions, now with 0.1

00:57 <Jack22> teepee  there is a min value (and r2) in flower which is smaller than the LED .. but maybe the parts are too small for the slicer (and nozzle) .. so the n value is 15 .. maybe try another

00:58 <Jack22> n=7  might work

00:58 <teepee> I'm testing with vertical holes, so resolution is not limited to nozzle size

00:59 <Jack22> vertical means the nozzle follow the curve of the pass mark  and these might be smaller .4  so the slicer will not move the nozzle there

01:00 <Jack22> resulting in a bigger diameter ..

01:01 <Jack22> the idea is that the small parts are squeezed when the LED is put in .. a smaller "spiel"  will make the outer part smaller  ( might work too but wasn't the idea)

01:03 <Jack22> Flower(5,r=LED/2+spiel,r2=LED/2-0.5,help=1,min=LED/2-0.1,n=7);

01:03 <Jack22> if the LED is 5mm  the inside is  just  4.8mm

01:13 <teepee> the spiel = 0.1 does work, trying the n=7 now

01:22 <Jack22> should make the contact area bigger so tighter

02:15 <teepee> still not a very clean print even though it was much slower, but the parameters seem quite good. very nice fit for both 5mm and 3mm

03:02 <teepee> ok, question, will we get enough starships to send all those NFT scammers to mars?

04:00 <dalias> isn't it easier and safer to send them out of the solar system?

04:01 <dalias> in any case you won't need many starships

04:01 <ccox> or into the sun?

04:01 <dalias> no, into the sun is the hardest

04:01 <dalias> because it's just 10 guys selling the same nfts back and forth between their 10000 sockpuppet wallets

04:01 <ccox> into the sun is just falling out of orbit

04:02 <dalias> there's no such thing as "falling out of orbit"

04:02 <dalias> being in orbit *is* free-fall

04:03 <dalias> work out how fast you're orbiting the sun right now. that's how much delta-v you need to stop orbiting so you just fall straight towards the sun

04:04 <teepee> not many raking in the big money maybe, but likely quite a number trying to unfortunately

04:04 <teepee> just saw that tweet about someone selling the eevblog URL

04:05 <teepee> so for extra fun, here's 2 of the grifters trying to get a bite https://opensea.io/assets?search[query]=openscad

04:06 <dalias> i think it's about 30 km/s

04:10 <teepee> yep, google says that's correct, 110 million meters per hour sounds better :)

04:28 <dalias> i computed it rather than googling :-p

04:32 <teepee> well, it's 2 * pi * au / 1000 / 365 / 24 / 60 / 60 :)

04:32 <teepee> but I would need to google au anyway

04:33 <teepee> it AE here

05:31 <greydigger> running OpenSCAD 2021.01 on macOS MacBook Pro has been working normally up to now. Tonight the viewport: translate = [ ... ] started incrementing in the x-direction automatically and continuously as long as OpenSCAD is the active window. This makes the render window viewport continuously scroll in the positive x direction (any object in the window

05:31 <greydigger> will just slowly move out of sight. I've restarted software, restarted computer, reinstalled software, nothing seems to stop continuous movement. This even happens without any model or file loaded. Did I do something wrong?

05:32 <ccox> Any chance you have a gaming mouse with extra buttons?

05:32 <ccox> or a wacom tablet with extra buttons?

05:32 <greydigger> No peripherals attached at all. just a power cord. nor via BT

05:34 <teepee> not sure why that would happen, but maybe just disable all the drivers in Preferences -> Axes

05:35 <greydigger> they are all unchecked. I assume that is what you are referring to.

05:36 <teepee> strange

05:37 <greydigger> That was an excellent clue though. I just saw the "Reset Trim" button in same place and hit that. BINGO.

05:38 <greydigger> much appreciated.

06:15 <ccox> bigger question for me is: how did his trim settings get messed up?

06:29 <gbruno> [github] psteiner opened issue #4053 (Viewport controls). https://github.com/openscad/openscad/issues/4053

06:40 <gbruno> [github] kintel pushed 1 modifications (Correctly install pkg-config file for uuid). https://github.com/openscad/openscad/commit/220497807813c399dddba49155f99f7997edf9e3

06:59 <gbruno> [github] kintel pushed 3 modifications (brew install meson). https://github.com/openscad/openscad/commit/a6021caa29f6a2047801b9ea476fa07b09e85a2a

07:37 <gbruno> [github] kintel pushed 2 modifications (More macOS build fixes (#4033)

07:38 <gbruno> [github] kintel pushed 1 modifications (Upgrade glib to 2.71.0). https://github.com/openscad/openscad/commit/48d9cfc252383d7758d3f38b83cab509ab9e76e7

16:36 <gbruno> [github] kintel pushed 1 modifications (Fixed comparison bug introduced by #4033). https://github.com/openscad/openscad/commit/06b5455c0b442ffa73be4e534036b56aa9cc94d9

18:05 <buZz> hehe, F5 render ; Total rendering time: 0:00:04.538 F6 render ; Total rendering time: 0:00:00.033

18:05 <buZz> or does 'flush caches' not flush all cgal/geo caches aswell?

18:07 <buZz> ah well, reopening did flush them , F6 now takes Total rendering time: 0:00:04.285

18:07 <buZz> and F5 does take longer, but marginally

18:07 <buZz> Total rendering time: 0:00:04.359

18:08 <buZz> https://pastebin.pl/view/raw/c085b650 <- this code

18:11 <teepee> hull() forces mesh calculation, so the top level is cached

18:11 <buZz> cached between a F5 and a F6 render you mean?

18:12 <teepee> yes, things like hull() or minkowski() behave like render() at this point, so unless the code part changes, the full mesh is available for both f5 and f6

18:14 <buZz> ahh, ok cool

19:06 <gbruno> [github] salamanders opened issue #4054 (Panic on latest beta (OSX) after a few minutes of usage). https://github.com/openscad/openscad/issues/4054

20:04 <buZz> final product ; https://i.imgur.com/SndmZjK.png

20:05 <buZz> tweaked slicer config some, brought printing time down to ~4 hrs

20:08 <teepee> not bad

20:08 <buZz> even on the 200x200x200mm at nurdspace, thats just a ~18-22hrs print for max bed size

20:08 <buZz> vs the ~4 day one i designed yesterday evening :P

20:09 <teepee> oops :)

20:09 <teepee> 4 days is at least a bit inconvenient

20:13 <dalias> that's only ~5.6 mm³/s

20:14 <gbruno> [github] kintel pushed 4 modifications (macOS dependencies: Update glib to 2.71 (#4032)). https://github.com/openscad/openscad/commit/d0be100cd25ab314e26aa0ed6d112098d6ae9bc2

20:14 <dalias> you can probably get it to 2.5x that even on a cheap printer with stock hotend

20:15 <dalias> btw teepee does hull always use render?

20:16 <dalias> it seems much much faster for me

20:16 <dalias> but maybe because i only take hulls of simple things

20:16 <dalias> and try to linear_extrude 2d hulls of circles instead of hulling cylinders, when possible

20:16 <teepee> yes, the preview code can't handle hull without actually calculating the mesh I believe

20:17 <dalias> for 2d there is probably a simplified way to compute hull making it cheap

20:18 <dalias> aside: for convex objects, hull of thin linear_extrudes gives you a cheap loft() :-p

20:18 <dalias> i used this for my new phone case because modelling the stylized curvature of the phone it had to fit tight to was such a pain

20:19 <dalias> just measured critical points and boundary conditions with caliper, then tuned the slices visually til i had a match :)

22:28 <gbruno> [github] psteiner closed issue #4053 (Viewport controls). https://github.com/openscad/openscad/issues/4053