Don't you just want to rotate the inner gear twice as far because it needs
to rotate twice for a full rotation of the cams? You don't need more
frames, it just needs to move twice the angle in each frame.

On Sun, 6 Jul 2025 at 08:15, Caddiy via Discuss discuss@lists.openscad.org
wrote:

nop head wrote:

The inner gear does rotate twice for a full rotation of the outer gears - at least that is the illusion, as the inner gear rotates at $t*360 and the outer gears rotate at $t*180. It works for the outer gears because they have even numbers of teeth and holes. But the cams have an odd number of lobes (one). It would, of course, all work fine if the speeds were doubled BUT there is another shaft with gears in the model (at the top in frame 82) that already runs at $t*720, which would have to be sped up to a dizzying $t*1440, and I would like to avoid that if possible, as it raises other issues.

I figured that two cams appearing and disappearing alternately, instead of one, each sweeping opposite 180° sectors in succession, would fix it as a workaround. Maybe there is another way of doing it without doubling the speeds?

(The cams look terribly narrow, but that’s how they are in the drawing.)

You don't need to double the speed, you just need the gear to rotate twice
as far. You can make the animation last twice as long.

To make something disappear you could just wrap it with if($t < 0.5).

On Sun, 6 Jul 2025 at 12:22, Caddiy via Discuss discuss@lists.openscad.org
wrote:

nop head wrote:

Twice as far in twice the time sounds interesting! Can that be applied to $t*180 to get full 360° rotation with half-speed?

I have got this far:

if($t > 0.5)

rotate([0, 0, $t*180])

translate([101, 0, 0])

color("red")

circle(50);

if($t < 0.5)

rotate([0, 0, $t*180])

translate([-99, 0, 0])

color("blue")

circle(50);

rotate([0, 0, $t*360])

color("black")

square([2, 160]);

The black line rotates at $t*360. The coloured circles go round at half speed, but only do half a circle. How can they be made to do a full circle at half-speed?

Or there is this:

rotate([0, 0, $t*180])

translate([101, 0, 0])

color("red")

circle(50);

rotate([0, 0, $t*180])

translate([-99, 0, 0])

color("blue")

circle(50);

rotate([0, 0, $t*360])

color("black")

square([2, 160]);

How could the two circles be made to disappear alternately, instead of simultaneously, to give the impression of a single circle that changes colour instead of two? Can if($t < 0.5) be advanced/retarded by 180°?

To make the inner gear turn twice as far use $t * 720, to get two turns as
$t goes from 0 to 1.

To make the animation take twice as long, so that it rotates at the same
speed, double the number of steps, so each frame increases $t half as much
and you twice as many frames. Or you could halve FPS but then it might look
a bit jerky.

On Sun, 6 Jul 2025 at 20:09, Caddiy via Discuss discuss@lists.openscad.org
wrote:

nop head wrote:

Yes, that would work, but no I don’t want to do that because the extra shaft would then have to rotate at $t*1440 instead of the present $t*720. The model I am working on has parts rotating at three different speeds: camshafts rotating at half crankshaft speed and a synchronising shaft (that’s what I will call it) rotating at double crankshaft speed.

The animation would take twice as long by the clock on the wall, but the $t clock would remain unimpressed.

Is there some other way to get either real or virtual full 360° rotation with $t*180? I think I need a time machine. Must see what ebay has to offer.

$t isn't a clock. It is just how far through the animation you are. It goes
from 0 to 1 in the number of steps you specify. That clock time that takes
will be the FPS / steps.

On Sun, 6 Jul 2025 at 21:26, Caddiy via Discuss discuss@lists.openscad.org
wrote:

nop head wrote:

The problem is that the number of FPS / steps you specify controls everything. It is not possible to apply one number of FPS / steps to one part and another number of FPS / steps to another part. How to work around that?

You scale $t in each part of the code to move its full distance when it
goes from 0 to 1. Then you set the number of steps and FPS to get the
correct total time and smooth enough motion.

On Sun, 6 Jul 2025, 21:51 Caddiy via Discuss, discuss@lists.openscad.org
wrote:

nop head wrote:

Doesn’t that preclude the use of $t*180?

If you want it to turn half a turn use $t * 180. If you want it to turn a
full turn use 360, etc. You scale every use of $t to make each part move to
its final position. Then every thing is synchronized.

On Sun, 6 Jul 2025, 22:01 Caddiy via Discuss, discuss@lists.openscad.org
wrote:

On 7/6/2025 2:13 PM, Jordan Brown via Discuss wrote:

Sigh.  "either harder than ..."

Jordan Brown wrote:

This is getting quite philosophical!!!

Well, yes and no. I have a model with things rotating at three different speeds. I want to rotate them at $t*180, $t*360 and $t*720. Not $t*360, $t*720 and $t*1440. If possible.

But $t*180 only does half a turn.

So I am looking for a workaround to give at least the illusion of a full turn.

How could two $t*180’s be made to work in tandem, but without producing two circles?

Could one $t*180 be stopped before it flips back from 1 to 0, while the other is working?

If there are two orbiting circles, each following a 180° arc, could they be alternately hidden to give the appearance of one circle moving continuously?

Something else?

mikeonenine@web.de wrote:

I would like to rephrase that:

If there are two circles, each following opposite 180° arcs, could they be alternately hidden to give the appearance of one circle orbiting continuously?

Why do you want to do that. Why not have a single circle always visible
doing a full orbit?

On Sun, 6 Jul 2025, 22:46 Caddiy via Discuss, discuss@lists.openscad.org
wrote:

nop head wrote:

Cos it’s too easy.

No.

I want rotations of $t*180, $t*360 and $t*720.

Not $t*360, $t*720 and $t*1440.

To keep speeds down.

If possible.

Speed is set by steps and FPS. $t is used to determine how far each part
moves. It is nothing to do with the speed other than it sets the relative
speeds of different parts.

On Sun, 6 Jul 2025, 22:59 Caddiy via Discuss, discuss@lists.openscad.org
wrote:

On 7/6/2025 2:45 PM, Caddiy via Discuss wrote:

No, because you need that one circle to go all the way around.  If, say,
you want to avoid jumps larger than one degree, you must have at least
360 frames, because there are 360 different places that the circle can be.

You can't make one iteration of the animation be different from the next
iteration... because then they would be two different animations.

Jordan Brown wrote:

180 + 180 = 360.

With the code I posted earlier on, the two circles don’t jump. But I want one circle. Surely it’s just a matter of hiding them alternately, so it looks like one circle?

Nophead came up with if($t < 0.5) but how could it be timed +$t*90 and -$t*90 respectively for each circle, to hide the circles alternately?

Jordan Brown wrote:

Yes, that is exactly the problem I want to avoid, to keep things manageable.

On 7/6/2025 3:27 PM, Caddiy via Discuss wrote:

What does "alternately" mean?

You make an animation that takes 10s to get a circle across the top.

You then need to spend the next 10s to get the circle across the bottom.

That's a 20s animation.

Print it onto film, so that we can talk about actual frames.  You need a
sequence of frames that run the circle across the top, and a sequence of
frames that run it across the bottom.  There's no trickery possible that
will somehow make the second time that you run the film be different
from the first time.  The film simply must continue until the elements
return to their original positions.

Now, to be clear, "original positions" does not quite have its obvious
meaning.  If you're animating a gear, each time you advance one tooth
you're back to something that looks the same, so you only need to
animate one tooth's worth.  If you put a mark on the gear, though,
you're back to having to animate the entire rotation.

Jordan Brown wrote:

What I mean is:

You make an animation that takes 10s to get one circle across the top 180°*,* after which it disappears for 10s.

You then need to spend the next 10s to get the other circle across the bottom 180°*, after which it disappears for 10s.*

Then repeat the sequence.

What does if($t < 0.5) mean in plain English? If $t is less than 0.5, then what? $t doesn’t go negative.

On 7/6/2025 4:12 PM, Caddiy via Discuss wrote:

That's a 20s animation.

Again, think of a loop of real film.  To get a complete cycle, you need
10s of a circle going across the top, and 10s of a circle going across
the bottom, and then back to the start.You can't play the same 10s piece
of film twice and expect to get different images on the second time
through.

