qeed has quit [Read error: Connection reset by peer]
qeed has joined #openscad
GNUmoon has quit [Ping timeout: 276 seconds]
GNUmoon has joined #openscad
<InPhase>
peeps[zen]: Yeah. The problem is threads are cut by a vertically oriented pattern, and linear_extrude does a horizontally oriented pattern.
Jack2242 has joined #openscad
<InPhase>
peeps[zen]: And thus making the mapping from vertical to horizontal is computationally messy in a weirdly intertwined manner with pitch and such. And then once you do that you have a somewhat inflexible shape that's tricky to tweak in radius at the ends without losing the vertical profile properties.
Jack22 has quit [Ping timeout: 256 seconds]
<InPhase>
peeps[zen]: I'm confident I could sit down with some paper and hammer out the trig to map vertical thread patterns to a horizontal cross-section as a function of all the relevant variables, and very briefly started working on it many years ago before I realized it wasn't going to scale in needed flexibility.
splud has quit [Read error: Connection reset by peer]
<InPhase>
pa: This for example is the one-to-one translation of Jack2242's Q5QA example to using close points. It's the same output shape (I bumped up the smoothing a little) but generated as a single polyhedron, so it will render more efficiently when smoothed.
<InPhase>
pa: This structurally follows the demo_* examples in that github page. And once it is in this form, you can make trivial numerical alterations to ThePolygon to alter the shape (e.g. curving) or changing shape along the path (using the parametric t variable).
<peeps[zen]>
InPhase: yeah its not ideal. i guess i was just trying to say its not infeasible (impractical, probably)
<InPhase>
peeps[zen]: Yeah. I think there is some merit to adding a pitch parameter to rotate_extrude as Jack2242 suggested to automatically get those sort of vertical-profile results. It's still not as flexible as I'd like for threads, but it would provide built-in support for a great many types of custom threads, which would be a nice boost.
<InPhase>
I'm a fan of good libraries, but they should also be exploratory to help us identify the most essential and flexible features to bundle in. And the lack of spiraling with vertical cross-sections as we have with horizontal is on that list. :)
<peeps[zen]>
i've considered adding a z translate to rotate extrude, but not sure how it would deal with self intersections or >1 turn
<InPhase>
peeps[zen]: Well here's a simple rule to remove self-intersections. Don't take a pitch parameter at all, but when enabling spiral mode it automatically maps it so that 360 degrees maps the top of the first pass to the bottom of the second pass?
<InPhase>
peeps[zen]: Like a min/max sort of thing.
<InPhase>
peeps[zen]: ... Which would be non-manifold if the top and bottom aren't flat. So clearly there's some more thought to be done. ;)
<InPhase>
Or, a specification requirement for using the feature I guess, analogous to the y-axis intersection issue.
<InPhase>
So in addition to the normal manifold requirements, rotate_extrude with spiral mode requires the input's max y and min y to both consist of edges and not isolated points.
<InPhase>
Then multiple turns should also be easy, and one pops out threads or other spirally things.
<InPhase>
Input would just be angle=thread_count*360, spiral=true
<InPhase>
Maybe AGZ already figured out what I just said...
<peeps[zen]>
InPhase: ideally it would work for both screw threads and coiled spring where the pitch is non-intersecting (like my thingiverse example)
<InPhase>
peeps[zen]: Fair point.
<peeps[zen]>
so pitch >= input geometry height (plus extra requirements if ==)
<InPhase>
pitch=undef for the auto mode I described, to avoid floating point issues.
<InPhase>
pitch > input height for space between.
<InPhase>
pitch < input height tosses a warning.
<InPhase>
pitch == input height means you got lucky or used carefully chosen values. :)
<InPhase>
Yeah, I think that's a viable design. It seems well specified and sits right with my brain as usable.
<peeps[zen]>
also pitch irrelevant if angle < 360
<peeps[zen]>
if angle == 360, then... things might be tricky
<InPhase>
Well not irrelevant. pitch will still specify the spiraliness.
<InPhase>
But not a problem.
<InPhase>
A 180 degree spring is possible then, at chosen 360 degree pitch.
<peeps[zen]>
yeah i mean irrelevant in terms of preconditions
<InPhase>
Yep.
<InPhase>
For 360... I guess that's weird.
<InPhase>
Maybe 360 with matched pitch is invalid. :)
<InPhase>
Is it manifold if two identical cubes meet at an exact edge?
<peeps[zen]>
i'm picturing for example attempting to do threads of a bolt, by modeling all the threads along the length, in 2D, then just do a single turn, but you'd have to guarantee that the input is periodic over the pitch, and the end faces might be painfull to figure out
<peeps[zen]>
that just seems like an equally valid approach as doing a single thread profile with multiple turns
<InPhase>
Oh, so angle=360 but pitch < input height.
<InPhase>
That would be messy and hard to make any guarantees about for general cases. I'd say don't support.
<InPhase>
You'd have to guarantee it lines up all the way along to make sense of it.
<peeps[zen]>
i just have a feeling that's going to be the first big WHY CAN'T I???
<InPhase>
If someone really wants to do it, they should do 360.01 and deal
<InPhase>
Because we can guarantee 360.01 will always work.
<InPhase>
Or wait... No we can't.
<InPhase>
That's the previous invalid case we said.
<InPhase>
Yeah, just don't support. :)
<InPhase>
The answer to "Why can't I?" is because there is no general way to make it manifold so it is not calculable, and it spells it out clearly in the requirements in the wiki page that would need to be there. :)
<InPhase>
If some clever person figures out how to solve it later, then great.
<InPhase>
Now for angle=360 and pitch == input height... Are two cubes meeting at an exact edge valid in all cases by CGAL standards?
<peeps[zen]>
nope
<InPhase>
Then this is invalid.
<peeps[zen]>
an edge must be shared by exactly 2 faces
<InPhase>
Slight update to the max/min manifold input criteria. Both must be edges, and they must share more than one x point between max and min.
<InPhase>
Or... If they share any x point, they must share more than one.
<InPhase>
Oh, and the absurd case... What if pitch < input height, but the intersection edges for top and bottom are not at max y and min y? It's possible to make a weird looking spirally thing that contacts at one correct edge, or that doesn't contact at all, because a thin part goes up on the inside, and maybe also a thin part goes down on the outside.
<InPhase>
Like, a spirally turbine like thing that you can't see through but that air could flow through.
<InPhase>
That only impacts the question of whether or not a warning should be thrown for pitch < input height.
<InPhase>
pa: And to finish my previous thought... This is an example of how you would go about smoothing it, but retaining a single polyhedron: https://bpa.st/JXEA The image is here: https://i.imgur.com/anFz9ge.png
Colt_ has joined #openscad
Colt has quit [Ping timeout: 268 seconds]
othx has quit [Ping timeout: 256 seconds]
othx has joined #openscad
snaked has joined #openscad
<peeps[zen]>
InPhase: what about taper for pipe thread or self-tapping screw points? first i was thinking something like a scale does on linear_extrude, but even if that were only in the radial direction, it would flatten out threads, change their angle. so something more like a radial shift in/outwards?
<peeps[zen]>
i think the whole profile would have to be rotated in 2D; sort of a secondary pitch
<InPhase>
It can't be a rotate because you can't alter the vertical spacing of the threads.
<InPhase>
That's the most critical part. The initial tapered portion cuts the starter path for the larger diameter threads.
<InPhase>
I mean, not a rotate of the input profile.
<InPhase>
I did it with a particular formula for radial shift inward, trying to approximately preserve the pitch angles.
<InPhase>
The logic is buried in the mess of math that requires a rewrite in my threading library, but I believe I did the inner radius and outer radius at a slightly different rate, so that the inner radius goes in a little faster than the outer radius which then catches up at the very tip.
<InPhase>
That way the threads keep the same pitch and general shape along the taper, but then there's a pointy tip when it gets to the end.
Colt_ is now known as Colt
KimK has quit [Ping timeout: 240 seconds]
KimK has joined #openscad
arebil has joined #openscad
rvt_ has joined #openscad
<peeps[zen]>
InPhase: the vertical spacing would only be off by the cosine of the taper angle. for NPT i just looked up the taper angle is only 1.7899degrees cos(1.7899) = 0.999512
rvt_ has quit [Client Quit]
<peeps[zen]>
i wonder if two different schemes are necessary for NPT style taper vs self tapping screws
<peeps[zen]>
even at 15degrees, vertical spacing would be 0.965926x the original, only ~3.4% short
<peeps[zen]>
we should probably bring some of this discussion of corner cases etc into that issue's comments, see if that person can share their code, and if its worthwhile. otherwise I'm tempted to just write it up myself
<peeps[zen]>
either way would be good to get these thoughts into a slightly more permanent and visible medium for posterity. i'll try to do that tomorrow
<peeps[zen]>
one other question, would you think its worth it to extend rotate_extrude's functionality or just make a whole new builtin (spiral|screw|helix|helical)_extrude
KimK has quit [Ping timeout: 240 seconds]
KimK has joined #openscad
<ccox_>
that depends on exactly how you want to extend it
Jack2242 is now known as Jack22
<Jack22>
a new module could also get rid of the fn issue .. i wouldn't care about the taper so much as for those InPhase closedpoints are the way to go - i would keep it simple, maybe adding a twist. Another thing would be if i make a rollerball track with a circle the 2D shape would need a distortion to make a circular track - so should we rotate the
<Jack22>
profile and move (pitch) or also rotate it 90° to the spiral path
<Jack22>
the later would be preferred especially for larger pitch values but also mean that a normal thread is hard to make to specs
submariner has joined #openscad
<Jack22>
another more sophisticated approach would be a path_extrude module that takes 2D shapes but the same problem as we have with closepoints - beginner would have a hard time to understand the usage. Something like a chain hull but with 2D shapes and not exclusive convex would be nice but the whole loop would be difficult to interpret as
<Jack22>
separated childs i guess.
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
rvt_ has joined #openscad
rvt_ has quit [Quit: rvt_]
rvt_ has joined #openscad
GNUmoon has quit [Remote host closed the connection]
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
arebil has joined #openscad
Colt has quit [Remote host closed the connection]
Colt has joined #openscad
Colt has quit [Remote host closed the connection]
Colt has joined #openscad
Colt has quit [Remote host closed the connection]
Colt has joined #openscad
Colt has quit [Remote host closed the connection]
Colt has joined #openscad
Colt has quit [Read error: Connection reset by peer]
<InPhase>
peeps[zen]: The rotate_extrude interface is simple, so I think reusing is okay if the new spiral features are simple. But, a problem can arise the other direction if there are many spiral features that do not work well if you try to mix them with non-spiral rotate_extrude. At that point a separate call makes more sense.
Colt has joined #openscad
<dalias>
would spiral rotate_extrude finally be a simple builtin thread/helix?? :)
miique has quit [Read error: Connection reset by peer]
rvt_ has joined #openscad
Guest2 has joined #openscad
Guest2 has quit [Client Quit]
<InPhase>
dalias: Basically.
<InPhase>
Suitable enough for the basic cases.
linext has quit [Read error: Connection reset by peer]
linext has joined #openscad
<peeps[zen]>
if pitch=undef is meant to be auto pitch, then not sure how that should work as a feature of rotate_extrude, add an additional spiral boolean?
<peeps[zen]>
so maybe makes more sense as a separate module
<InPhase>
peeps[zen]: I pictured a spiral boolean, yeah. But separate could be cleaner.
<InPhase>
pitch without a spiral bool of true is meaningless, for example, and that's not a good design.
<peeps[zen]>
also i feel like helix is a better descriptor than spiral. i think spiral implies a 2D shape
<InPhase>
I like the word spiral better, emotionally, but helix is more accurate, so sure.
<InPhase>
Oh, yeah. And I guess helix_extrude needs to extrude both directions, which has never been an issue for rotate_extrude. We need both chiralities. :)
<InPhase>
One could mirror, and the implementation could even be made by a hidden mirror if that's easier to write, but that's best as part of the API for less mental load.
<peeps[zen]>
actually a true spiral extrude would be a whole other use case, like generating vanes of a scroll compressor
<InPhase>
Could be saved for later, yeah.
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
rvt_ has quit [Quit: rvt_]
ur5us_ has joined #openscad
rvt_ has joined #openscad
ferdna has joined #openscad
la1yv has quit [Read error: Connection reset by peer]
la1yv has joined #openscad
<ccox_>
The other day someone mentioned wanting formatting for numbers (basically for blueprints). A format() call was suggested.
<ccox_>
Couldn't we accomplish most of what they needed with a single precision/format specifier added to str, or a format_number() function? That would greatly simplify the complex parsing needed for format() or printf() style formatting.
<teepee>
what complex parsing?
<ccox_>
have you ever read the source for printf that tries to parse the formatting?
<teepee>
hence the suggestion to use std::format (via external lib until we actually can use c++20)
<InPhase>
It's not necessary to reimplement things in the standard libraries just to use them. :)
<ccox_>
A library version of format could also work.
<ccox_>
But I always prefer the simpler, robust option over the more complex.
<teepee>
the standard is based on https://fmt.dev/latest/index.html so that should be a reasonable transition if we'll use only the standard stuff
<teepee>
I does not get easier and more robust than c++ standard
<ccox_>
obviously, you have never attended a C++ standards meeting ;-)
<teepee>
I did not, but I'm still convinced using the standard libc++ is better than inventing format stuff ourselves
ur5us_ has quit [Ping timeout: 240 seconds]
<InPhase>
"It does not get easier and more reliable in terms of dependency management than using the C++ standard library when writing C++ programs." --I-fixed-that-for-you teepee translation. :)
<veverak>
hmm
<veverak>
hmmm
<veverak>
oh shit, I thought this is C++ and was writing C++ question :D
<veverak>
sowwy :)
<teepee>
:)
<teepee>
pretend it's about openscad source and it fits right in here :)
<teepee>
I don't think we use static_vector<>, but array<> instead
<veverak>
yeah, array<> is not that great for some stuff
ferdna has quit [Quit: Leaving]
ur5us_ has joined #openscad
<teepee>
true, it only works for completely const data
<veverak>
and the api for static_vector is in the end more sane
<veverak>
you can use array with simple types to do the same, but the code is more cluttered
<veverak>
(sometimes, sometimes it is the opposite)
rvt_ has quit [Quit: rvt_]
epony has quit [Ping timeout: 240 seconds]
epony has joined #openscad
<veverak>
just note: I do embedded
<veverak>
static_vector is relevant there quite much :D
<teepee>
and that's the boost one?
* juri_
something something haskell something. :)
<veverak>
nah, my own
<veverak>
we have C++ lib that focuses on stuff for embedded