I’ll keep this in mind while I investigate this theory. At the moment I’d say that ‘vertices’ ultimately are emergent properties of particular geometry, and yes they can be altered somewhat, but sometimes the geometry dictates their composition. Indeed, there’s some options to that composition, but there’s always pros and cons.
If you have countless “half-turns”, you will end up with more ‘vertices’ than if you have a ‘helix’. Therefore, you’ll have more probability of ‘vertices’ that end up having cons.
Two 180 deg turns/srfs, (is) terrible for representing a cylinder – imo. It’s redundant information – twice as many ‘seams’ is twice as frustrating as one ‘seam’. One seam is bad enough. Hb, no seams – that would be nice.
I’m not familiar with the belief that ‘pull’ is somehow used ‘behind the scenes’ during ‘trimming’ processes. But I do believe that the action of ‘pulling’ crvs to srfs, does what appears to be ‘rebuilding’ the crvs to match the degree and point density of said srfs. So, that might be a factor in the outcome.
That’s why I rarely trim something that way. It’s more probable that if you use the ‘crv’ trick, you might be able to get Rhino trim to work by directly selecting the ‘crvs’ instead of the whole thread entity. But that’s obviously more meticulous. And yes it would be nice if Rhino just did it automatically or something lol.
Usually, I prefer for things to be more obviously ‘intersecting’ prior to ‘trimming’, and sometimes I extend things beyond to make sure they do clearly intersect first, before trimming. That’s an example on the right side of your image where they obviously intersect, and Rhino does fine with it more ‘automatically’.
To reiterate, the ‘intersect’ command is a nice trick to reveal why Rhino trim will fail to trim two objects ‘automatically’. If Rhino thinks the ‘intersection’ derives an ‘open curve’, then trim will obviously fail.
Indeed.
I suspected this yesterday, while looking at how the ‘edges’ were comprised. I was attempting to set it up with my methods to find out. But glad you beat me to it
Guess I’m slow here lol, glad to see you succeed
Rhino 1.0 sounds awesome
More vertices, means higher probability of vertices causing trouble.
The advice is fine, and the opinion of how sound it may be is fine too. I just don’t agree with it from the standpoint of ‘work flow technique’ and ‘geometric composition’.
If there’s a specific reason to comprise geometry that way where you arbitrarily increase the number of edges, seams, and vertices to a much higher magnitude than necessary, then I’d like to know what really condones such a decision.
And if the reason that condones it is, “to avoid a srf sharing a vertices ‘twice’”, then I’m willing to challenge it, in order to find out whether that’s an obstacle or not.
I suspect there’s a strawman fallacy in the claim that the srf inevitably obtains said “two verts twice”.
It’s probable that the workflow that is being avoided by that claim, is potentially executed incorrectly – imo. And, even if the “two verts twice” thing occurs, then I’m willing to investigate what is really wrong with that.
Even, if I model something with a few “two verts twice” and avoid a hundred or so extra seams and verts somewhere else, then I’m willing to consider the pros and cons.
(1) Yes, tapered threads are supposed to be tightened until they “jam” together forming a tight seal. In fact, the two surfaces are supposed to slightly deform each other (very slightly), from what I understand. However, in theory, there should be no voids for a perfect thread, screwed into a perfect nut or coupling. (Okay, some minor technicalities at the rest and roots of the thread, but the flat parts of the thread profile should, in theory, generate no voids if geometry were perfect.)
(2) I’m almost sure, that the deviation from the normal frame will not be consistent for a tapered thread. I’ll try to make a demo for this. In fact, I thought exactly as you do, and was then confused about why my surfaces didn’t join together.
Some initial intuition for now:
(A) A 2d Archimedes spiral, or arithmetic spiral is actually pretty weird. Every time it crosses the x-axis, it crosses at a different angle! This is extremely different from a geometric spiral, which always crosses the x-axis at the same angle.
(B) Our tapered thread is based on an Archimedes spiral, just one that moves upwards in the Z-axis.
If you like, a 2d Archimedes spiral in the XY-plane is just an extreme version of a tapered helix. It’s so tapered, it’s flat! (Taper isn’t just a few degrees, it’s 90 degrees.) So if your intuition is correct for all tapered threads, then it should be true for threads that are (almost) tapered at 90 degrees. Say, extreme cases where the taper is 89 degrees (almost flat!).
I’ll make a demo of this, and post it shortly.
btw, I’ve been interested in posting about all this, because I was very surprised by it, myself. And I had the same intuition as you did, until I tried making actual geometry in Rhino.
It would be nice if someone split the last, say 25 posts or so into a separate topic - as it’s so far off the original and so long that this thread has become almost impossible to read and find the actual proposed solutions to the OP’s problem.
Okay, let’s look at an extreme example, of a simple flat Archimedes spiral in the XY-plane. Does this agree with your intuition? You might expect all of the tangent lines to be parallel. But they are not. In fact, the right-most tangent is almost vertical, and the tangent line at the center is horizontal.
The tangent line is the “X-axis” of the TNB frame that is used by Sweep1-roadlike. So if these tangents aren’t parallel, but are tilting more and less, then the rail-shape cannot have a consistent orientation relative to the origin (which is the “axis” of the spiral).
Not to mention the iterations of other similar permutations of threads being avoided due to the fear of being labeled as ‘necroposting’.
Although this subject matter has been going on since the '70’s, sooo…
I agree with this 110%:
That’s why I often will 3D-model threads maybe 7 times outa 10, on my projects. But CAD’s don’t make it easy. Although, it seems to be easier for users and more common, than 15 yrs ago.
Hi ,
V5, yes split the thread into a new one on all this lovely talk over thread making, keep this to my own particular post, though it asked for vids on thread making, and whilst nothing worthy much was seen, its become little o me struggling to replicate this real thread.
so in fact I guess 3 threads.
and here is where I am now, just going at it before looking in on forum thread, following Jim, Tom and Jeremy methods. I have redone that profile as absolutely carefully as I am ever going to manage. @jeremy5 @jim @Tom_P
I even found that snapping helix to the radius line gave a different diameter to entering a value. 3 times I redid it, as at one time it was badly adrift from the profile mirrored downwards. even the circle centre snap had gone odd ball. so hyper checking everything, and not trusting snaps, and the helix tool is a bit off at times, I have this.
and I do a Jim Multitrim, and it doesnt work.
Then I do a single trim and get the rear end to work.
maybe make cutters and thread solids, then try for a boolean difference ?
off to have a late lunch at 6.39pm…as its doing me in despite hammering away at it, ! and see what suggestions there are.
Out of the countless files I’ve repaired over the yrs, the vertices commonly give users trouble, in terms of achieving closed solids or not – for example.
There’s also something to be said for the ‘inflections’ that vertices cause in rendermesh curvature composition, and also something to be said whether Rhino can fillet geometry that contains edges, vertices etc. successfully or not.
Hence, edges/vertices/seams (seem) to be the route cause for common problems in Rhino. Maybe cause (when) users don’t mangage them accordingly – it doesn’t really matter why (for the sake of my point here).
What matters, here to my point, is the probability of a vertice(s) being necessary or not, by ‘existing somewhere’ or ‘being positioned one place’ or another, and leading down the road to ‘failures’ in other features that are intended to emerge through further design developments down the road.
3D-thread-geometric-etities shouldn’t contain a whole bunch of vertices – imo.
I’m just reviewing and compiling to find where the angle changed from 55 deg to 60 deg.
I’m definitely more familiar with 60.
Locking down and specifying all the parameters is definitely of the upmost importance in order to convey the design intent.
It would be nice to be able to design shapes like this ‘parametrically’ and see what the degrees-of-freedom are, especially for the designer to see what might happen if they change the parameter from 55 to 60 and so forth.
“Before being adopted as a British Standard it was known as the CEI thread.”
So if you want 60 degree and 20TPI along with all the other radius data, it would have to be determined if this thread profile is closely following some standard, or if it’s some hybrid custom profile, with some particular custom design-intent driving it, etc.
If only someone could set this up with that super fancy parametric GH using geometric constraints and dimensional constraints so we can analyze this properly:
" 20 tpi can be seen as well for 7/16 and above." so I guess the radii or depth would have to adjust.
then look in on forum again, so more threads up front. and I sort of did that by ensuring I had solid .
Learning all the time, and many thanks Jim Jeremy Tim, CAD CNC AND all that have helped.
I planar sliced the end with a surface, then cut the surface with the result and joined, made a cutter and boolean diff’s it. and I am done .
Now I must make the thread in the item this screws into.
I presume I clone and offset surface by 0.0002 or whatever the tables say. then boolean difference this from the solid I have. I bet its not that simple.
One small thing I am niggled by, the catching of the top of the previous turn of thread.
Any ideas welcome. has to be to do with cone angle, but 52 degs is what I measure on this item. so I replicated it.
My trade secret is to not use a ‘cone’ shape per say. So, ‘ramp’ part of the initial thread until it goes from zero ‘trough’ to 100% ‘peak’, then done – no full revolution (technically not a revolve op), and no cut into next thread adjacent.
But some might argue, “no that bad”.
Side note:
I wanna know the rest of this part it probly top secret
Just to be clear, afaik no standard includes a 1-1/16" thread so as I pointed out way back this is probably proprietary. However, as Steve said it came from a company which made cycles it is possible they have adopted a profile they knew well
Yeah, that’s been pretty clear, which is why I’ve been wondering what the degrees of freedom are in terms of how closely, and why bother, to pretend such of any magnitude of conformation towards said ‘standard’ which simply does not match.
Bottom line is, what are the parameters, and what works.
But I guess he got it. I just wish I knew what the other end of this thing looks like lol. I’ll probably put a round flange on it, if I find time.