Over the length of the animation, $t runs from 0 to 1.  $t is less than
0.5 for the first half of the animation, and is greater than or equal to
0.5 for the second half of the animation.

The "if" is a standard OpenSCAD "if".  It does whatever you tell it to,
when the condition is true.

For instance.

if ($t < 0.5)
	square(10, center=true);
else
	circle(d=10);

will be a square for the first half of the animation, and a circle for
the second half.

This will do exactly what you're suggesting:

if ($t < 0.5)
    color("red") rotate($t*360) translate([10,0,0]) circle(3);
else
    color("blue") rotate($t*360) translate([10,0,0]) circle(3);

But if you want it to take 10s for the red circle to go across the top
and 10s for the blue circle to go across the bottom, that's 20s.  Set
the FPS to whatever you like, and set the number of frames to twenty
times that - so perhaps 5 and 100.  That's what you must do if you want
the circle to change color, but if you wanted it to stay the same color
then all you need is

color("red") rotate($t*360) translate([10,0,0]) circle(3);

Jordan Brown wrote:

Thanks. It works fine, but it’s too damn fast for me. It’s the standard $t*360 speed.

So it seems $t is the time and 360 is the distance around a full orbit. Unfortunately it is not possible to give the 360° extra time for it to go slower.

Would it be possible with $t*180 to use an “else” statement to tell it to disappear when it reaches $t = 1, then start again at 0 after an interval of $t = 1?

On 7/6/2025 6:05 PM, Caddiy via Discuss wrote:

How fast it is depends on your FPS and your number of frames.

If you set FPS to 1, it will be slow.

Yes.

Yes, sort of.  $t*360 is saying "during the animation, vary from zero to
almost 360".

Pedantic node:  We've been saying $t=1, but it never actually
reaches 1.  It stops and loops back to zero one frame before $t=1,
so that a loop that yields the same image for $t=0 and $t=1 doesn't
have the same frame twice.

"Extra time" isn't really meaningful.  If you say "$t*360", it will take
exactly the length of the animation to make it all the way around.  It
can't take longer than that, because the animation is done when $t=1.

If you have something else that needs to move faster, multiply $t by a
bigger number - say, if you have another thing that needs to rotate
twice during the animation, it would be "$t720".  Look back at my clock
example, where the hour hand, the minute hand, and the second hand all
rotate at different speeds.  The hour hand is $t360, so it goes around
once during the animation.  The minute hand is $t36012, so it goes
around twelve times.  The second hand is $t1260, so it goes around 720
times.

If you have something that needs to move slower, then it needs to be
the thing that uses $t*360, and your original thing needs a larger
multiplier so that it will go around more times.

The animation only runs from $t=0 to $t=1.

There is nothing after 1.  That's the end.  Fini.  Then the animation
engine starts over, but it starts over from $t=0; absent random numbers
it will produce the same sequence of frames.

The universe begins at $t=0 and ends at $t=1.  You must set FPS and the
number of frames to control how many frames and how many real-clock
seconds that is.

(Actually, the FPS is pretty worthless in a lot of animations, because
once it takes more than a small fraction of a second to run your
program, the animation engine can't keep up.  What ends up mattering for
the final product is the parameters that you give to your video-creating
tool when you have it combine the frames.)

If it's easier for you to understand, you can do something like this:

FPS = 10;
FRAMES = 1000;
seconds = $t * FRAMES / FPS;

and always set your animation parameters to 10 and 1000.

Or more correct and less tightly tied to the parameters would be:

LENGTH = 100;
seconds = $t * LENGTH;

and set your FPS and number of frames so that frames divided by FPS is 100.

But for this kind of animation, where you have some piece of the action
that needs to make a complete circle, it's probably better to base
everything directly off of $t and thus what fraction of that complete
circle has gone by.  In the clock example, the hour hand goes around
once during the animation, and when we're 1/1000th of the way through,
the hour hand has gone around 360/1000 degrees, the minute hand has gone
around 12*360/1000 degrees, and so on.  I could base it on seconds,
but that only makes sense because it is a clock; if it was something
else going around then it wouldn't directly make sense.

You could work in seconds, but then you'd have to figure out how many
seconds it would be for your model to go through its full cycle, and
pretty much everything would cancel out so that you'd effectively be
back to working in that "fraction of a cycle" model.

Jordan Brown wrote:

That makes sense.

Animation goes in steps with certain intervals. What about generating a new image every 2nd, 3rd or nth step?

I am already at $t720. Unless I find a solution, I will need $t*1440. That will require a large number of steps and generate a large number of frames. But my video program can skip every second or third frame.

The clock example must be the worst case scenario! My engine also has three different speeds but they only range from half speed to double speed -  a factor of 4, but that’s bad enough if the range has to go from standard to quadruple speed.

Would it not be possible to introduce an interval between $t=1 and $t=0 equal to the time taken for a run from $t=0 to $t=1?

Or introduce some kind of a dummy run inbetween live runs?

I wish I had studied computer programming!

On 7/6/2025 9:27 PM, Caddiy via Discuss wrote:

Not that your program can see.  At any given invocation it sees a single
value of $t.  It has no idea how frequently $t changes.

The best way to think of that aspect is that your program is going to do
whatever it does, and the camera guy is going to run the camera at
whatever frame rate he likes.

Or another way to look at it is that your program is asked to generate
an image of the model at a particular moment in time, and doesn't know
that somebody outside is going to ask it many times so as to build a video.

Absent manually matching up values in your program with your animation
settings, no.

Yep.  Again, look at the clock... the need for smooth animation of the
second hand, compared to the ratio between the second hand and the hour
hand, tells you how many frames you need.  There's no getting around it

• the hour hand has to go all the way around, and during that time the
  second hand has to go around 720 times, and to have it move smoothly you
  need a certain number of frames per time that it goes around.  If you
  want it to jump one second at a time (like many real clocks do, by the
  way), you need 60 frames per minute, 3600 frames per hour, 43,200 frames
  per 12 hours.

But if it's OK to show fewer frames... tell the animation control panel
to generate fewer frames.  You might try playing with the clock.  Tell
it FPS=1, frames=43200, and watch it look like a normal clock.  Then
tell it FPS=0.1, frames=4320, and watch it jump ten seconds per frame. 
Many fewer frames, much more jumpy, though still running at correct
"clock" speed.

There is no interval between $t=1 and $t=0.  That's like talking about
the interval between the last frame of the film and the first frame of
the film, when you've pasted the film into a loop.

If you really want a range from 1 to 2 after the range from 0 to 1, here
you go:

$t2 = $t * 2;

$t2 will range from 0 to 1, and then from 1 to 2, and then jump back to 0.

That doesn't really change the picture any, but if it makes you happier :-)

There is no "between".  There is nothing before 0, and nothing after 1. 
And from the perspective of your program, there's no "second run".  It
can't tell how many times it's been run, or what $t was on the previous
runs.

It's kind of more math than programming per se.

What you need to do in OpenSCAD animation is to map the 0..1 clock that
you get from $t into whatever timeline you need.

If you need to rotate something once during the animation, use $t360 to
map 0..1 into 0..360.
If you want to lift something 10 units up in Z during the animation, use
$t10 to map 0..1 into 0..10.
If you want to move something, and then move it back to the original
place, 1-abs(2*$t-1) will map 0..1 onto 0..1..0.

And the other thing you want to do is also mathematical:  you want to
recognize the periodicity of your model's motion, so that you know how
long you have to animate before you get back to the original state.  For
instance, here's a program that rotates a square.  It only needs to
rotate 90 degrees, one quarter of the "full" animation, because after 90
degrees you're back to something that looks like the original, and
looping will do the rest for you:

rotate($t * 90) square(10, center=true);

Going back to your cams and gears, you must turn the big gears all the
way around, because that's how much you need to get the cam back to its
original position, and you must rotate the other gears to match.  The
frame rate interaction with the gears is simpler than it first seems (or
at least than it first seemed to me), because the linear speed along the
gears in a flat connected chain of gears is constant - when you turn one
gear one tooth, all of the other gears turn one tooth.  The difference
is that for some of them that's 1/60 of the way around, while for others
it's 1/30 of the way around.  So if you decide that you need, say, three
frames per tooth-step, so that a tooth starts at the zero position, then
1/3 of the way to the next position, then 2/3, and then it's at the next
position, and you have 60 teeth on your big gear, you need 3*60 = 180
frames.  Each frame will step your big gear two degrees, and will step
your smaller gear four degrees.  Your smaller gear will be jumpier, but
will still get three frames per tooth-step.

