teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | https://openscad.org/advent-calendar-2021/ | Website: http://www.openscad.org/ | FAQ: https://goo.gl/pcT7y3 | Request features or report bugs: https://goo.gl/lj0JRI | Tutorial: https://bit.ly/37P6z0B | Books: https://bit.ly/3xlLcQq | FOSDEM 2020: https://bit.ly/35xZGy6 | Logs: https://libera.irclog.whitequark.or
<peeps[zen]> tcurdt: looke like that wiki page is just out of date. we moved from qmake (openscad.pro) to cmake since the last release
<ccox> the directions on the github readme are more accurate and up to date than the wiki, WRT macos builds
<teepee> no idea why someone copied the text into the wiki, I've removed that
<tcurdt> I just got a build working a few seconds ago :)
<tcurdt> and just updated the github issue
<JakeSays> openscad builds with cmake now?
<tcurdt> it does :)
<JakeSays> that's nothing to smile about.
<JakeSays> i can't stand cmake. i'd take bash scripts over it.
<teepee> good luck with those across mutiple platforms
ferdna has quit [Quit: Leaving]
<teepee> I'm not a huge fan of cmake, but it does cover at least some of the platform/compiler stuff
<JakeSays> cmake just sucks. pisses me off that qt moved to it
<tcurdt> I mean - I left that world of pain quite a while ago. But is there anything that doesn't suck in that realm?
<teepee> no, that's impossible
<JakeSays> yes. GN. i use it extensively.
<teepee> is that the google thing?
<JakeSays> yes
<teepee> that is not coming near any of the projects, end of story
<JakeSays> have you ever used gn?
<teepee> there is *no* build system coming out of google that will be of any use somewhere in the real world that is not google
<JakeSays> huh. that's awfully short-sighted.
<dalias> cmake is worse than everything except qmake, so ... ¯\_(ツ)_/¯
<teepee> reality
<ccox> according to goggle engineers, their build systems aren't even of much use INSIDE google. It's just the "flavor of the month" as new hires discover new toys and projects bigger than they can understand.
<JakeSays> teepee: it's not reality. not at all.
<JakeSays> ccox: well, most of google's public projects use gn, so not sure what that engineer was talking about
<teepee> I maintain stuff across multiple platforms and maybe 20 linux distros of different age going back maybe 5 years
<tcurdt> what's the project page of "GN"? it isn't very search friendly.
<teepee> that is absolutely impossible to do with anything google designs
<JakeSays> tcurdt: lol it's not.
<JakeSays> teepee: well, i don't envy you having to do all that maintenance, for sure.
<ccox> JakeSays: public != internal. I know more than a few Fellow and Senior Developers at Google.
* JakeSays shrugs
<JakeSays> tcurdt: that's the repo
<tcurdt> yup ... looks about right
<teepee> yeah, and the last paragraph clearly explains why it's incompatible at least with the linux distro world
<JakeSays> teepee: yeah that part is annoying. i've been working on the gn folks to fix that
<teepee> I don't know if that strategy is good or bad, maybe their "we always rebuild the world" is a better approach
<teepee> but it's inherently incompatible with other existing stuff
<JakeSays> not sure what you mean
<teepee> a linux distro ships libraries as separate packages
<JakeSays> right
<teepee> there's no "i have all the source repos and just build main branch" possible
<teepee> it's even forbidden by rule for some packages
<teepee> lib3mf includes a private copy of libzip and zlib
<teepee> at least one of those is flagged by the debian linter and will prevent the package to be shipped that way
<JakeSays> i'm not sure why that's an issue. gn isn't for building packages
<teepee> that's not the point
<tcurdt> "i have all the source repos and just build main branch" worked just fantastic for the go eco system (sarcasm)
<teepee> I'm say the google philosopy is "build the world from source for every app"
<JakeSays> why is that an issue?
<teepee> because it does not work outside google
<JakeSays> i dont understand how. i know many projects that work that way.
<JakeSays> what's wrong with building from source?
<teepee> again, it's incompatible with distro packaging, I can't just pull in library source from everywhere
<ali1234> nothing wrong with building from source, but the typical dumb CI pipeline that builds an entire VM then compiles every dependency from source then builds your app every time you make commit is just bad
<JakeSays> well, i understand it's not compatible with distro packaging, but that's not something most people have to deal with
<teepee> also for build time reasons it's a no-go, but that's just a minor point
<teepee> if you build your own stuff, that's fine
<teepee> I'm providing application builds for people to use in lots of different platforms, so people have a choice
<teepee> as I said, I'm not really saying one or the other is better
<teepee> but the google way is incompatible with pretty much any build environment I can use
<JakeSays> well, gn has nothing to do with how things are actually built.
<JakeSays> or which philosophy, etc.
<teepee> the official page says I have to download the build binaries from the google site
<teepee> OBS has NO network access at build time whatsover
<JakeSays> only if you dont want to build your own
<JakeSays> google just provides binaries if you want to use them
<ccox> ^ all this nonsense is why I stick with simple Makefiles and sometimes CMake (when it has to fit into another build system).
<teepee> and don't care about packaging in distros
<ali1234> all build systems currently in existence are terrible
<JakeSays> teepee: so your issue is it's not available in a distro?
<teepee> so to build on OBS I would need to maintain a gn package myself there so it can be installed in the build process
<JakeSays> or as a pkg
<ali1234> every single one is over-engineered
<teepee> one of the many points
<JakeSays> ok well i see your point, and for what you do it's an issue, but i don't limit myself to what is or is not available in a distro.
<JakeSays> ali1234: and yes, they are. lol. but that's to be expected
<JakeSays> i'll tell ya what's a real pain in the ass - un-twisting and stripping cat5 cables
<teepee> yeah, even with hands that's already annoying ;-)
<teepee> hmm, no response from CircleCI, I guess that means no answer this week
<teepee> oh, oops, missed the calendar door opening, did it work?
<teepee> whew
<tcurdt> so - I just realized my homebrew based build has references to those libs in homebrew ... that's not great :-/
<tcurdt> how is this done for the official release?
* tcurdt checks an official binary
<ccox> also beware: homebrew likes to install QT6, which will hose your build (multiple versions of Qt = pain)
<tcurdt> @rpath
<tcurdt> I know @executable_path and @loader_path - what is @rpath?
<tcurdt> ah ... define via LC_RPATH?
<teepee> that's the point, the simple homebrew build just builds with the homebrew dependencies which is fine for local use
<teepee> for distribution the script builds the dependencies with min-macos-version=10.13
<tcurdt> not even for that
<teepee> hm?
<tcurdt> "which is fine for local use" me: "not even for that"
<teepee> why not?
<tcurdt> that means the app is completely dependant of my homebrew libs ... that's not a great place to be at
<teepee> of course, if you build via homebrew, it uses the libraries installed that way, how else would that work?
<tcurdt> well, it could still bundle these up, no?
<teepee> I suppose you could, but that's not something provided by openscad build scripts
<tcurdt> what does the bundling via @rpath?
<teepee> it defines where the libraries are searched by default
<tcurdt> right - but the bundle needs to build for that as well
<tcurdt> hence my wondering
<teepee> the process would be the same as for the dependency build I would assume
<teepee> yes, but the bundle also needs builds with a sdk version range, not tied to the "whatever the build machine has"
<tcurdt> it seems the homebrew build references the libs in place, while a release build creates a bundle and references them in there
<teepee> yes, there's just too much point for bundling the homebrew dependency build as we can't distribute that anyway
<teepee> we could add some build script for that to the contrib folder, but there's no point in maintaining yet another build version
<tcurdt> sure ... right now I am just wondering where this happens in the build ... call it curiosity - for now :)
<teepee> I've tried to maintain and release the macos builds without having any reasonable access to a machine, so I really don't need more variations
<tcurdt> I can imagine :)
<teepee> macos-build-dependencies + release-common
<teepee> luckily kintel had some time to dust of some of the macos build stuff
<teepee> but that now means I can't even run the builds anymore, previously I could not build but run the bundles coming from the CI systems
<tcurdt> maybe back to the idea of a mac mini m1 as a ci runner? :)
<tcurdt> just need to find a sponsor for that
<teepee> if you find one, send it over :P
<tcurdt> :)
<teepee> in theory it would not need a M1 I think, it should be possible to cross build for both Intel+M1
<teepee> github might add M1 at some point, people asking like every 5 days or so
<tcurdt> but then github macos runner would already be enough
<tcurdt> tbh I never tried to build a cross platform build before getting a m1
<teepee> in theory yes, but getting all the dependency builds working via remote CI is not the amount of time I'm willing to spend
<tcurdt> well, at least not since powerpc+intel
<tcurdt> yeah, the feedback loop is not quite the same :)
<tcurdt> on the other hand - if one would get all to build on a real intel machine ... it should also work on the ci runner
<tcurdt> so if intel => intel+arm would work ... it might help with the ci situation
<teepee> depends
<teepee> right now there's also a struggle with build times, if that would go to twice the compilation time, that would be an issue too
<teepee> we'll see what the options at CircleCI are, github limits are quite generous still I think, but I'm not holding my breath that this goes forever
<tcurdt> more than 6h for build?
<tcurdt> and with an external runner the workflow limit should be 72h
<tcurdt> that said - external runners also come with some security concerns I guess
<teepee> depending on the performance and if it would build essentially twice, even 6h are not totally impossible
<teepee> the full MXE dependency build for windows does take about 6h
<teepee> although that is building the full cross build chain including mingw-gcc, so it's a bit more work that normal
<tcurdt> crazy ... sounds like external runners and proper artifact cachine could help a lot
<tcurdt> s/cachine/caching/ ... it's getting late
<teepee> yes, we do cache
<teepee> unfortunately that macos cache dropped after 15 days and now we can't rebuild as they limited to 1h runtime
<teepee> so the macos builds are back to fail due to missing cache
<tcurdt> oh boy :)
<teepee> with cache hit, it's maybe 15 minutes or so
<tcurdt> feels dirty just to write this but - how about caching it externally?
<teepee> lol, we had that till about 2 weeks ago
<tcurdt> lol ... and why didn't that help?
<teepee> it did, the internal one is nicer, at that point there was no info about the 1h limit that dropped without warning
<teepee> at least I did not see any, supposedly there was an email, but the ones I checked had no info
<tcurdt> that was with circle? and kintel is now working on a github setup? IIUC
<teepee> he did both
<gbruno> [github] t-paul pushed 1 modifications (Always create new cache key based on build number.). https://github.com/openscad/openscad/commit/17e201fa566da0fe29e890f24d1e8591088bb4f0
<teepee> the actual release build (as in non-snapshot version) actually was on github already
<teepee> but the snapshot builds would be better to have on circleci
<tcurdt> because? spreading the build time?
<teepee> pulling build artifacts to the file server and also not putting everything into one service
<tcurdt> ah ... what you wrote befure
<teepee> circleci did have very long timeouts before too, now just waiting while Travis pushes out everyone to github actions for them to restrict too
<tcurdt> well, as said ... I would just push the snapshot artifacts to the file server
<teepee> I don't like storing all sorts of credentials in random cloud services
<tcurdt> that would have the builds in one place ... would make maintaining them easier
<tcurdt> I am with you
<teepee> not really, it's just one or the other config file
<tcurdt> but there are options
<teepee> it would be nice for github to add a separate auth token that just allows downloading artifacts, I'd be happy to use that
<tcurdt> if that's a real concern you could setup openid for it ... that would still be push
<tcurdt> anyway ... time for bed ... if there a ways I am happy to help ... let me know
<tcurdt> would love to get that proper m1 build some time - and I am a fan of openscad :)
<tcurdt> later!
<teepee> gn
tcurdt has quit [Quit: Leaving...]
ferdna has joined #openscad
<lf94> ok, lets see day 4.
<lf94> more fricking cube unions! aaaaaaaagh!!
<ccox> hey, they can't all be singing and dancing (or marching cubes)
<InPhase> lf94: Hahah.
<InPhase> lf94: But not 100!
<lf94> InPhase: turns out the GLSL code that Curv spits out is _heavily_ inlined
<lf94> It does not output GLSL for loops, for example.
<lf94> So I'm fixing this now, even if it's not official. I re-did Day 2 and it renders when r = 2 without the hack.
<lf94> Today's will be simple to do
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
peepsalot has joined #openscad
Jack212 has joined #openscad
<peepsalot> the topic looks clipped short, is it hitting a character limit?
Jack21 has quit [Ping timeout: 256 seconds]
<lf94> topic?
<lf94> yes, it looks clipped.
<lf94> I would remove FOSDEM
<lf94> and Website:
<lf94> (just the prefix not the url)
teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | https://openscad.org/advent-calendar-2021/ | Website: http://www.openscad.org/ | FAQ: https://goo.gl/pcT7y3 | Request features / report bugs: https://goo.gl/lj0JRI | Tutorial: https://bit.ly/37P6z0B | Books: https://bit.ly/3xlLcQq | FOSDEM 2020: https://bit.ly/35xZGy6 | Logs: https://bit.ly/32MfbH5
<lf94> bit.ly is evil no?
<teepee> no idea, is it?
<lf94> l.openscad.org/aotehust would be better :D
<lf94> I think bit.ly has ads
<InPhase> How would it? The redirects are instant.
<teepee> well, someone register a new toplevel .scad
<teepee> then we can use l.scad/12ab
<Zauberfisch> good day
<Zauberfisch> is there a way to set $fn for import("file.svg")?
<Zauberfisch> I'm importing a circle, and I'd like it to be as smooth as possible
<teepee> I think that's not yet implemented, but yeah, it should be
<Zauberfisch> oof
<Zauberfisch> so not possible at all?
<Zauberfisch> I guess I could make it 100x the size, and then in openscad scale it down?
<teepee> I don't see scale making a difference
<teepee> but it would be possible to just do the conversion in inkscape
<Zauberfisch> hmm
<Zauberfisch> you are right
<Zauberfisch> ok, then I'll give up
<Zauberfisch> I'll have a designer do this
<teepee> :(
<Zauberfisch> I bought a 3d printer as a toy. but now I actually have a client asking for a print
<Zauberfisch> so there is a budget to pay a designer so I don't have to deal with this :D
<teepee> ok, that argument works :)
<gbruno> [github] t-paul pushed 1 modifications (Add qt5 multimedia and svg packages for MSYS2.). https://github.com/openscad/openscad/commit/0123eecd71b11b0bd9e7875bbeccf5b1ef38eac2
<Zauberfisch> (otherwise I do love openscad)
<Zauberfisch> but I don't have the motivation to try and mess around with this svg thing right now
<teepee> whew and we are green on macOS again
<teepee> that is really cutting it close
<teepee> build limit = 1h, build time for Qt5 = 56 min
<teepee> Zauberfisch: doing just the fun part is certainly the better option
<Zauberfisch> oh, unless someone wants to build $fn for svg import for like 50$
<Zauberfisch> I'd be willing to put that up as a bounty. but it's probably ridiculously low compared to the effort
<teepee> that's fine, that's why it's called bounty not full payment
<teepee> I would *want* to regardless of money, but I don't see the time for that
<teepee> 2 month vacation would help :)
<InPhase> teepee: I grant you permission to take a 2 month vacation from work!
<teepee> yeah, I know, I just have to take it before december 6th
<teepee> on the plus side, projects for next year seem to be stable, so hopefully no panic approaching ;-)
<teepee> which might be enough to eventually get something done
<InPhase> :) I wish you a peaceful time with good balance.
<InPhase> I'm entering a slightly more intense stretch of work for a little bit. It comes in waves at times.
<teepee> I've seen that. projects with big companies are always a bit fuzzy at the end of the year. on one side they tend to go into freeze mode with people in vacation, but also may want to spend some money to keep budget or need something quick to deliver for years revenue
<teepee> not sure how it will go this year with mostly a different big company in the picture :)
<teepee> normal plan for after christmas days would be CCC watching, which did not happen last year
<teepee> current estimation for this year... 50:50
<lf94> InPhase: Curv is kind of stepping on its own toes: if I used GLSL directly I could do those thousands of unions.
<lf94> I was able to render Day 2 with r = 5
<lf94> with Curv still - I was able to optimize it a few magnitudes
<gbruno> [github] t-paul pushed 3 modifications (Merge pull request #3991 from openscad/dep-build-timeout-macos
<lf94> I was able to render r = 10.
<lf94> So not far behind OpenSCAD. And that's with a very simple optimization
<teepee> ok, now do 50 :)
<lf94> Well the challenge asks for 20, so I consider it good enough for now
<teepee> there is no challenge
<lf94> is this a joke on "there is no spoon"? lol
<teepee> probably not as I have no idea what that means
<lf94> it's a challenge for me absolutely
<teepee> it's interesting that r = 50 is still ok-ish responsive in preview, but it would probably need centuries to mesh
<lf94> Since I'm working against Curv's design
<lf94> Mine could probably mesh fairly quickly
<lf94> How long does meshing for r = 10 take?
<teepee> that's fine, the calendar is something fun and maybe also something to learn new stuff
<lf94> Yeah absolutely :)
<teepee> what you do with that is totally up to you of course
<lf94> It's been fun to stress test this language
<teepee> the interesting question would be if the fast-union would make a difference
<lf94> Well I'm using a faster union than the unrolled union
<lf94> the issue is actually the GLSL compiler.
<lf94> not so much the unions
<teepee> Total rendering time: 0:01:18.829
<lf94> Ah shoot, I'd have to calculate bounding box
<teepee> or with lazy union:: Total rendering time: 0:00:00.433
<teepee> :P
<lf94> Nice
<teepee> but that's a bit of a corner case
<teepee> yeah, even after restart: Total rendering time: 0:00:00.284
<teepee> so it's not doing any union
<teepee> well, that's with 20 but it does not matter then
<teepee> 50: Total rendering time: 0:00:01.693 / Objects: 26148
<teepee> hum, 46MB STL file :)
<lf94> X)
<lf94> No problemo
<InPhase> But the color.
<lf94> I'm not bothering with color
<lf94> I just don't feel like it but curv can do it
<lf94> you just specify `colour <thing>`
<lf94> I mainly don't care because I can only 3D print in one color ;p
<InPhase> I was mostly wondering if the approach to color makes certain things tricky.
<InPhase> Like when you start coloring unions or differences, the rules are less clear.
<InPhase> Oh, and side tip.. OpenSCAD for loops are end-point inclusive, which is why the top block is out of alignment.
<InPhase> You're short one block.
<InPhase> I'd rather OpenSCAD loops not be inclusive, but alas, this is baked in hard by now.
<lf94> So are Curv actually, I went out of my way to make it exclusive XD
<InPhase> :)
<lf94> It's ok, doesn't change much.
<lf94> coloring the unions would be the same as in openscad
<lf94> essentially im coloring each cube and then unioning
<InPhase> The resulting code for this one looks pretty comparable.
<lf94> if I did do it
<lf94> yeah.
<lf94> Remember, Doug comes from an OpenSCAD background
<lf94> So there will be influence there :)
<lf94> (Influence in the language coming from openscad)
<lf94> I'm finding it easier to think in terms of "generate points", "generate rotations", etc, and then combining it all.
<InPhase> Or, could. Jack212 used a gratuitous module recursion there in what could have been a for loop, but probably mostly for demo purposes on how the rotations and translations stack.
<lf94> I could've stacked it for curv as well, using recursion
<lf94> Maybe I should try it
<InPhase> Tomorrow's should be pretty straightforward for you. The one after that I'm waiting eagerly to see you attempt. :)
<lf94> We're building up a nice test suite for Curv.next XD
<lf94> (Doug's next iteration of the language)
<InPhase> :)
<lf94> It's too bad you've seen them all
<lf94> Would've been nice for just teepee to know
<lf94> Is there /anyone/ else doing the calendar publicly?
<teepee> that would have been tricky considering I only did the html and admin part :)
<teepee> what do you mean?
<teepee> there lots of calendars like fpga, university doing physics videos, ...
<teepee> still only one post?
<InPhase> Wait, you see the one?
<InPhase> It shows me zero.
<InPhase> Weird. Even when I click the hashtag directly in the @OpenSCAD post the post containing that hashtag doesn't appear.
<InPhase> Twitter is such an interface mess.
<teepee> lol, yes, now it's gone, no idea why
<teepee> it did show the @openscad tweet
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
<InPhase> I see. You need a blue checkmark to be important.
<InPhase> Click some buttons and get a blue checkmark! :)
<teepee> haha, not in 1000 years
<InPhase> Is there an openscad@openscad.org or something?
<InPhase> Looks like the requirement is either domain email address that looks official, or the website mentioning the twitter account.
<lf94> teepee I mean anyone else doing the scadvent calendar you made
<lf94> teepee I only meant InPhase not knowing :)
ferdna has quit [Quit: Leaving]
<teepee> if it would be "the calendar I made" it would be just: return "" this year
<teepee> so much better result via teamwork
<InPhase> teepee: Looks like the notability requirement is easy to hit. OpenSCAD is all over the news in outlets with blue twitter checkmarks, so that should meet their standard.
<teepee> someone is trying to get that checkmark for quite some time to now avail... https://twitter.com/erzaehlmirnix
<teepee> at some point I may find the specifc post which looks funny
<teepee> but probably only after getting some sleep :)
<InPhase> The standard is different for organizations. They have it broken down by category.
<InPhase> If you show up in the news, you're set.
<InPhase> :)
<teepee> well, she has a book out on amazon, not news but still something :)
<InPhase> With individuals there were weird criteria about how you use twitter.
<teepee> yep
<teepee> also that "we have stopped the program" and still some people got it anyway - mixed signals
<InPhase> These are the instructions. But certainly get some sleep first. :) https://help.twitter.com/en/managing-your-account/about-twitter-verified-accounts
<teepee> I like that suggestion :)
<Jack212> zauberfisch:  for SVG you can just refine the path in inkscape and adding points with 2 clicks  ( it is not a  solution but a fast workaround)
<Zauberfisch> ok, thanks
<Zauberfisch> maybe I'll give it a try
<Zauberfisch> if it's really easy
<Jack212> https://imgur.com/MrAa7yG  would be more towerersque
<Jack212> zauberfisch just use the path tool and mark  all knots  - then click the +Add knot  symbol (first one on the bar) this will add knots between the existing and so double them ..  (you also can selectively adding them by just double clicking on the path. ( if it is an Object you have to hit ctrl shift c to convert into a path)
af has quit [Ping timeout: 252 seconds]
af has joined #openscad
arebil has joined #openscad
pa has quit [Ping timeout: 245 seconds]
pah has joined #openscad
lastrodamo has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
Guest828 has joined #openscad
Guest828 has quit [Client Quit]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
arebil has joined #openscad
pah is now known as pa
TheCoffeMaker has quit [Ping timeout: 252 seconds]
Jack212 is now known as Jack21
TheCoffeMaker has joined #openscad
TheCoffeMaker has quit [Ping timeout: 256 seconds]
TheCoffeMaker has joined #openscad
ferdna has joined #openscad
la1yv_b has quit [Ping timeout: 256 seconds]
la1yv_b has joined #openscad
<InPhase> Jack21: I bet a building following that sort of design would also be very earthquake and high wind resistant. The only challenge would be the elevator layout. :)
<Jack21> didn't califa looks a bit like that
<InPhase> Plus, every floor gets its own observation deck, which is kind of nice.
<InPhase> Without the twists.
<InPhase> The twisting would be a little harder to build, but would probably add sturdiness.
<Jack21> a good architect will always give the builders headache
<InPhase> :)
<Jack21> i think the new 3d elevator (magnetic propulsion) will be suitable
<InPhase> "So we need these at a 34.375 degree angle"
<InPhase> "Not 34, not 35, that makes the top not line up right..."
<Jack21> based on the golden angle as every sunflower
<Jack21> evolution of million years for optimal areal cover
<InPhase> I'm not sure why that works, but I recognized it as soon as I looked at the top-down view of your tower, before looking at the source.
<InPhase> Then I tested switching it to 35, and it did not look as nice.
<Jack21> but not sure that the top didn't line up .. it is just the next block missing
fling is now known as bedroller
<Jack21> btw i think PHI should be a constant in oSCAD like PI
bedroller is now known as fling
<Jack21> InPhase if you change the angle you also have to change the size factor as these are linked so every 3rd floor  is not piercing through the wall of the first
fling is now known as ciphersalad
ferdna has quit [Quit: Leaving]
<gbruno> [github] t-paul pushed 1 additions 6 modifications (Add JSON import.). https://github.com/openscad/openscad/commit/60586106e4cf86445cada53defd38623fb2f7b5d
<gbruno> [github] t-paul pushed 1 additions (Merge pull request #3992 from serkan-maker/master
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
<InPhase> Jack21: 34 degrees has that problem, but 35 doesn't, as it rotates a notch faster.
<InPhase> Jack21: I took special notice of the 137.5/4 because I first, in tribute to lf94's efforts, tried to guess the angle by inspection and got 35 degrees. Then I did a top level view and intuitively felt like this was one of those golden angle things. Then I checked the code and saw the one you used, and tried switching it up to my guess of 35. :) The side view looks fine, but the top is just... off
<InPhase> somehow.
<InPhase> Perhaps that is the scaling factor though, and shrinking it slower would make 35 look better from the top by almost aligning those vertices to the edge.
<Jack21> right  i also put in the rough number .. else would be 34,3769....
<InPhase> I suppose rotate(35) and s=s*0.882 works alright visually.
<Jack21> 360/ϕ²
<Jack21> yeah the changes are usualy not that much  - you get a steeper helical angle or shallower
<Jack21> with 35 it is likely that after  some floors it will repeat but no one would notice that
<gbruno> [github] t-paul pushed 1 modifications (Update German translation.). https://github.com/openscad/openscad/commit/9458a03f2427d71e11e91f0ef6661e9c47e35670
<Jack21> 2485°
<Jack21> for (i=[0:35:2485])rotate(i) translate([30,0])circle();
<Jack21> for (i=[0:34.3769:3600])rotate(i) translate([40,0])circle();
<Jack21> oh just found out about "segments" in linear_extrude - is that new, isn't mentioned in the docu
<Jack21> already worked around with a segmented square module for those cases
RichardP_ is now known as RichardPotthoff
<gbruno> [github] t-paul pushed 14 modifications (Merge pull request #3993 from openscad/translation-updates
<Jack21> So turns out the linear_extrude is now creating faces differently to 2021.01 version
<gbruno> [github] t-paul pushed 1 modifications (Update openSUSE downloads, now supported: Leap 15.3, Leap 15.4, Tumbleweed.). https://github.com/openscad/openscad.github.com/commit/fd344a63de60147e649a0189d9a81c56d479046c
<teepee> yes it does
<teepee> trying to not create crazy geometry, especially when using twist
<Jack21> damn
<Jack21> i exploited this
<teepee> :(
<teepee> how?
<Jack21> now it has flat sides ..  (done that 2017)
<Jack21> well the geometry was not clean but you could print it
<teepee> yeah, the not-clean part was the part that was reported as bug
<Jack21> probably a good thing  - it was a bit weird to build faces along the longer distance
<peepsalot> Jack21 i think you can still exploit it by rotating an extra facet angle
<Jack21> yes bit the sides getting very diagonal then
<peepsalot> also you can set segments=0 to disable it
<peepsalot> i'm pretty sure adding 60 degrees (for hexagon) should be exactly same as previous behavior, what does it look like instead?
<peepsalot> s/rotating/twisting/ hopefully that was obvious what i meant
<Jack21> no before the diagonal was along the longer side, now the face is constructed along the short side
<peepsalot> i know that. now try adding 60 degrees of additional twist
<peepsalot> i was the one that implemented that change btw
<peepsalot> oh, i think i see, that trick works for regular polygonal shapes, but maybe not with the smooth rounded tips of your shape
<Jack21> here in comparison https://imgur.com/a/UooZiOO
<Jack21> wait with twist=180 that looks like the other with twist=60
<peepsalot> no idea what i'm looking at there
<Jack21> this is the same code .. one with the old one with the current version
<Jack21> and with the rounded edges this goes awry as the first edge is now sharp and the following round
<Jack21> anyway i was just making use of some weird behavior  so it is good that it is fixed now ..  but we should mention the segments in the cheat sheet and documentation
<peepsalot> except your picture now only shows a single side instead of a hexagon. its really hard to follow what you are doing without any code to reference
<Jack21> sorry linear_extrude(50,twist=60,slices=1,segments=1)circle(10,$fn=3);
<Jack21> linear_extrude(50,twist=60,slices=1,segments=1)offset(3,$fn=36)circle(10,$fn=3);//  and with rounded edges this getting worse when twisting more
<peepsalot> yes, so for a triangle adding (360/n)=120 makes it act the same as before (60 vs 180 as you noted)
<Jack21> yes without the rounded edges this works
<Jack21> but with segments this is also looking nice
<Jack21> n=60*2;
<Jack21> linear_extrude(50,twist=-n,slices=+1,segments=100)offset(3,$fn=36)circle(10,$fn=3);
<Jack21> linear_extrude(50,twist=n,slices=+1,segments=100)offset(3,$fn=36)circle(10,$fn=3);
<Jack21> ok tried minkowski instead -- doesn't work well it is now frozen
<Jack21> with twist 179 minkowski is giving a similar result
<Jack21> so this is looking nice now but took over 30sec to preview https://bpa.st/ZWWQ
<Jack21> but i assume it is now without faulty edges
<peepsalot> also you could probably speed things up with a cylinder minkowski instead of sphere
<Jack21> the moment i pass the threshold like twisting the hexagon over 60° the minkowski need a long time
<Jack21> cylinder was ¾ faster
<Jack21> probably as the polyhedron is going from convex to concave so minkowski need more time
<Jack21> and shouldn't use segments - Ü
<Jack21> but looks funny
<peepsalot> yes i think minkowski requires convex decomposition internally
<Jack21> it is nice that you get now proper antiprism with twisting
<peepsalot> Jack21, also, maybe somewhat inconsenquential, but the old behavior was not necessarily always split along the longer side, but i think was tied to twist direction. you might even be able to emulate new behavior on previous release by negating the twist angle
ferdna has joined #openscad
<Jack21> in my case i used the superposition of negative and positive twist - they looked the same so far
<ccox> Just created a pull request for SVG import to use $fn, $fs, $fa (the changes went much faster than I expected).
<teepee> nice!
<Jack21> i assume for converting the curves they already used those internally
<teepee> no, it had just some hard coded values
<teepee> a bit like prototypes last for years in production systems :)
<Jack21> yes that is what i meant you just need to put variables instead of the hardcoded numbers
<teepee> ah, right, yeah, that quite possible, for sure for elipse/circle which I looked at yesterday
<teepee> still as the PR shows, quite some places to work through
<Jack21> hmm yeah i forgot it is not everything a path
<Jack21> wonder if the b-spline and bezier are different in SVG .. probably they are
<teepee> different?
lastrodamo has quit [Quit: Leaving]
<Jack21> you can have the same curve as b-spline and bezier  so just the control points change - and i wasn't sure if that is within the svg format or just something inkscape simulates
<ccox> I think it is simulated, because I don't see SVG supporting anything other than Bezier
<ccox> (SVG is basically Illustrator files as XML)
<Jack21> ah ok
<teepee> yes, SVG has cubic and quadratic splines, the path does support control point mirroring though, so they connect multiple splines
<teepee> cubic and quadratic beziers I shold say
<Jack21> so inkscape has some tag  to know what it used to create it
<Jack21> like "spiro path"  - wonder why you can't switch that later
<Jack21> wasn't aware that quadratic and cubic are different - thought they use cubic and just link 2 control points
<Jack21> maybe i should add this in my module .. so if p2 is missing p1 is used
ferdna has quit [Quit: Leaving]
<ccox> Now LGTM analysis is taking longer than the builds...
<teepee> yeah, it's a bit annoying, and it does not seem too useful either
<teepee> I do have a question about the CalcFn, it seems to ignore the fa/fs values
<ccox> yep, because in the cases that use it, we have no angles (just bezier curves)
<ccox> I couldn't think of a reasonable way to apply fa or fs in that situation.
<ccox> but improvements could be made in the future, now that the values are available.
<teepee> yeah, angle is a problem, $fs would be possible
<teepee> text has some heuristics based on the font size
<ccox> well, the function of $fs is a whole nother issue (either misdocumented, or mathematically useless based on the get_fragments_from_r code that uses fmax(fmin()) instead of fmax(fmax()) )
<ccox> And right now, the SVG import ignores text (text::set_attrs does not create any geometry)
<teepee> yep, only started to collect the data but it's not finished