02:18 <enthdegree> https://pastebin.com/znyXN8zz

02:19 <enthdegree> heres my awful solution (both a very ugly shape and a very ugly solution approach)

02:24 <enthdegree> thankfully what it supports is light enough to be held up short-term by the generic PLA the printer came with

08:51 <teepee> lol, I feel like I did not pay any attention lately. "Ultimaker Thingiverse" I totally missed that

08:51 <guso78_> yeahh, they have a new Cura version lately and make the "Tree" support standard, which i have been using for one year now!

09:05 <J23k13> the makerbot ultimaker merger was a while ago

09:07 <J23k13> DefunctAugust 31, 2022

09:09 <teepee> they supposedly put OpenSCAD update into the backog with "no promises when something will happen"

09:09 <teepee> which I guess is more than bot makerbot and statsys did the last 6 years ;-)

09:09 <J23k13> and so ultimaker is also part of stratasys

09:11 <teepee> oh, this way? meh

09:12 <teepee> almost time to learn Haskell then

09:14 <J23k13> there is something NPM capital involved https://investors.stratasys.com/news-events/press-releases/detail/793/stratasys-completes-merger-of-makerbot-with-ultimaker

09:18 <J23k13> NPM holds 54.4% Stratasys 45.6%

09:21 <teepee> so I guess it's pretty unclear how that will go mid-term. we'll find out eventually I suppose

09:26 <J23k13> Stratasys top 10 shareholders own over 30%  .. so  these company names are just a mask - as they are all  "shared"

09:34 <teepee> my impression is they just buy everything which even slightly looks like competition and then starve it until it's dead

09:35 <teepee> so basically I wonder if that means cura is dead

10:02 <J23k13> as NPM holds the majority and cura is going strong into cloud platform i assume they are safe for now  - however they got strong competition an their printer segment from bambulab and prusa is trying

11:09 <guso78_> have you seen the mail from terry, who wants to alter an existing STL ? difference() is the solution, but how to be accurate ? what about having  function, which can extract certain characteristics from an object like bounding box, center and even center of holes ? using this altering stl files will become more easier

11:25 <teepee> yes, at some point there was even some trying to convert to actual openscad code, but that was when G+ still existed

11:26 <teepee> never heard back from them

11:28 <teepee> there's that data = render() mod(); proposal which would even be nicer if that would not return a fixed structure but allow a function to be passed

11:28 <teepee> holes = render(detect_holes_function) ...

11:28 <teepee> bbox = render(calculate_bounding_box) ...

11:28 <teepee> or something like that

11:41 <guso78_> suppose the bbox detect function is easy. how would it look like ?

12:05 <teepee> the code already exists, the other infrastructure is the interesting part

12:15 <guso78_> suppose its available in any of the available libs.

12:15 <teepee> also in c++ code

12:19 <guso78_> ahh, misconception! when coding:  holes = render(detect_holes_function)  and render is an openscad languge fun, i thought that hole detect function is also openscad function

12:20 <teepee> render would be the built-in, the function passed in could be both in theory

12:20 <teepee> but we don't have code doing that so far (I think)

12:27 <guso78_> detecting the holes is just creating the difference of an objects hull with the object, check whrere the result touches the hull in 2 distinct placces and calculate the point of gravity from the selected objects. Actual implementation will be more complex than just my select_overlap function

13:53 <teepee_> guso78_: that hull only covers some special cases

13:56 <teepee> linear_extrude(8) square(40, center = true); difference() { linear_extrude(1) square(60, center = true); for (x=[-25,25], y=[-25,25]) translate([x,y]) cylinder(r=2, h=20, center = true); }

13:57 <teepee> maybe project in all axes to catch full through holes in axis direction?

14:19 <guso78_> https://stackoverflow.com/questions/2083771/a-method-to-calculate-the-centre-of-mass-from-a-stl-stereo-lithography-file

14:20 <guso78_> calculate the center of mass would also be very useful to have in openscad. it literally calculates the center point of of an object independant on the actual triangles represented.

14:21 <juri_> center of mass implies consistent materials.