Stacked gears can change the linear speeds of the teeth, and make the
picture more ... interesting.  (Your cams are sort of a degenerate case
of that.)

For a demonstration of a similar rotating animation, take a look at day
20 of

https://openscad.org/advent-calendar-2023/

There is no need to generate extra frames and then skip them in your video
creation tool. The number of frames is set by Steps and the total time (and
hence the speed of the movement) is FPS / Steps. The amount each part moves
during the animation is how much you multiply $t by.

If you double all the $t multipliers then each gear will move twice the
distance. If you double Steps then they will move at the same speed they
did before and the animation will take twice as long. If you have too many
frames then reduce FPS and Steps to keep them in the same ratio to give the
animation the right duration and things more at the speed you want. I.e.
Set Steps to how many frames you want and FPS / Steps to the time you want
it to last, so the parts move at the speed you want.

Often the frames are not generated fast enough in real time in OpenSCAD but
when you make the video you specify the same FPS it will be real time when
it plays.

On Mon, 7 Jul 2025 at 07:54, Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:

I don't have much idea about animation in openSCAD.
Sketched a very simplistic animation in python.

On Sun, 6 Jul, 2025, 12:45 pm Caddiy via Discuss, <
discuss@lists.openscad.org> wrote:

Could you use the alpha channel in 'color(r,g,b,alpha)' perhaps?

On Mon, Jul 7, 2025, 12:47 Sanjeev Prabhakar via Discuss <
discuss@lists.openscad.org> wrote:

If I understand you right, you can either double the # frames, or render
two films, one with your cam the other one without it, and concat the
pieces later in your video editing program.

Am 06.07.2025 um 14:03 schrieb nop head via Discuss:

On 7/7/2025 10:24 AM, Marko Kleine Berkenbusch via Discuss wrote:

