SolveSpace Logo SOLVESPACE -- parametric 2d/3d CAD
Examples
Tutorials
Features
Download
Reference
Technology
Library
Forum
Contact
USER FORUM

(you are viewing a thread; or go back to list of threads)

threads, spiral shapes (by John Griessen)
Is there a practical way? Examples?
Sun May 17 2015, 23:31:51
(no subject) (by Blinkenlight)
Nope, not really (as far as I'm aware). Although if you're happy with something that only _looks_ like a thread, you can just draw a sawtooth-like "zig-zag" line and lathe it - it's not an actual thread but damn if I can tell just by looking at it... ;)
Mon May 18 2015, 16:31:56
Is there a practical way? (by John Griessen)
How about importing a spiral shape and combining it? Is that possible?
Tue May 19 2015, 13:03:14
Huh? (by Blinkenlight)
How do you intend to import _anything_? I have only seen SolveSpace open its own files...
Tue May 19 2015, 13:49:54
Spiral Shape Suggestion (by Roland Frank)
Hello.

For the spiral shape you could try your luck with a segmented
approach like I did the spring here:
http://solvespace.com/forum.pl?action=viewthread&parent=67
[View videos ...]

You could lathe circle to get a torus.
Then cut away (with box) half torus to get a "half ring".
Add together half rings of different inner diameters.

That should work ...

Roland
Tue May 19 2015, 16:51:58
Spiral Shape Suggestion (by John Griessen)
I suppose many segments could approximate a smooth spiral enough for a screw cap. Thanks for the idea.
Fri Jun 5 2015, 18:38:57
(no subject) (by EvilSpirit)
Just finished this for NoteCAD: http://notecad.xyz/?filename=thread.xml
This is based on additional parameter for revolution (lathe) and this can be easily implemented in SolveSpace (helical surface should be approximated with NURBS). Source code is here https://github.com/NoteCAD/Not...ode/Features/RevolveFeature.cs
Perhaps this helps to implement such feature in SolveSpace.
Sun Nov 4 2018, 13:06:07
(no subject) (by Paul)
This is one of those things I find conceptually and mathematically easy. Generating the control points and surface patches for an approximate spiral is easy. It's doing so in the SolveSpace code that is killing me. I'm starting to think that instead of trying to implement features I should try documenting some of the data structures...

BTW there are two ways to do helical things. One is to revolve the way the lathe tool does, but shifting the control points linearly along the rotation axis with each set. The other is to do like extrusion, but add several layers of control points rotated around the extrusion axis (2nd degree curves with points similar to arcs). The second one seems more suited to making things like fan blades.

The weird thing I found is that SS has multiple copies of points and curves. I made tapered extrusions (frustums) but the control cage remained straight and didn't line up. I even exported to stl and 3D printed such a shape. I have so far been unable to figure out what all needs to be done to make this complete.

On a somewhat related note, I think doing CAD with triangular NURBS surfaces could be an improvement. I think (but have not verified) that you could avoid the need for trimming NURBS by breaking things down into non-flat triangular patches with 3 NURBS curves for edges. This might require a whole new CAD program.
Sun Nov 4 2018, 16:31:40
(no subject) (by EvilSpirit)
Understanding of code written by someone else is the main skill of programmer. You should improve this skill, even if it seems painfully for you.

While doing real helix you should take derivatives to get tangent direction and rotate sketch in the way where normal and this direction will be codirected. I mean, if you want to sweep circular sketch, you should get circle in cross-section of helix, not an ellipse.

I think NURBS was a good idea several decades ago, but now we don't need to build our geometry based on approximations, so it is possible to use real surface equations. When we need result - we should approximate our surfaces with triangular mesh, because it is simple to draw and process. Using NURBS approach seems unreasonable overcomplicating to me.
Sun Nov 4 2018, 23:22:15
(no subject) (by Paul)
>> Understanding of code written by someone else is the main skill of programmer. You should improve this skill, even if it seems painfully for you.

Thanks for pointing that out. I've spent most of my career doing implementations mostly from scratch. I'm better at reading text and implementing code than the other way around.

>> I think NURBS was a good idea several decades ago, but now we don't need to build our geometry based on approximations, so it is possible to use real surface equations.

I spent a lot of time writing ray tracers that handle implicit surfaces (general quadric, torus, booleans). I don't see how you'd write a CAD program that handles exact representations for a lot of things. Best I can think of for a screw thread would be parametric involving trig functions - but it would be exact. Intersection boundaries can still become high order very quickly.
Mon Nov 5 2018, 13:57:04
(no subject) (by EvilSpirit)
> Intersection boundaries can still become high order very quickly.

Yes, this is still not solveable. But if you don't store approximated boundary but say this is intersection of surface with exact equations a and b. Also, we can store CSG representation which not require to store approximated values.
Tue Nov 13 2018, 06:24:03
Post a reply to this comment:
Your Name:
Your Email:
Subject:
(no HTML tags; use plain text, and hit Enter for a line break)
Attached file (if you want, 5 MB max):
© 2008-2022 SolveSpace contributors. Most recent update June 2 2022.