Question about spring.gif on wikibooks
In the section of the manual which describes linear_extrude():
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Using_the_2D_Subsystem#linear_extrude
There exists an animated GIF with a "spring and mass":
However I don't believe that this spring is generated with either linear_extrude() nor with rotate_extrude(). Unless someone can come up with the code.
For example if you take a snapshot of this animated GIF and if you imagine "cutting" the spring on the Z/Y plane, you would get a square cross section. This square would remain the same size regardless of the length of spring. But this is not how linear_extrude() works. linear_extrude(), when used with the 'twist' parameter, extrudes something that is defined on the X/Y plane, which in the case of this spring would be an object that is constantly changing in shape. Also rotate_extrude() does not have sufficient options (which are advertised) to produce this spring, unless some new options have yet to be documented for rotate_extrude().
While I have generated identical springs in my code and while I know how to do it, it seems to me that placing this spring GIF in the section for linear_extrude() is a case of false advertising, unless I am missing something blatantly obvious.
The reason why I caught this anomaly is because I was searching for a simpler way to make threads (NOT by defining individual polyhedron which I am doing now), using some sort of rotate_extrude()-related strategy, because I wanted that thread to appear correctly in FreeCAD when importing my piece into FreeCAD. I don't want to redefine my inventory of parts from scratch in FreeCAD (using Python).
Hope that made sense. Thanks.
Sent with Proton Mail secure email.
On 1/7/2024 2:38 PM, neri-engineering via Discuss wrote:
In the section of the manual which describes linear_extrude():
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Using_the_2D_Subsystem#linear_extrude
There exists an animated GIF with a "spring and mass":
However I don't believe that this spring is generated with either
linear_extrude() nor with rotate_extrude(). Unless someone can come
up with the code.
I doubt that it was generated using linear_extrude. (And it couldn't be
generated using rotate_extrude.)
If you look at the image's own page:
https://commons.wikimedia.org/wiki/File:Spring_100x20_in_OpenSCAD.gif
then you'll see a comment:
Spring Not Possible to construct using linear or rotate extrude
[...] it seems to me that placing this spring GIF in the section for
linear_extrude() is a case of false advertising,
Yep. I think we should have a general rule that any image in the manual
needs to be accompanied by the SCAD program that generated it.
I've removed it. (I think that will remove it from a number of
generated pages. I left it in the page that discusses animation.)
It probably is possible to generate that spring using linear_extrude.
I've generated a circular-cross-section helix using linear_extrude. But
it is no fun at all; for the circular-cross-section one the 2D shape
that you start with looks sort of like a banana. I have no idea how to
calculate that shape; I think I generated the helix somehow (BOSL2?),
used projection() to grab a slice, and then extruded that slice to prove
that I could do it. The shape of that original slice would depend on
the "angle" of the helix, so for the spring animation it would be
different for each frame.
It probably is possible to generate that spring using linear_extrude. I've generated a circular-cross-section helix using linear_extrude. But it is no fun at all; for the circular-cross-section one the 2D shape that you start with looks sort of like a banana. I have no idea how to calculate that shape; I think I generated the helix somehow (BOSL2?), used projection() to grab a slice, and then extruded that slice to prove that I could do it. The shape of that original slice would depend on the "angle" of the helix, so for the spring animation it would be different for each frame.
I totally understand your "banana theory" because I was trying to do something similar to generate a thread, by way of linear_extrude(), where the cross section was something like a circle which was offset just a little. But even then, I don't think it duplicated the thread exactly. I have superficially decided that using linear_extrude() in this way, by computing a fancy cross section, isn't feasible; at the very least the computation of the cross section is complex, and even then, I believe that it can be shown that the extrusion will lead to different "curvatures" than would be achieved by passing a 60 degree cutter on a lathe, to generate a screw thread.
It would be nice to add a modification to rotate_extrude() that does a sweep angle which can be greater than 360, and which "translates" by some amount z_off per each 360 made. I'm sure I could do it if I knew where the OpenSCAD code is. This way making threads would be so much easier, and the generation would potentially carry over to FreeCAD, once the associated "workbench" changes are made in the workbench in FreeCAD.
On 1/7/2024 4:23 PM, neri-engineering via Discuss wrote:
I totally understand your "banana theory" because I was trying to do
something similar to generate a thread, by way of linear_extrude(),
where the cross section was something like a circle which was offset
just a little. But even then, I don't think it duplicated the thread
exactly. I have superficially decided that using linear_extrude() in
this way, by computing a fancy cross section, isn't feasible; at the
very least the computation of the cross section is complex, and even
then, I believe that it can be shown that the extrusion will lead to
different "curvatures" than would be achieved by passing a 60 degree
cutter on a lathe, to generate a screw thread.
Nah, with the right initial slice you can generate a perfect helix.
Consider: take a perfect helix. Now, take a horizontal slice of that
helix anywhere you like. All of those slices will be identical to one
another, give or take rotation. If you linear-extrude-with-twist that
slice, you'll get the helix back. (Give or take the resolution of your
slice and your extrusion, of course.)
It would be nice to add a modification to rotate_extrude() that does a
sweep angle which can be greater than 360, and which "translates" by
some amount z_off per each 360 made. I'm sure I could do it if I knew
where the OpenSCAD code is. This way making threads would be so much
easier, and the generation would potentially carry over to FreeCAD,
once the associated "workbench" changes are made in the workbench in
FreeCAD.
I'm pretty sure that rotate_extrude, even with a "translate" option,
can't generate a correct helix either. The problem is that it would
take a circle and advance it up and around the helix, but the circle
would stay aligned with the Z axis. The circular cross-section for the
helix needs to be perpendicular to the "angle" of the helix. I'm sure
that there's a slice that would work, just as there is for
linear_extrude, but it probably be some ellipse-like shape.
And as for where the OpenSCAD code is, that's not a secret :-)
https://github.com/openscad/openscad/
Caution: rotate_extrude of over 360° risks self-intersection.
Nah, with the right initial slice you can generate a perfect helix. Consider: take a perfect helix. Now, take a horizontal slice of that helix anywhere you like. All of those slices will be identical to one another, give or take rotation. If you linear-extrude-with-twist that slice, you'll get the helix back. (Give or take the resolution of your slice and your extrusion, of course.)
A perfect thread has a flat valley and flat "tips" (see image below). For that reason it's probably not possible to come up with a linear_extrude(). I don't want to prove this because it's not worth my time, but I am a mathematician. linear_extrude() of a cross section of perfect thread will create a sinusoidal thread, which won't have "straight" edges, a "straight" valley and "straight" tips.
I'm pretty sure that rotate_extrude, even with a "translate" option, can't generate a correct helix either. The problem is that it would take a circle and advance it up and around the helix, but the circle would stay aligned with the Z axis. The circular cross-section for the helix needs to be perpendicular to the "angle" of the helix. I'm sure that there's a slice that would work, just as there is for linear_extrude, but it probably be some ellipse-like shape.
A thread is generated by taking a trapezoid (a four-faced polygon) and rotating it around, and moving it along the axis of rotation while it's being rotated around. Image below, it's my generator code. Thanks for the tips on where the code is. Yes it would be very doable, it would be a cinch. I also understand your comment regarding self-intersection. Very true.
[thread.png]
Nah, with the right initial slice you can generate a perfect helix. Consider: take a perfect helix. Now, take a horizontal slice of that helix anywhere you like. All of those slices will be identical to one another, give or take rotation. If you linear-extrude-with-twist that slice, you'll get the helix back. (Give or take the resolution of your slice and your extrusion, of course.)
A perfect thread has a flat valley and flat "tips" (see image below). For that reason it's probably not possible to come up with a linear_extrude(). I don't want to prove this because it's not worth my time, but I am a mathematician. linear_extrude() of a cross section of perfect thread will create a sinusoidal thread, which won't have "straight" edges, a "straight" valley and "straight" tips.
Actually on second thought I realize that you're probably right. I was lacking a slight detail in the cross section, but that detail was very important. Every cross section is identical but rotated along the Z. That is the key to the proof.
Jordan Brown wrote:
On 1/7/2024 2:38 PM, neri-engineering via Discuss wrote:
I left it in the page that discusses animation.
That section is a prime example of how not to write a user manual. For a start the heading should be “Animation” and not “$t” because any user wanting to find out how to animate their design is not going to be looking for $t.
3rd line: “With this information in mind, you can animate your design.” - Really??? Not one mention of $t*360 or the different motions that are possible, let alone how to program them!
“Naming convention” - Who cares?
Worse than useless to a user - just a tease and a waste of time.
Fortunately there is this Forum with a lot of helpful people.
[ Discussing
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Other_Language_Features ]
On 1/21/2024 4:31 PM, Caddiy via Discuss wrote:
That section is a prime example of how not to write a user manual.
It's a wiki. If there's a problem with the material, you can figure out
a better way to present it and fix it. I'm pretty sure that no special
privileges are required.
For a start the heading should be “Animation” and not “$t” because any
user wanting to find out how to animate their design is not going to
be looking for $t.
Yeah, the section headers there are a Q&A that's indexed by answer, not
by question.
I added words to the headers for the $ variables so that you have more
of a chance of finding the question you're looking for.
3rd line: “With this information in mind, you can animate your
design.” - Really??? Not one mention of $t*360 or the different
motions that are possible, let alone how to program them!
It's a reference manual, not a tutorial. It should have some examples,
but real how-to-use belongs elsewhere. One could probably write a small
book on OpenSCAD animation techniques.
“Naming convention” - Who cares?
Anybody trying to make sense of the output :-)
But I agree, it's pretty opaque - especially since it appears to be
somebody analyzing the behavior from outside, without looking inside to
see what's really happening. I doubt that it's really as complex as
they describe, and if it is then it's a bug that needs to be fixed.
Jordan Brown wrote:
It's a wiki. If there's a problem with the material, you can figure out
a better way to present it and fix it. I'm pretty sure that no special
privileges are required.
I might just have a bash at that. Someone may need to check the layout and style though.
I added words to the headers for the $ variables so that you have more
of a chance of finding the question you're looking for.
That looks better!
One could probably write a small book on OpenSCAD animation techniques.
Simple harmonic, circular, elliptical motion, full and part rotation/different speeds - anything else? I couldn’t provide anything on Turtle or sweep.
On 1/21/2024 6:25 PM, Caddiy via Discuss wrote:
One could probably write a small book on OpenSCAD animation
techniques.
Simple harmonic, circular, elliptical motion, full and part
rotation/different speeds - anything else? I couldn’t provide anything
on Turtle or sweep.
Well, I'm not quite sure how it would fit into those categories, but
take a look at
https://files.openscad.org/advent-calendar-2023/PorchPirate/Porch%20Pirate.webp
and its implementation:
https://files.openscad.org/advent-calendar-2023/PorchPirate/Porch%20Pirate.scad
It's largely driven by tables that control the position, size, and
rotation of various components at various times, with interpolation.
(Once I got the basic infrastructure in place, the problem was actually
one of direction, not technology - I had to decide what I wanted to
happen, when.)
Or https://www.youtube.com/watch?v=6qNHy48iOOs
which is driven by a simpler table, but does first-person view.
https://imgur.com/a/5N20EP6
implementation: https://bpa.st/3VNA
in a sense just rotates one component, but it then calculates the
mechanical effects on the other components.
Take a look through the Advent calendars for animations by other people
with various interesting behaviors. neri-engineering has some great
videos too.
Can you condense those techniques down into a page or two? Maybe, but I
kind of doubt it.
Heck, you might be able to spend a page just on why you might want to
animate a model.