ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
Guest35 has quit [Quit: Client closed]
snaked has quit [Ping timeout: 256 seconds]
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
<InPhase>
Jack21: Nice. :)
<InPhase>
Guest1: Well... Indent 4 spaces.
<Jack21>
And it is Snowball day .. Ü
<InPhase>
Guest1: Other than that it's more of try to fit the style in with nearby code, and discuss any cases that would deviate significantly from that.
<InPhase>
Guest1: We're a community of just the right size and structure where it's easy for new contributers to just openly discuss what they're thinking about doing, or post a little code example ahead of time if there's something they need feedback on.
<InPhase>
Jack21: Ah, finally. :) I've been waiting for the Snowballs, and lost track of the calendar.
* Jack21
wonders .oO (4 spaces .. so much hmm )
<InPhase>
Jack21: I know, 4 is greater than 0. ;)
<Jack21>
so much space .. vast emptiness of endless space makes me feel so small
<teepee>
just a matter of finding the right font ;-)
<Jack21>
btw. probably the reason why cats love boxes so much - no free space
<Jack21>
a font where a colon had a space included - Ü
<teepee>
WARNING: Point index 9223372036854775808 is out of bounds (from faces[59][1]) in file ../../../../../.local/share/OpenSCAD/libraries/rcolyer-threads/threads.scad, line 226
Colt has joined #openscad
<teepee>
InPhase: ScrewHole(outer_diam, ...
<teepee>
where's that outer_diam exactly?
<teepee>
it looks like it's defining the middle of the thread, so it's cutting same amount on both sides?
<InPhase>
teepee: outer_diam is the nominal outer diameter of a thread, e.g. 4 is an M4. The actual size of a hole goes out further than the outer diameter because of clearance requirements, so it does represent the furthest protrusion of the hole that cuts except that there's a little extra cut.
<InPhase>
9223372036854775808 Not sure how you get that. :)
<teepee>
that was me using asin instead of sin producing NaN as diameter :)
<InPhase>
Ah. :)
<InPhase>
I still have one open github issue I need to process on that library. I should get around to that soon. The submitter of the PR just bundled a few problems that needed to be sorted out.
<teepee>
but I seem to get near perfect sizing when reducing the diameter by sin(tooth_angle) * pitch / 2 which if my math is not wrong would be about half the cutting size
<teepee>
I'm using totally non-standard thread here with angle = 55° and pitch = 3
<InPhase>
If you wanted exact render sizing, doing the different of ScrewThread yourself with tolerance=0 should probably do it. Although it certainly won't be exact print sizing. Those offsets take into account the effects of attempting to print such a shape.
<InPhase>
s/different/difference/
<teepee>
no, the clearing is perfectly ok
<teepee>
It's just that I'm targeting a 2mm ring (of around 60 to 80mm diameter)
<teepee>
so I want to keep the 2mm wall for the thread too, just adding some material where the thread is
paddymahoney has joined #openscad
Guest1 has quit [Quit: Client closed]
<InPhase>
teepee: Yeah, I had some "cutting it close" issues with my T-slot nut design.
<InPhase>
Although conceivably one could difference out a cylindrical container hole and then insert a positive cylinder of a known size. But that imposes a lot more alignment constraints for exact sizing on through holes. It also makes impossible through-holes with non-planar far-ends, which I've had a number of times.
<Jack21>
as there is a wall around you can make the hole bigger
<teepee>
adding another 0.2 closes the cylinder, which might make sense with default tolerance = 0.4
<Jack21>
inPhase another reason is that the cut for an inner thread has a different geometry (https://imgur.com/a/TMITJLe)- i mean i can't prevent that someone uses this in a difference - but it doesn't generate a good thread and as the start and end of a thread is primed - it will not work
<Jack21>
always welcome - happy for everyone enjoy using it
snaked has joined #openscad
<Jack21>
better is calculate the scaling factor so for a cylinder with d= 1 just scale ( [25, 13.3]) else new1/d , new2 /d
<Jeringa>
solve
<Jeringa>
thanks for all
<Jeringa>
to everybosy
<Jeringa>
your are a great support
<Jeringa>
and great staff
Jack21 has quit [Quit: Client closed]
ur5us has joined #openscad
Jack21 has joined #openscad
Jack21 has quit [Quit: Client closed]
SebastianM has joined #openscad
ochafik has quit [Remote host closed the connection]
Jack21 has joined #openscad
Jeringa has quit [Quit: Client closed]
ur5us has quit [Ping timeout: 252 seconds]
ur5us has joined #openscad
SebastianM has quit [Quit: Bye]
<InPhase>
Jack21: So I carefully considered the alternate geometries of official threads when I designed my threading library, but what I discovered is that it basically didn't matter for the typical size scales where plastic interacts with standard sizes of metal threading. And when you get to larger size, for plastic in plastic, it also didn't matter much. Most of those rounding efforts are based around not
<InPhase>
having razor sharp metal shards on screws. This isn't really an issue for plastic, and the extra material just gives you better grippiness than you'd get from rounding things.
<InPhase>
Jack21: So one could insert the extra steps to account for it, but it would usually mostly disappear between layer lines, and not really be better enough to be worth the effort.
<InPhase>
Jack21: In order to insert all that rounding you also pay a heavy price of extra polyhedron faces.
<InPhase>
(So it's not just about the implementation effort.)
<Jack21>
from my experience it is worth it but i also print 40-80μm layer
<InPhase>
That could change things.
<InPhase>
It might also differ if one was printing in metal. The plastic deforms so quickly when encountering metal threads that it basically adjusts its shape rapidly anyway.
<InPhase>
For things I made like the augur wall anchors, the edges being as sharp as the plastic layers could make them were also a huge benefit, as it has to cut into drywall.
<Jack21>
you can always use rad=0
<InPhase>
So I concur there is a place for it. I just had considered it carefully and rejected it as necessary for the scope of purposes of what I was constructing due to material differences.
<Jack21>
but for all prints - it is never good if the angle changes much at one point so even split on 2-3 layer makes a huge difference - in spiral print this is very noticeable
<InPhase>
A side-effect was that the holes were in fact the same geometric shape, just scaled outward a bit.
<Jack21>
And for visible threads like on a lid for a box it makes much sense as the thread feels nicer when rounded
<InPhase>
One of my big concerns was in fact M3, M4, and M5 threads. For M3 any rounding on a standard type FDM printer obliterates the thread content from resolution issues.
GNUmoon has quit [Ping timeout: 276 seconds]
<InPhase>
For M4 it would take away a really big part of what they have to work with.
<InPhase>
M5 could handle a bit.
<InPhase>
For higher quality printers and materials that can handle it without shrinking out of shape, this could differ.
<Jack21>
oh i am not just rounding the corners, they are calculated exactly so the distance is still there
<Jack21>
the contact should be the slope not the peak so these need to have different rounding and distance
<InPhase>
The question is simply how much material needs to be deformed before it slips out.
<InPhase>
Rounding leaves that amount less.
<InPhase>
The force profile for pull-out changes at the rounded parts.
<Jack21>
yes and a thin sharp edge holds less than a rounded
<InPhase>
With metal on metal they tend to hold without deformation on the rounded edges, and it's only snapping that is a failure mode. But I had some M3s suffer from pull-out. M4s sometimes did this until I got it snug enough.
<Jack21>
you can use differen tollerance with rounded as the contact is not at the edge and so less influenced by the printing irregularities
<Jack21>
But you sure need the same profile on both sides .. so it works best if both parts are printed -- there are also very different quality of screws on the market
<InPhase>
For layer line jitter it is about half at the 30-degree edges, so this is correct. But you also get totally spatially random plastic deformation defects from stringiness or plastic just extruding irregularly or spitting a bit that become relevant at the M3 M4 thread scales, and these are basically the same between the profiles.
<InPhase>
The sharp edges in fact tend to retract from plastic shrinkage at this scale, and thus you get a little extra rounding for free. :)
<InPhase>
https://www.thingiverse.com/thing:1686322 The five bolts in the front left row, from front right going to the left, are M8, 6, 5, 4, 3. If you look closely at the M4 you can see it is in fact rounded already.
<othx>
InPhase linked to "Screw Threads, Holes, Bolts, Nuts, and Rods Library by rcolyer" on thingiverse => 37 IRC mentions
<InPhase>
The M5 is also effectively rounded, although less so.
<Jack21>
that is using .5mm threads but i also printed smaller that work nicely
<InPhase>
(Click over to the printed version in white filament for what I described.)
<InPhase>
The black print is identical but you can't see it.
<InPhase>
The inner threads also get a shrinkage effect in the other direction which again rounds it at that size scale.
<Jack21>
this has a double thread pitched 1.3 but with just 0.375 height
<InPhase>
This is an example of where rounding would in fact have been nicer in my past work: https://www.thingiverse.com/thing:1692539 Click over to the second image where you can see the large sharp-edged thread toward the left end of the left rod piece. It worked fine, had an intriguing aesthetic, and was a super snug fit. But rounding might have been more elegant.
<othx>
InPhase linked to "Twist-on Paper Towel Holder with Rod by rcolyer" on thingiverse => 4 IRC mentions
sublim8 has joined #openscad
<InPhase>
That was the design where I calibrated the goodness of fit at larger thread scales, and confirmed it held up well.
<InPhase>
Also... I need to print a new one of those, as I sold that paper towel holder with my last house. My new laundry room sink could also use one.
<sublim8>
t-paul I had to scrap my pr and redo it. I saw your comment after recreating the pr.
<sublim8>
The swizzle feature I implemented is indeed like the one in GLSL.
<sublim8>
Hey InPhase.
<sublim8>
Hey teepee.
<sublim8>
I don't know if people want it or not but, as I mentioned above, I implemented vector swizzling.
<teepee>
sublim8: yeah, I saw there was other stuff in there, I just thought I'll comment already anyway :)
<Jack21>
thingyverse let me only view small version of the images -- needed to extract the image url
<teepee>
sublim8: I wonder if it makes sense to also limit max 4 entries. but on the other hand I don't see how it would hurt to allow more
<sublim8>
I recreated the vector-swizzle PR because I accidentally based it on my data-render code. Now it's based on the current master. It's less than 10 lines.
<sublim8>
I don't limit the entries
<sublim8>
I don't think it makes sense to limit them.
<teepee>
I know, the glsl spec does, not sure why
<sublim8>
well, different language for different use.
<teepee>
with language changes I'm always a bit cautious as it's easy to extend but almost impossible to take things back
<sublim8>
But it's nice to have similarities to dull the learning curve.
<sublim8>
Sure, but is that large a change?
<teepee>
what is? the checks? I assume it would be easy to create a regex testing valid combinations
<sublim8>
I thought you were talking about the while swizzle feature
<sublim8>
the whole
<teepee>
yes, I do
<teepee>
glsl allows 3 sets of swizzles xyzw rgba and stpq
<sublim8>
I can add the others, that's no issue
<teepee>
which cannot be mixed and allow a maximum of 4
<sublim8>
So, are you proposing we mirror GLSL?
<sublim8>
That tightly?
<teepee>
yeah, it's proven to work for people :)
<teepee>
we don't need to exactly copy though
<teepee>
lets hear what other people think
<InPhase>
What's stpq for?
<sublim8>
texture coordinates
<sublim8>
I think
<sublim8>
is it?
<sublim8>
yeap
<sublim8>
just looked it up.
<teepee>
yeah, we may want to skip that for now, we don't exactly have textures at this point :)
<InPhase>
Well we don't have those so we shouldn't waste future letter availability on things unusable. But rgba can be fed into color(), so that makes sense.
<teepee>
and I think it's a good idea to prevent mixing different combinations
<sublim8>
Yes but even GLSL isn't so strict about that. x, z, y, etc are just names to reference certain parts of the vector.
<sublim8>
GLSL allows you to use any name in any place.
<teepee>
nope, not according to the spec I've linked
<teepee>
> Additionally, there are 3 sets of swizzle masks. You can use xyzw, rgba (for colors), or stpq (for texture coordinates). These three sets have no actual difference; they're just syntactic sugar. You cannot combine names from different sets in a single swizzle operation. So ".xrs" is not a valid swizzle mask.
<sublim8>
Hmm. Where exactly?
<sublim8>
Yes
<sublim8>
Mixing is allowed
<InPhase>
I suppose multmatrix swizzling would be unusuably complex.
<teepee>
Uff... In OpenGL 4.2 or ARB_shading_language_420pack, scalars can be swizzled as well. They obviously only have one source component, but it is legal to do this: float aFloat; vec4 someVec = aFloat.xxxx;
<sublim8>
but you don't have to use st for indexing textures.
<teepee>
true, as it says, it's totally for looks, not for feature
<sublim8>
Mixing in the same swizzle is not allowed.
<sublim8>
And that's how it should be.
<sublim8>
xsty
<InPhase>
For more complex things we'll need slicing and maybe indexing by list. :)
<InPhase>
Range literals will help with slicing.
<sublim8>
So, what changes do you propose at this point?
<sublim8>
Error checking for not mixing letters and ...?
<sublim8>
limit to 4?
<teepee>
my suggestion would be to start slow by 1) adding a regex that checks for xyzw and rgba with limit 4 2) add a simple test case, I can show you an example
<teepee>
changing to unlimited would simply change the regex, no other changes would be needed
<sublim8>
ok
<teepee>
yep, boost regex seems to support the [xyzw]{1,4} syntax
<sublim8>
sure
<teepee>
so it really should be a matter of ^([xyzw]{1,4}|[rgba]{1,4})$