<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]>
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?
<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
<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>
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)
<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 :-)
<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
<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
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
<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