teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | 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
<teepee> joseph_: not sure about the branch at this point, I suppose we'll get to that in case the project is getting a green light
<teepee> as for precondition - no, I don't think the existing stuff can or should factor into acceptance decisions, for this years proposal
<teepee> of course it would be something nice to have :)
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<linext> i found a bug in my corner rounding method
<linext> if the shape has inner curves and you attempt to hull the whole thing, the inner curves get lost
<linext> the curved top is supposed to follow the same shape as the middle section
<linext> is there a way to use hull on 2d shapes without filling in the inner curves?
<linext> i forget, but i think someone showed me a simple command to inflate/deflate a 2d shape slightly
<linext> oh yea, it's offset
snaked has quit [Ping timeout: 265 seconds]
<linext> hmmmm...
<linext> it would be nice if there was a function like hull, or an argument to hull, that keeps the 2D shape and merges only the one axis such as Z
<linext> i don't need to hull x-y, just the slices in the z-axis
kintel has joined #openscad
<kintel> joseph_ From my perspective (but I haven't read any small print of the GSoC contracts), the most important, by far, is to make contributions that make it into the codebase. I don't expect you to contribute time outside of the GSoC period, so let's just focus on making that time productive in terms of working on stuff that will be done
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<linext> anyone have a solution to making the slices into a smooth curve? https://ibb.co/BVmxtKQ
snaked has joined #openscad
kintel has joined #openscad
<kintel> As mentioned before, I _strongly_ encourage small and frequent PRs, as that shortens the feedback loop, and increases the change of stuff being merged.
<linext> if i rotate the slices so they are no longer x-y, could that work?
* peeps[zen] rummages through old gists
<peeps[zen]> ah here it is
<peeps[zen]> it only works on convex cross sections though
LordOfBikes has quit [Ping timeout: 248 seconds]
<linext> hmm
J237665 has joined #openscad
LordOfBikes has joined #openscad
J2376 has quit [Ping timeout: 260 seconds]
<InPhase> linext: Can you provide curve.svg?
<InPhase> linext: Perhaps I can teach you the ways of the force.
<joseph_> teepee kintel: Personally I think it would be best if I can get last year's PR merged sometime during the "community bonding period." An unfortunate reality of the scheduling this year is that GSoC got shifted earlier and my university calendar got shifted later. GSoC begins on the first day I'll probably be back home after the semester ends
<joseph_> So it's almost unavoidable that I finalize the old PR while the semester is still ongoing. One additional factor I'm aware of is that kintel previously mentioned being unavailable during the summer. If I respond to the code review in early/mid May would you still be able to comment and/or approve?
<linext> InPhase, also this is the code that makes the curve: https://www.3dcustomizer.net/paste/98A64023
<InPhase> Excellent.
<InPhase> Even better.
<kintel> joseph_ I'm available until June 22nd. After that I may check in from time to time, but I'll be in the bush for stretches of time, so don't expect any signal from me.
<kintel> In terms of getting last year's PR merged, it's doable. As a start, I tend to suggest pulling out any valuable refactoring into a separate PR, just to make the critical part as small as possible.
<kintel> There are some challenges needing discussion, e.g. the strategy of adding vertex attributes vs. rendering multiple meshes.
<kintel> Also, guso78[m] has been working on similar things (textures), also adding more vertex attributes, so perhaps try to figure out if there is any common ground makes sense.
<kintel> On top of all that, I recently discovered that introducing any GLSL into OpenSCAD's rendering pipeline causes quite large rendering bugs, due to OpenCSG utilizing the fixed pipeline. This may delay any merging of GLSL-related code into OpenSCAD. ..which is another reason for splitting up the PR and make the critical parts as small as possible
<kintel> ^ this _could_ mean that it's reasonable to _first_ embark on the OpenGL modernization project, before merging the shader functionality
<kintel> ..but there is significant work and exploration and refactoring needed until this is clear
<kintel> Oh, and I'm back Aug 16th, if that helps
<gbruno> [github] kintel pushed 1 additions 2 modifications 1 removals (Minor cleanup of github CI files, only run the expensive CodeQL test on master push and weekly) https://github.com/openscad/openscad/commit/3b1cf06ed0aa2b0a4a09becddf550dd1aedee7a7
<kintel> teepee & al: I just noticed that Admins would automatically bypass branch protection (see above accidental push). I've since adjusted protection settings to _not_ allow automatic override of branch protection: https://github.com/openscad/openscad/settings/branch_protection_rules/25335026
<kintel> (in case someone needs to break glass and push without going through a PR, this can be temporarily disabled)
<InPhase> With great power, comes great breakage.
<kintel> Not everyone can yield that kind of power Sunday evening after a few beers ;)
<kintel> *wield
<InPhase> kintel: Indeed, indeed.
<InPhase> linext: https://bpa.st/23RV6
noonien has quit [Ping timeout: 276 seconds]
<gbruno> [github] rcolyer opened issue #4620 (fast-csg resize no-op) https://github.com/openscad/openscad/issues/4620
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Fleck has quit [Ping timeout: 255 seconds]
Flecks has joined #openscad
qeed has quit [Remote host closed the connection]
<gbruno> [github] gsohler synchronize pull request #4601 (Python delivered in tiny bites) https://github.com/openscad/openscad/pull/4601
qeed has joined #openscad
guso78 has joined #openscad
<guso78> teepee, it appears, that alpha particle hit one of the manifold tests in https://github.com/openscad/openscad/pull/4601
<guso78> is it useful to rerun ?
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
hyperair has quit [Remote host closed the connection]
castaway has joined #openscad
agnes_de_lion[m] has joined #openscad
epony has quit [Remote host closed the connection]
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
juri_ has quit [Ping timeout: 255 seconds]
juri_ has joined #openscad
Guest2 has joined #openscad
Guest2 has quit [Client Quit]
tcurdt has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
epony has joined #openscad
L29Ah has left #openscad [#openscad]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<guso78> teepee, thanks! Suppose the answer is not "no"
L29Ah has joined #openscad
<teepee> indeed :)
<teepee> yeah, we hopefully can find the root cause for those, although I thought kintel disabled that specific one already
<teepee> ah, that was an issue, not a PR - https://github.com/openscad/openscad/issues/4614
<teepee> so the strategy is the instrumentation stuff, it's probably hard to catch otherwise
<guso78> glad to learn, that my intent got a nice side-effect :')
<guso78> BTW did you realize the concept to store the hashes of trusted files  into QCachedSettings and the menu action to revert all that trust ?
<teepee> I saw the discussion but was travelling the last couple of days so I did not really follow what was going on
<teepee> group of people having fun with old retro computers from (mostly) east germany getting old ;-)
<guso78> ok np. InPhase has elaborated some details on how to make the all "User Flow"  around  trusting and untrusting files.
<guso78> Last concern was if you are fine with storing the Hashes in QSettingsCached (~/.config/openscad/openscad.conf or similar under linux) or  if  they have to move to antother place)
<teepee> if it's a gui feature, that sounds like the reasonable place
<teepee> I don't know if there are any size restrictions for that
<guso78> teepee, my 1st computer was C64 because my father decided to get one. he used it to do the book keeping as follows:
<guso78> 1 dim expense[40]
<guso78> 2 expense[1]= 34,3
<guso78> 3 expense[2]=34,1
<guso78> one line per expense. some time later he learned about how to save to files
<teepee> I had one a bit later, but initially it was difficult to get those from the bad western zone :D
<teepee> so first one was https://en.wikipedia.org/wiki/Robotron_KC_87 - built in Dresden and possible to buy for crazy money
<guso78> wow! 2.5 times faster than c64 O:3
<teepee> not really, powerfull cpu instructions but most required many cycles
<teepee> also no special chips like sid and vic, so the actual *home* computer use was quite limited
<Scopeuk> wow someone made a keyboard that looks worse than the zx spectrum
<guso78> i remember  very well as i sometimes have copied opcodes bytes directly from a magazine into a basic code line and somehow and finally i was able to save  it as a game onto the floppy drive(yes there were checksums to give it a chance at all)
<teepee> Scopeuk: yes, no available resources producing the same result as going for the cheapest thing you can get away with :)
<teepee> yes, c64er had also that listing thingy with sometimes many pages
<teepee> east germany had no notion of software rights or licenses so in that respect lots of copying was going on
<teepee> that said, some of the official tapes with software had huge pricetags
<Scopeuk> I can attest from having see some quite large containers of copied taps and disks in my time that the uk didn't have much of a concept of it at the time either (amongst the populous)
tcurdt has quit [Quit: Textual IRC Client: www.textualapp.com]
<teepee> and uk had their very own special list of computers, and quite interesting ones at that
<teepee> like one of the people at the meetup last weekend got one of those acorn machines
<Scopeuk> those were supper common, schools used them in massive numbers
* Scopeuk has good memmories of playing lemmings on them
<Scopeuk> the company is still doing rather well for itself (a few rebrands laters) acorn risk machines -> advanced risk machines (ARM)
<guso78> haha, i think it was on CGA or EGA resolution ...
<teepee> yep, I now, it's like a baby raspi :)
<teepee> I'd love to have one of those acorn archimedes and a bbc micro, but then there's no time anyway
<Scopeuk> I am just old enough to have run into bbc micros at school
<Scopeuk> some of my earlist programing experience was about age 8 or 9 programming a bbc micro in basic to drive a seven segment display plugged into one of it's expansion ports
<teepee> rich parents (B)?
<Scopeuk> the resistance materials (wood/metal working) teacher was very techy (he became an it teacher later) and had a retired bbc micro in his workshop with some custom hardware he built next to it
<teepee> well, I don't know how it worked, I only saw a video how they had the "cheap-ish" A and the full B version
<Scopeuk> this would have been in the early 2000's
<Scopeuk> ok one of those numbers is wrong
* Scopeuk must have bene slightly older
* Scopeuk was not born in the 90's
<teepee> :)
<guso78> haha, my age is available in the chat ..
<Scopeuk> I remember quite vividly in primary school (age 6 or 7) learning how to load applications from disk on a bbc micro and feeling like some sort of super techy
<Scopeuk> machines of that era are objectively awful but you were a lot closer to the machine. I think I could probably put togeather a course with a basic LA to wonder through the busses and operations of a bbc micro details every aspect of how it is working and what is going on
<Scopeuk> a modern machine does much the same but everything is so fast and so overlapped that you can't mentally model it
<linext> InPhase, thanks. another trick i figured out is that if the scaled slices are thinner than the printer layer height, it will come out smooth
<InPhase> linext: Correct. No hackery smaller than the printer resolution matters. But it sure looks different. :)
<InPhase> The difference might matter for selling things.
<guso78> teepee, my PR failed again with the exact same error. I believe you can use it to see the manifold error in more than 66%
J237665 has quit [Ping timeout: 260 seconds]
kintel has joined #openscad
J23 has joined #openscad
ricardo has joined #openscad
ricardo is now known as rhz
rhz has quit [Ping timeout: 260 seconds]
<kintel> guso78 Can you do it 3 times in a row? :)
* teepee tries that
<guso78> sorry guys,  it appears to be a "github permission thing"  but honestly ... better not to have all permissions O:3
<teepee> haha, no need
<teepee> the thing that failed was not 006 but 024 for the second run
<peeps[zen]> its funny those are my two goto benchmark scripts. they are notably some of the more computationally expensive from the tests / example code
<peeps[zen]> is increase in complexity directly proportional to increase in failure rate?
<teepee> hard to tell, there's not a huge amount of crashes (good :-)
<teepee> *reports of crashes
<teepee> whoops valgrind errors out: ==206633== Valgrind: debuginfo reader: Possibly corrupted debuginfo file.
<teepee> oh, clang issue generating unknown debug stuff
<peeps[zen]> if I bump my $fn to 32 in my example script here: https://github.com/openscad/openscad/issues/4617 I get errors in 5 out of 5 runs, but only 2 of 5 crashed
<InPhase> peeps[zen]: Yep. Threading failure opportunities, memory issues, and similar non-deterministic non-ideal bugs go way up with computational complexity. And the huge pile of interaction bugs goes way up with complexity.
<teepee> yeah, the interaction with cgal probably does not help either
<guso78> peeps[zen], I was able to get release_common.sh working in my place with some few tiny(but effective) tweaks. I am wondering very much, how the script runs without in other places, but i doubt anybody likes to elaborate on that XD
<peeps[zen]> guso78: runs without what?
<InPhase> peeps[zen]: The bug I just posted an issue for last night actually reduced down to a really simple case, but I only noticed it because of a random failure in a complicated script. Reducing it down it turned out to be fast-csg totally failing if and only if you pass it a child with more than one geometric element that has not yet been processed with a render. If you render, or pass only one child,
<guso78> i tweaked the release_common.sh script by converting some relative pathes to absolute pathes(using OPENSCADDIR) e.g. or commenting a command which works on 'icons'  directory, which i dont see locally
<InPhase> resize works fine. Probably this is just one of those type conversion issues, but from a practical perspective, it's hard to spot that kind of thing from testing without just throwing a lot of randomly complicated models in there and checking for failure.
<InPhase> peeps[zen]: Although we had a test that would have caught it if it had been run with fast-csg, but it wasn't.
<teepee> guso78: this does not seem to be needed in other places
<teepee> icons folder is inside the resources folder
<teepee> it needs to be run from top level source folder though
Joel has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
<guso78> teepee, yes, very likely.  but my local issue is that the script stops on any subcommand with an error and wont produce the final archive. this is why i commented the command with the icons locally.
<guso78> teepee, did not find the icons folder yesteday. anyway, i can check again in the evening.
Joel has joined #openscad
<teepee> argh, ffs Reason: Incompatible library version: git requires version 12.0.0 or later, but libintl.8.dylib provides version 10.0.0
<peeps[zen]> guso78: "failing fast" is typically preferable imo, but if you want the script to continue, comment this line: https://github.com/openscad/openscad/blob/master/scripts/release-common.sh#L27
<guso78> Ahhh,thank you for poining out!
<guso78> right now i am happy that none of the commands fail and actually i prefer to stay with this setting :)
<guso78> (y) (y) (y)
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
guso78 has quit [Ping timeout: 260 seconds]
epony has quit [K-Lined]
peeps[work] has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
ricardo has joined #openscad
ricardo is now known as rhz
<rhz> Hi #openscad. Good afternoon. I'd like to know if there's any library to read openscad models from another programming language. In particular, I'd like to count the number of sticks and sheets (both different types of cubes) that I used to create a model.
<teepee> rhz: directly no, but nophead uses additional text output that is then read as BOM via python scripts
<teepee> no = "not that I know of" :)
<rhz> thank you, teepee
rhz has quit [Ping timeout: 260 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ricardo has joined #openscad
ricardo is now known as rhz
<rhz> Is there a way in openscad to check that no cube intersects any other cube? I imagine one way would be to put the whole model in an `intersection() { ... }`
<rhz> It works :)
<teepee> yep, visual check that way works, but no "automatic" results
<Scopeuk> I guess you might be able to read the no geometry error when attempting an export
<teepee> well, the summary statistics would also give a zero bounding box
rhz has quit [Ping timeout: 260 seconds]
guso78 has joined #openscad
<guso78> pwd is clearly openscad source dir.
<guso78> is there any mechanism in place which finds icons directory inside resources dir ? i am absolutely curiuos, dont know such a shell scripting feature
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
guso7815 has joined #openscad
GNUmoon2 has joined #openscad
GNUmoon has quit [Ping timeout: 255 seconds]
guso78 has quit [Ping timeout: 260 seconds]
guso78 has joined #openscad
<teepee> guso78: that is probably unused code now as packaging is done via cmake
<teepee> so the icons folder was likely moved around after the code was not used anymore
<guso78> ok, i need to follow the cmake path. i am wondering why its not the "default" in my case ...
<guso78> teepee, finally i need to put textures onto the cubes and i will end up in ... (haha name missed)
<teepee> good question, the CI stuff does run the release-common script
<guso78> my platform for use with release-common.sh is 'Linux'
<guso78> *Minecraft*
<guso78> https://imgpile.com/i/h3GaFF quite some changes were needed to make it run in my place. maybe some hints to make the script more robust ...
Guest74 has joined #openscad
Guest74 has quit [Client Quit]
snaked has quit [Quit: Leaving]
usop[m] has joined #openscad
guso78 has quit [Quit: Client closed]
guso78 has joined #openscad
guso78 has quit [Quit: Client closed]
guso78 has joined #openscad
guso78 has quit [Ping timeout: 260 seconds]
peeps[work] has quit [Ping timeout: 260 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
snaked has joined #openscad