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: