<ccox>
Sigh, now I have a design that only works well in the daily builds, and takes half an hour to render in the 2021 release. Guess I won't be posting that publicly for a while.
<J24k85>
teepee part 3 - step 4 - I would add a step to show how the order of rotate and translate play a role by rotate(45) translate([0,5])square(10);
<pca006132>
in the mailing list it seems that some people are still using snapshot builds ~1year ago...
<pca006132>
and manifold changed A LOT in this 1 year
<kintel>
pca006132 Yeah, some people are hesitant to upgrade, and cling to their specific build for a long time. Not much we can do except nudge them along
<kintel>
..or release a new stable :)
<InPhase>
People aren't going to cling long once we get a new stable out.
<InPhase>
The delta is so huge.
<InPhase>
This will be an epoch point release.
<kintel>
Yeah, I think the big question is whether we can set ourselves up to provide stable bugfix releases after a stable release
<kintel>
Earlier that proved to be too time consuming as the master branch diverged too fast, so backporting bugfixes wasn't very convenient
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #openscad
<InPhase>
Well, we ended up with a huge delta this time, as much ambition converged at once.
<InPhase>
But just thinking about other projects, a smart move is probably a release, gather feedback, and another release not too much later.
<InPhase>
Maybe 6-12 months at most.
<InPhase>
Because I will not be remotely shocked if we learn some things that need to be folded into another timely stable release. :)
<kintel>
yeah, we just have to avoid pulling in too speculative features which takes time to mature..
<InPhase>
So we might simply want to release with the understanding that another one will have to come soon, and see what happens and respond accordingly. I don't think there's much of another way. And this falls nicely under the "fail forward" strategy that can work really well for open source.
<InPhase>
i.e., just take some issues as part of an epoch change, and plan to address them soon.
<kintel>
Anyway, I fully agree. Let's try to be even better at isolating speculative features behind build flags
<InPhase>
Although we've also probably never had so many people running nightly, so I think we're in really good shape considering the magnitude of the updates.
<kintel>
yeah, true. Which is also reflected in the number of inflowing issues :)
<kintel>
With the above in mind we could also try to be a bit more lax about release quality, and e.g. allow some UI issues to persist as long a language issues are resolved
<InPhase>
Yeah, I think so also.
<InPhase>
Most important is to try our best to avoid breaking language issues. Even a few manifold bugs in designs outside of our existing scope of tests are an okay problem, since we know this works on the vast majority of stuff.
<InPhase>
And if it's not too long until the resolution release, users will stay appreciative of the transition path overall.
<pca006132>
well, CGAL has (arguably more) issues as well, we can never guarantee bug-free in any of our code :)
<pca006132>
but of cause another issue would be manifold changes causing changes in the mesh output, I think some users are strongly opposed to this
<pca006132>
but this is quite fundamental in manifold's inexact method
<kintel>
I'm not too concerned, the output surface is still deterministic, it's just the meshing that's non-deterministic, right?
<kintel>
..or is there also an aspect of simplification moving vertices around a bit too?
<pca006132>
we will probably not move them around, but may eliminate some of them
<pca006132>
but that should be close to the floating point precision limit, at least for now, before we get a proper decimation algorithm to simplify the mesh to user-defined tolerances
<pca006132>
*close to double precision limit
<pca006132>
I'm a bit curious about if manifold can avoid these floating point madness if we provide a variant using exact arithmetic... will probably make things 10 times slower, but we probably get to avoid many floating point issues...
CameronBrooks11 has quit [Quit: Client closed]
J24k has quit [Quit: Client closed]
J24k has joined #openscad
J24k34 has joined #openscad
TylerTork has joined #openscad
<TylerTork>
I thought I saw a BOSL2 function to eliminate excess polygons in what is actually a flat surface, but I can't find it now. I'm talking about these superfluous facets in what are actually flat faces, for instance: https://prnt.sc/D_EqdHHrmVtD
J24k has quit [Ping timeout: 256 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mmu_man has quit [Ping timeout: 264 seconds]
<J24k34>
teepee would it make sense to put a title in gif as they start empty - until some object emerge after seconds
<teepee>
ah, yes good idea
<teepee>
done
dicot has quit [Read error: Connection reset by peer]
mmu_man has joined #openscad
dicot has joined #openscad
CameronBrooks11 has joined #openscad
TylerTork has quit [Quit: Client closed]
JakeSays_ is now known as JakeSays
foul_owl has quit [Ping timeout: 252 seconds]
h1 has joined #openscad
h1 is now known as Guest1010
<Guest1010>
How would I create a pipe with a 90 degree bend in it ?
<Claws61821>
If I want to plot a shape as a polygon from a function, do I need to iterate a variable through it to create a set of vectors and then iterate through that set to create the points, or is there a more direct way?
SamantazFox_ is now known as SamantazFox
<InPhase>
Claws61821: As a 2D polygon you can just use a list comprehension.
<InPhase>
Claws61821: demo: polygon([[8,0], [-5,0], each [for (x=[-5:0.1:10]) [x,0.2*x^2+3]]]);
<InPhase>
Oops, make the 8 and the 10 the same value for a square edge. :)
<InPhase>
But that idea.
<InPhase>
You could also loop over a for angle for round stuff, and so on.
<Claws61821>
So if I have `function shape(4 parameters)=[long math function]`, then I can do something like `polygon([each [for (x=[-120:1:200]) shape(x,B,L,w)]])`?
<Claws61821>
Okay, yeah. I had a few typos in my example, but that worked. Thanks InPhase
Claws61821 has quit [Client Quit]
<teepee>
J24k34: in some sense it is, it's just not one of the 3 basic CSG operations
mmu_man has joined #openscad
<J24k34>
true - that should be changed - Ü
snaked has joined #openscad
<teepee>
I don't think I'll get that Schwibbogen model done, so assuming the tutorial works out, we need to fill 4 more doors (3 saturdays and the 24th)
<InPhase>
teepee: As Christmas gets close, it gets easier to think of Christmasy stuff, right? :)
<InPhase>
Haven't even listened to any Christmas music yet.
<teepee>
in theory yes
Guest41 has joined #openscad
Guest41 has quit [Quit: Client closed]
TylerTork has joined #openscad
dicot has quit [Ping timeout: 276 seconds]
<TylerTork>
okay how about this one? I have a set of polygons in 3D space and I want to create the polyhedron that is bounded by the planes they lie on. The vertices are not points I already know -- that's what I want to calculate.
snaked has quit [Quit: Leaving]
snaked has joined #openscad
<InPhase>
TylerTork: If you have the vertices of the polygons at least, then that's a reasonably straightforward sdf problem.
<dTal>
>The vertices are not points I already know
<InPhase>
I assume that meant of the final polyhedron. Otherwise it's a nonsense problem, because you don't actually have polygons. :)
<dTal>
TylerTork: what exactly *do* you have?
<TylerTork>
InPhase: I know some other points on the plane. I
<dTal>
This is a straightforward linear algebra problem