14:21 <guso78_> yep, agreed. i assume  that the yellow material has same density in all the points :)

14:22 <guso78_> teepee, i like the projection approach. maybe clipper even has an option to extract holes.

14:45 <Scopeuk> center of mass really would need to go to your slicer

14:45 <Scopeuk> center of mass as juri_ says for a solid homogenous material is easy, not so much for a 3d print with the large number of rules that derive where material is and isn't deposited

14:48 <guso78_> Probably I expressed myself very bad. I am aware that an 3d printed objects is done with filling,  double perimeters etc.

14:49 <guso78_> I was referring to the center of gravity of the virtual objects shown in openscad window, not the actual printed object.

19:37 <Phoo> I want to overwrite a cylinder. Can I simplyfy my code?

19:37 <Phoo> module r_cylinder(h, r, r1, r2, d, d1, d2, fr=0.1){

19:37 <Phoo>     _d1 = d==undef ? (r==undef ? (r1==undef ? (d1==undef ? 0.0 : d1) : 2*r1) : 2*r) : d;

19:37 <Phoo>     _d2 = d==undef ? (r==undef ? (r2==undef ? (d2==undef ? 0.0 : d2) : 2*r2) : 2*r) : d;

20:00 <teepee> Phoo: maybe limit to a smaller set of options?

20:08 <Phoo> I just found out, that I can once overwrite the input parameter constant

20:11 <teepee> not quite overwrite, you get a new variable with the same name :)

20:11 <teepee> but the effect is the same

20:12 <teepee> there's also is_undef() in case you get warnings at some point

20:12 <Phoo> I see. because of the scope?

20:13 <teepee> yes, the parameters live in some sort of magic extra scope I guess

20:18 <Phoo> I have a polygon as an arument. Now I want a list, that is the polygon plus an offset of the polyong, reversed

20:18 <Phoo> Think of the frame around a polygon

20:20 <teepee> there is offset() - https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Transformations#offset

20:21 <Phoo> does it work on a list, too?

20:23 <teepee> no, BOSL2 is a big library which has lots of stuff handling vertices as lists

20:29 <Phoo> how can I use for() to create a list?

20:31 <teepee> list = [for (a = [0:3]) a * a]; echo(list);

20:32 <Phoo> ah. thanks.

20:33 <teepee> more details under the name "list comprehensions" https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/List_Comprehensions

20:36 <joseph_> teepee: I just got back from my summer travel, so I'm now about to address the feedback on my PR from a few days ago. I don't have any more major trips planned during the rest of GSoC. Also was your earlier comment about "transfering additional data through the manifold CSG process" directed to me or was that about what guso is working on?

20:37 <teepee> joseph_: that was to guso78, context like multi-color stuff or so

20:47 <gbruno> [github] jbinvnt synchronize pull request #4675 (GSoC 2023: Create VertexStateManager) https://github.com/openscad/openscad/pull/4675

20:51 <guso78_> joseph_, my changes are not relevant at the moment. i am in the progress of BIG refactoring. @kintel foresees a PolysetBuilder to create the Polysets instead.

20:52 <guso78_> there are more than 40 files changed and my doubts increase that this will be *ever*  acceptes even ctest shows pass :)

20:54 <gbruno> [github] t-paul pushed 1 modifications (Remove Debian 10, add Debian 12 and Ubuntu 23.04.) https://github.com/openscad/openscad.github.com/commit/614a5c6afbcfd5162fe9b375a868e81d98cc2042

21:00 <guso78_> ahh, different challenges defined now '=D '=D

21:32 <joseph_> teepee: The CircleCI branch-build has failed again. My PR can still get merged though, right?

21:47 <teepee> joseph_: yes. the issue with that is clearly the broken docker image, as long as the test runs are fine and no obvious build errors are shown, the merge is good to go

22:45 <joseph_> teepee: Ok, so is #4675 good to go?

22:47 <teepee> joseph_: yeah, I want to have another look at the whole files of the renderes, but I think the topics kintel raised were addressed and I did not see any additional things. plus the test cases are green without test-file changes

22:49 <teepee> so it might be a good time to summarize the next step you want to go