00:02 <lf94> https://forum.openscad.org/I-made-a-thing-unionRound-fillet-union-td33534.html

00:41 <InPhase> lf94: Sure, generating points externally can be very reasonable.

00:41 <InPhase> lf94: Metaprogramming offers great benefits in other languages, so it seems fine here as well.

00:42 <lf94> Even if you generate points you need to still connect them right

00:42 <InPhase> I have C++ code where I pregenerate source code with other C++ code. One can very easily write an array to spit out point data and stash it.

00:42 <lf94> I wonder how you'd do that for like a blob surface

00:42 <InPhase> lf94: Oh, well that's what the CloseLoop was built for.

00:42 <InPhase> s/CloseLoop/CloseLoop library/

00:43 <lf94> Aren't those libs slow though?

00:43 <InPhase> No, it's lightning quick.

00:43 <InPhase> It's typically faster than anything else you can do in OpenSCAD.

00:45 <lf94> It's like hull for points right?

00:45 <InPhase> Nope.

00:46 <InPhase> It's a single polyhedron call.

00:46 <InPhase> It takes the points, triangulates them, and calls polyhedron.

00:48 <InPhase> To achieve this it has specific requirements on the points. They must trace out non-intersecting layers (can be curved layers) along the surface, and each layer loop must have the same number of points. Satisfy those constraints, and almost any shape will render almost immediately.

00:51 <lf94> How does it know what points connect to which?

00:51 <lf94> Hm

00:52 <InPhase> lf94: Index order.

00:52 <lf94> Ah :D

00:52 <InPhase> Since they are the same length, same indexed points are always connected.

00:52 <InPhase> I spent a lot of time struggling with the other ways one can define it, but most of them get problematic in edge cases that are hard to define and specify as a problem.

00:53 <InPhase> The matched-length version though actually gives you very nuanced control on where the edges are if you choose to pay attention to that (which I wanted to for the threads I was making while first designing it).

00:55 <InPhase> Probably someday I will make a closest next layer point version, but for some designs it will have instabilities in triangulation due to floating point errors.

00:57 <InPhase> So instead I have spent years scratching my beard over this possibly intractable problem. And therefore, index order puts the layout burden and the control in the hands of the user, at the price of sometimes requiring more points per layer than desired for shapes that change loop length radically. But it makes up for it by being super fast anyway.

01:56 <lf94> So I'm in a weird place: looks like Doug has basically abandonned his project (it's been almost half a year)

01:56 <lf94> Then there's a project I've started but I don't have the expertise to complete it

01:57 <lf94> Now I'm coming full-circle to openscad because I think if you use analytical methods to generate points, it can do nearly everything curv could do

01:57 <lf94> curv was just as slow as openscad for non-trivial things too

01:58 <lf94> My new code cad is fast as hell, but I just don't have the time or motivation to create the code for proper exporting

01:58 <lf94> and already I look at it and go "ugh"

01:58 <lf94> So at this point I'm looking at openscad. Community power is just too powerful of a thing to ignore.

02:05 <joseph_> teepee InPhase: I've been a bit sidetracked by some unexpected apartment logistics that had to be dealt with quickly. Thanks to the suggestions I solved my error about backups, I just needed to create /root/.local/... I'm about to push that change to my dev env mini-repo. By tomorrow I hope to have built up a document I can share which contains my questions so far about ideal approaches for substituting things in the Renderer

02:05 <joseph_> architecture

02:31 <InPhase> joseph_: Ok, sounds good. Make sure to include specific references to parts of the code in question to help ground us for the discussion.

02:32 <InPhase> joseph_: Pretend as if we haven't looked at that section for a while. :)

02:32 <InPhase> lf94: Yes. Yes it is.

02:34 <InPhase> lf94: And I remain a believer in the potential of a built-in OpenSCAD module that takes an sdf function literal as a parameter. I think this would really patch up a set of those hard cases, letting a person flip between them for various components.

02:35 <lf94> Having used SDFs I'm doubtful because I think you can create the same organic shapes by just exporting points

02:36 <lf94> So like, continue using SDFs but not in their usual shader context basically

02:36 <lf94> You sample points along their fields

03:02 <InPhase> For most shapes I can generally conceptualize and work with functional surface descriptions better than distance metrics, so I concur with the principle. But there are certainly a large set of shapes that are easier to break down as compositions of distance functions, whereas functional compositions of surface outlines are much more challenging.

03:12 <lf94> such as?

04:17 <InPhase> Well, fillets for complex shapes, for example, as long as you have been careful in the preceding composition steps.

13:07 <lf94> if you use analytical model I think you can fillet them easily still?

13:07 <lf94> generate your complex SDF with fillets, and sample the field's surface, right?

14:39 <InPhase> lf94: Yes. I frequently do fillets precisely in that way. And it's very easy (with appropriate math skills) with surfaces that have symmetry. But I will reference the portion of benchy that J1A8451 highlighted 8 days ago: https://pasteboard.co/dd71BiPaPBpX.png

14:40 <lf94> :o! Yes! Exactly!

14:40 <InPhase> For a fillet like that it would clearly be easier to not have to analytically try to determine the transitions.

14:40 <lf94> "with surfaces that have symmetry" why does this matter in the context of sdf sampling?

14:40 <InPhase> Ah, sdf sampling.

14:41 <InPhase> Well, yeah, then we're in agreement that this would be easier with an sdf backing. Which in turn would be better done not in the OpenSCAD language itself, but would be nice to have integrated in some manner as a feature.

14:42 <InPhase> Now that also means that every piece you try to merge in this way needs to also be sdf constructed, but such is life.

14:43 <InPhase> It would work okay for this image as long as the walls are constructed with a radial distance intersection and not a planar filter intersection.

15:58 <lf94> you could create an sdf "context" using purely openscad code and have it spit out points though right

15:58 <lf94> "context" -> 3D array for example

17:03 <lf94> Well OCCT failed me today

17:04 <lf94> https://github.com/sgenoud/replicad/issues/33

17:05 <lf94> The second last alternative is using Blender as a code cad

17:05 <lf94> and then finally openscad

21:01 <gbruno> [github] t-paul locked issue #4271 (Bounds missing on sliders) https://github.com/openscad/openscad/issues/4271

21:01 <gbruno> [github] t-paul closed issue #4271 (Bounds missing on sliders) https://github.com/openscad/openscad/issues/4271

21:35 <J1A84> seems we really need a guide "how to log an issue" Ü - assuming some people never used a ticket system before.

21:38 <J1A84> on the other hand wouldn't help if people use an inappropriate tone

21:48 <teepee> yeah, I think with the new template stuff on github that's even easier now

21:48 <teepee> as there can be a template for "feature request" and one for "bugfix" and so on

22:01 <J1A84> what about bug request?

22:03 <J1A84> .. that is not a feature, it's a bug

22:17 <J1A84> was wondering why so many .. ah https://www.printables.com/contest/76-coasters    cylinder(3,d=85);

23:48 <InPhase> J1A84: Most of those are from people who never had to clean a coaster, it seems. :)