Can you use it?  Of course.  (Though, hmm.  Some variations emit
transparency into the resulting PNG, which means that your background
when you are viewing can leak through.  You probably don't want that.)

Will it help reduce the number of frames?  No.  You need enough frames
to reproduce your entire cycle, at a desired frame rate.  Making things
appear and disappear may (but not in this case) be useful as part of
building your animation, but can't help reduce the number of frames.  If
you need a frame with a circle positioned at the 5:00 position, you need
a frame with a circle at that position; a frame with a circle at a
different position will never help.

Jordan Brown wrote:

Could you expand on that? Is program = my script/code?

There is no interval between $t=1 and $t=0. Granted. But it is not a valid argument. May I remind you of your “pedantic mode” further up. With n frames, the animation runs from 0 to n-1, as 0 and n are identical. So what we really want to talk about is the interval between n-1 and 0, which does exist.

Well, there we are! Swings and roundabouts. We are still going to get the same number of frames as when the cams are run at $t*360. Running them at $t*180 won’t help!

On 7/7/2025 3:01 PM, Caddiy via Discuss wrote:

Yes.

Er, maybe, kind of, but mostly no.  After n-1 comes 0.

Yeah, you're pretty much stuck:  you need to spin the big gears 360
degrees to get the cams back into the original position, and I think you
need at least three frames per tooth-step to make sure the gear appears
to spin in the right direction, and your big gear has 60 teeth, so I
think you need a minimum of 180 frames.

Though, hmm.  You might be able to get clever.  On its face, you need to
step three times per tooth-step, to keep the teeth looking like they are
spinning in the right direction.  But if you do steps that are
significantly larger, if each frame steps 4/3 of a tooth-step, I think
it'll still look like it's spinning in the right direction, but take
something like a quarter as many frames.  So you might try using 180/4 =
45 frames.  I think you'll end up with an optical illusion where it
looks like the teeth of the gear are spinning slower than the cam is
spinning, but it might not be too bad.

On 7/7/2025 3:40 PM, Jordan Brown via Discuss wrote:

Expanding a little more...

Your program sees a clock that runs from zero to one, and has no idea
how the animation engine is using that clock.  It doesn't know whether
it's one frame per second or a hundred, and it doesn't know whether
there are ten frames or a thousand.

For a mechanical demonstration like you're doing, that's mostly OK.  You
make the model run through its cycle as the clock ticks from zero to
one, and your program doesn't care how fast it's running.  When you, the
human, start up the animation engine, you control that.  You can make it
run fast, so that it takes ten seconds to complete a cycle, or slow, so
that it takes ten minutes.  You can make it very smooth, at 60 FPS
(after converting to video; the OpenSCAD engine won't be that fast) or
very jumpy at 2FPS.  Your program doesn't need to know.

But if you are doing something where time matters, like the Porch Pirate
animation at https://openscad.org/advent-calendar-2023/ day 24, your
program wants to do things at particular times.

To do that, you can promise yourself that you will set particular
animation parameters.

You can, if you really feel the need, tell the program the FPS and total
number of frames that you'll set, and then your program can calculate
both time and frame number.

// Set these into the animation engine.
FPS = 10;
FRAMES = 100;

// Derive other values.
duration = FRAMES/FPS;
currentTime = duration * $t;    // in seconds
currentFrame = FRAMES * $t;

but more likely you just want to know the total duration:

// Set FPS and frames so that frames/FPS is 60.
// So maybe FPS=10 and frames=600, or FPS=5 and frames=300.
DURATION = 60;    // seconds
// Derive other current time.
currentTime = duration * $t;

In Porch Pirate, that calculation is at line 209.

I have a kind of fun animation demo and timeline management
infrastructure that I've been playing with for a couple of days, but
unfortunately it depends on a not-yet-merged feature (PR #6012, an
evolution of #4337 and subset of #4478) so it wouldn't be all that
interesting for most people.  I'll post it when we get 6012 merged.

Jordan Brown wrote:

Yeah. That’s something I thought about too. I would attack the problem from the other end and apply the principle to the fastest-rotating gears, the ones at the top, so I don’t need to run them at $t*1440. I need to find a $t value that makes them look convincing without hopping or looking too fuzzy. I will do a new animation with just the gear in question for test purposes. Then it should be possible to run the camshafts at $t*360, (the cranks at $t*720) and still get good results with only 180 frames.

Sanjeev Prabhakar wrote:

That’s interesting. Similar to the if($t < 0.5) command.

Can you put some off-centre mark in the large gear, let it turn 180° and disappear, make a second large gear (a copy of the first) appear, turn it 180°, let it disappear, let the first gear reappear and so on, so that it looks like only one gear?

Of course, if it still looks like just one gear, the animation will not be very exciting.

Python: It seems very popular and I considered taking a closer look at it, but I read somewhere that it has safety problems. Is that true?

I think it can be done the way you mentioned.

I need to go for my morning walk now and will give it a try later in the
day once I have some time.

As far as safety with python , I don't know much frankly. I am using it for
more than 2 years and till now did not find any such problem. I am not a
software engineer anyway.

On Tue, 8 Jul, 2025, 5:16 am Caddiy via Discuss, discuss@lists.openscad.org
wrote:

On 7/7/2025 4:45 PM, Caddiy via Discuss wrote:

Yes and no.

If you only ever run your own programs, there's no problem.
If you carefully inspect other people's programs before running them,
there's not much of a problem.
If you download other people's programs and run them without looking at
them, there is at least a theoretical problem.

The difference is that an OpenSCAD-language program really can't do
anything, but a Python program can do anything that you (the user) can
do.  (Newfangled container technologies might help.)  The OpenSCAD
language has no mechanism for, for instance, writing to a file, or
deleting a file, or making a network connection.  Python has all of
those things.  If you download and run a malicious OpenSCAD-language
program, the worst that it can do is chew up a bunch of CPU time and
memory and make you forcibly close OpenSCAD.  If you download and run a
malicious Python program, it can scribble on any data that you, the
user, can scribble on.  It can install bots that will mine Bitcoin for
the villains.  It may be able to install a bot that monitors your
keystrokes and the contents of your screen.

Practically, is Python+OpenSCAD a large enough target for any villain to
try to do those things?  Maybe, probably not.

Jordan Brown wrote:

Worth a second look, then. Something for the long winter evenings.

On 7/7/25 20:05, Jordan Brown via Discuss wrote:

Another program I use heavily is now called LinuxCNC, mostly written in
the original python & gradually converted to python3 now.  The usr count
in machine shops around the planet may exceed the usr's here. In my 25
year history of it, no one has managed to attack us that I can recall.
All my machines here can browse the net, its one of my setup
requirements but they are isolated, all at non-routable 192.168.xx.yy
addresses NATed by the router. That seems to be all the protection
needed to keep the blackhats on the other side of the router.

Cheers, Gene Heskett, CET.

--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis

On 7/7/2025 4:19 PM, Caddiy via Discuss wrote:

Assuming that you stick with flat gears - not stacked - the rotational
speed really isn't an issue, per se.

Across a flat gear chain of any size, the linear speed along the edge of
the gear is the same.  If you turn any gear in the system one tooth
forward, all of the other gears will also turn one tooth.  Gears with
fewer teeth require fewer tooth-steps to turn around, but that's not
your animation problem.  You need to ensure that you get enough frames
to show a tooth - any tooth, all of the teeth - getting from one
position to another.  Except perhaps for the step-skipping hack I
mentioned, it seems to me that that would mean at least three frames per
tooth-step.  (Actually, it appears to that any number greater than two
works.)

I built a quick test with a 60-tooth gear, a 20-tooth gear, and a
10-tooth gear.  That's $t360, $t1080, and t2160, for those who care
about the numbers.  (I represented them as 360, 3360, and 6*360.)

It runs at about 3FPS on my system, and looks OK with 180 frames. 
Actually, it's not bad down to about 140.  What's important is that each
frame steps a tooth less than half a tooth-step.

As soon as you start stacking gears - so that, say, turning a 60-tooth
gear turns the 30-tooth gear on top of it, the tooth-step speed changes
and you have to look at the ratios between the tooth-step speeds.

I don't think that you want to muck with the gear speeds per se.  You
want the model to do what the actual machine does.  If gear A spins ten
times as fast as gear B, then that's what it does.  If you try to mess
with those ratios, the teeth won't mesh properly.  (And, again, for a
flat gear chain what matters is the linear speed along the edge, not the
rotational speed.)

Once you have the machine operating properly, then you need to figure
out the camera parameters that let you take good video of it.  Just like
a real machine with a real camera, the frame rate controls what kind of
stroboscopic effects you get.

Here's that test program:

include <BOSL2/std.scad>
include <BOSL2/gears.scad>
$gear_steps = 2;
rotate(3360$t) {
spur_gear(circ_pitch=5, teeth=20, thickness=8, shaft_diam=5);
color("black") right(5) cube([10,1,10], center=true);
}
translate([25,0,0]) rotate(-6360$t) {
spur_gear(circ_pitch=5, teeth=10, thickness=8, shaft_diam=5);
color("black") right(5) cube([10,1,10], center=true);
}
translate([-64,0,0]) rotate(3-360*$t) {
spur_gear(circ_pitch=5, teeth=60, thickness=8, shaft_diam=5);
color("black") right(5) cube([10,1,10], center=true);
}

I think the proper BOSL2-y way to do it would have been to use anchors
and attachment to position the gears, and there's a parameter
(gear_spin, I think, but I don't have the docs up) that spins just that
one gear without spinning its attachments.  But I wanted to stick mostly
with base OpenSCAD operations.

On 7/7/2025 6:13 PM, gene heskett via Discuss wrote:

Written in Python isn't a problem.  (Or at least no more of a problem
than downloading any other software.)

What makes a Python+SCAD variant somewhat worrisome is that you are
tempted to download models written in Python.

That takes you from downloading one program that other people (maybe
many other people) have watched and used, to downloading dozens of
programs written by single people, that may never have been looked at by
other people.

In theory you might get an e-mail message apparently from a friend that
says "hey, look at this cool model that I made".  You run it, and it
eats your data.

you could very easily address This issue, by not referring the Editor
content as "Model"  but rather as Snippet/Code

I propose this definition:

STL/3MF/AMF/OBJ    Model
SCAD                          (CSG ) description (Its  descriptive language
only)
PY                                Code/Snippet

SCAD files are NOT models, because (most) slicers can probably not
proicess them

Having this small "correction" in people's minds will not turn python code
into a monster  anymore

On Tue, Jul 8, 2025 at 4:12 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:

On 7/8/25 10:13, Jordan Brown via Discuss wrote:

I don't generally do that, mainly because I can generally do better code
than I can dl.

Cheers, Gene Heskett, CET.

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis

I think the issue here is whether one can accept source code for a
general programming language (Pascal, C, Python) from an arbitrary or
unknown source and trust that it will be safe to run on one's computer
without inspection.  I think the answer is "no".

On the other hand, one can accept source code SCAD files and trust that
they will run safely without inspection.

Attempting to rename things does not change the underlying issue.  In
this case, Jordan would be talking about downloading Code (written in
Python) and trusting it.  This remains problematic or dangerous when the
origin of the Python is uncertain.

Jon

On 7/8/2025 3:12 PM, Guenther Sohler via Discuss wrote:

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On Tue, Jul 08, 2025 at 03:26:34PM -0400, gene heskett via Discuss wrote:

In that case you can be tricked by saying "Please look at this model I
made. It doesn't work as I intended, can you help me improve it"?

Before you know it you've got it loaded up and the python stuff
installs a backdoor onto your system.

(I got about 10 mail messages today with "please see our order in the
accompanying document", "Re: Debit note", "request for quotation",
"prealert for XYE22070102", "Transaction proof Nif 2027944154" etc
etc. Apparently some people click on these to run the
windows-executables inside to give away access to their machine.
Those 10 are the ones that the spamfilter didn't filter out. )

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ  Delfgauw, The Netherlands.
** KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a** is going up.  -- Chris Hadfield about flying up the space shuttle.
**  'a' for accelleration.

On 7/8/2025 1:00 PM, Jordan Brown via Discuss wrote:

But we've discussed that to death, and the conclusion is that for some
people the risk is acceptable and for other people it isn't.

At this point all that's important to me is that people understand the
risk.  Caddiy asked about rumors of Python safety problems, so I replied.

I think we can let that subtopic die now.

Die subtopic DIE ;-)

On Tue, Jul 8, 2025 at 4:03 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:

On Tuesday, July 8, 2025 at 04:00:56 PM EDT, Jordan Brown via Discuss discuss@lists.openscad.org wrote:

My thought on this is that there could be a graphical environment such as Blockly:

https://developers.google.com/blockly

which was limited to only "safe" constructs, then, when a Python file which is not explicitly trusted (there will need to be a set of libraries which are vetted/approved in order to do truly interesting things) it is imported into this safe subset, with any code which does not match isolated into blocks/constructs which are not executed --- the user may then easily review the code and see what the isolated code in question does.

William

--
Sphinx of black quartz, judge my vow.
https://designinto3d.com/

William F. Adams wrote:

That is a question that interests me. An antivirus/malware scanner won’t help, the user has to be capable of reviewing the code and spotting stuff that doesn’t belong there??

Meanwhile, to change the subject yet AGANE, the results of my tests with a parametric simplified gear train and $fn=5 for quicker results:

The numbers of teeth on the fastest gears are down from 60 and 30 to 50 and 25 to make things easier.
The number of frames at which they appear to stand still is 50*720/360 and 25*1440/360 =100. Double that = 200. Above 200, the gears rotate forwards, below they go backwards. If the sign before the $t in the code for the backward gears is reversed, they go forwards! And surprise, surprise: you can’t tell the difference between 180Rx30 (R=reverse, 30 is the FPS in the video program) and 220x30 - no difference in quality! Doubling the number of frames to 360 improves smoothness a bit, but is not really worth doubling the size of the file. Of course, if a gear is reversed to go forwards, it has to be decoupled from parts to which it is attached - you don’t want them going backwards. That way you can save 40 frames.

mikeonenine@web.de wrote:

Continuation because of limit for attachments.

mikeonenine@web.de wrote:

Continuation because of limit for attachments.