JB
Jordan Brown
Mon, Jul 7, 2025 6:53 AM
On 7/6/2025 9:27 PM, Caddiy via Discuss wrote:
Animation goes in steps with certain intervals.
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.
What about generating a new image every 2nd, 3rd or nth step?
Absent manually matching up values in your program with your animation
settings, no.
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.
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.
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.
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?
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 :-)
Or introduce some kind of a dummy run inbetween live runs?
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.
I wish I had studied computer programming!
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/
On 7/6/2025 9:27 PM, Caddiy via Discuss wrote:
>
> Animation goes in steps with certain intervals.
>
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.
> What about generating a new image every 2nd, 3rd or nth step?
>
Absent manually matching up values in your program with your animation
settings, no.
> 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.
>
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.
> 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.
>
> 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?
>
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 :-)
> Or introduce some kind of a dummy run inbetween live runs?
>
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.
> I wish I had studied computer programming!
>
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 $t*360 to
map 0..1 into 0..360.
If you want to lift something 10 units up in Z during the animation, use
$t*10 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/
NH
nop head
Mon, Jul 7, 2025 9:18 AM
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:
On 7/6/2025 9:27 PM, Caddiy via Discuss wrote:
Animation goes in steps with certain intervals.
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.
What about generating a new image every 2nd, 3rd or nth step?
Absent manually matching up values in your program with your animation
settings, no.
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.
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.
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.
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?
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 :-)
Or introduce some kind of a dummy run inbetween live runs?
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.
I wish I had studied computer programming!
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/
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
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:
> On 7/6/2025 9:27 PM, Caddiy via Discuss wrote:
>
> Animation goes in steps with certain intervals.
>
>
> 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.
>
> What about generating a new image every 2nd, 3rd or nth step?
>
>
> Absent manually matching up values in your program with your animation
> settings, no.
>
> 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.
>
>
> 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.
>
>
> 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.
>
> 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?
>
>
> 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 :-)
>
> Or introduce some kind of a dummy run inbetween live runs?
>
>
> 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.
>
> I wish I had studied computer programming!
>
>
> 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 $t*360 to
> map 0..1 into 0..360.
> If you want to lift something 10 units up in Z during the animation, use
> $t*10 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/
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
SP
Sanjeev Prabhakar
Mon, Jul 7, 2025 4:47 PM
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:
Is it possible to make something disappear periodically? Maybe by making
one dimension (radius or linear_extrude etc.) of a shape alternate between
zero and a positive value at regular intervals?
The problem: the cams in the animation go 180° at half-speed then jump
180° so they effectively catch up to end up going at full speed. If they
could be made to disappear every second pass, and a second cam in each case
pops up and continues where the first disappears, until after 180° it is
replaced by the first cam, that would give the illusion of continuous
half-speed motion.
I know the standard solution would be to double all the speeds. But there
is a further shaft with gears that already run at double speed, so they
would have to run at quadruple speed. Instead of at least 180 frames, it
would need 360 frames to avoid the artefact of gears appearing to run
backwards or just looking fuzzy. That gives a rather large file and, with
max. 50 fps, a slow animation.
$vpr=[ 170, 315, 45 ];
$vpt=[ 0, 0, 0 ];
$vpd=700;
module cams()
{
hull()
{
cylinder(r=19, h=5);
for ( i = [0, 20])
rotate([0, 0, i])
translate([14, 0, 0])
cylinder(r=10, h=5);
}
translate([0, 0, 12])
rotate([0, 0, 90])
hull()
{
cylinder(r=19, h=5);
for ( i = [0, 20])
rotate([0, 0, i])
translate([14, 0, 0])
cylinder(r=10, h=5);
}}
// Timing gear
rotate([0, 0, $t*360])
color(steel1)
linear_extrude(6, center=true)
gear(30, 24, 2);
// Timing gears
for ( i = [0:1:3])
rotate([0, 0, 90*i])
translate([72, 0, 0])
rotate([0, 0, 3i+4 - $t180])
color(steel1)
{
linear_extrude(6, center=true)
difference()
{
gear(60, 48, 2);
for ( i = [1:1:8])
rotate([0, 0, 360/8*i])
translate([30, 0])
circle(8);
circle(12);
}
translate([0, 0, -28])
difference()
{
union()
{
cylinder(r=16, h=32);
translate([0, 0, 0])
cams();
}
translate([0, 0, -0.5])
cylinder(r=12, h=33);
}
}
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
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:
> Is it possible to make something disappear periodically? Maybe by making
> one dimension (radius or linear_extrude etc.) of a shape alternate between
> zero and a positive value at regular intervals?
>
> The problem: the cams in the animation go 180° at half-speed then jump
> 180° so they effectively catch up to end up going at full speed. If they
> could be made to disappear every second pass, and a second cam in each case
> pops up and continues where the first disappears, until after 180° it is
> replaced by the first cam, that would give the illusion of continuous
> half-speed motion.
>
> I know the standard solution would be to double all the speeds. But there
> is a further shaft with gears that already run at double speed, so they
> would have to run at quadruple speed. Instead of at least 180 frames, it
> would need 360 frames to avoid the artefact of gears appearing to run
> backwards or just looking fuzzy. That gives a rather large file and, with
> max. 50 fps, a slow animation.
>
> $vpr=[ 170, 315, 45 ];
>
> $vpt=[ 0, 0, 0 ];
>
> $vpd=700;
>
> module cams()
>
> {
>
> hull()
>
> {
>
> cylinder(r=19, h=5);
>
> for ( i = [0, 20])
>
> rotate([0, 0, i])
>
> translate([14, 0, 0])
>
> cylinder(r=10, h=5);
>
> }
>
> translate([0, 0, 12])
>
> rotate([0, 0, 90])
>
> hull()
>
> {
>
> cylinder(r=19, h=5);
>
> for ( i = [0, 20])
>
> rotate([0, 0, i])
>
> translate([14, 0, 0])
>
> cylinder(r=10, h=5);
>
> }}
>
> // Timing gear
>
> rotate([0, 0, $t*360])
>
> color(steel1)
>
> linear_extrude(6, center=true)
>
> gear(30, 24, 2);
>
> // Timing gears
>
> for ( i = [0:1:3])
>
> rotate([0, 0, 90*i])
>
> translate([72, 0, 0])
>
> rotate([0, 0, 3*i+4 - $t*180])
>
> color(steel1)
>
> {
>
> linear_extrude(6, center=true)
>
> difference()
>
> {
>
> gear(60, 48, 2);
>
> for ( i = [1:1:8])
>
> rotate([0, 0, 360/8*i])
>
> translate([30, 0])
>
> circle(8);
>
> circle(12);
>
> }
>
> translate([0, 0, -28])
>
> difference()
>
> {
>
> union()
>
> {
>
> cylinder(r=16, h=32);
>
> translate([0, 0, 0])
>
> cams();
>
> }
>
> translate([0, 0, -0.5])
>
> cylinder(r=12, h=33);
>
> }
>
> }
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
MK
Marko Kleine Berkenbusch
Mon, Jul 7, 2025 5:24 PM
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:
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:
Is it possible to make something disappear periodically? Maybe by making
one dimension (radius or linear_extrude etc.) of a shape alternate between
zero and a positive value at regular intervals?
The problem: the cams in the animation go 180° at half-speed then jump
180° so they effectively catch up to end up going at full speed. If they
could be made to disappear every second pass, and a second cam in each case
pops up and continues where the first disappears, until after 180° it is
replaced by the first cam, that would give the illusion of continuous
half-speed motion.
I know the standard solution would be to double all the speeds. But there
is a further shaft with gears that already run at double speed, so they
would have to run at quadruple speed. Instead of at least 180 frames, it
would need 360 frames to avoid the artefact of gears appearing to run
backwards or just looking fuzzy. That gives a rather large file and, with
max. 50 fps, a slow animation.
$vpr=[ 170, 315, 45 ];
$vpt=[ 0, 0, 0 ];
$vpd=700;
module cams()
{
hull()
{
cylinder(r=19, h=5);
for ( i = [0, 20])
rotate([0, 0, i])
translate([14, 0, 0])
cylinder(r=10, h=5);
}
translate([0, 0, 12])
rotate([0, 0, 90])
hull()
{
cylinder(r=19, h=5);
for ( i = [0, 20])
rotate([0, 0, i])
translate([14, 0, 0])
cylinder(r=10, h=5);
}}
// Timing gear
rotate([0, 0, $t*360])
color(steel1)
linear_extrude(6, center=true)
gear(30, 24, 2);
// Timing gears
for ( i = [0:1:3])
rotate([0, 0, 90*i])
translate([72, 0, 0])
rotate([0, 0, 3i+4 - $t180])
color(steel1)
{
linear_extrude(6, center=true)
difference()
{
gear(60, 48, 2);
for ( i = [1:1:8])
rotate([0, 0, 360/8*i])
translate([30, 0])
circle(8);
circle(12);
}
translate([0, 0, -28])
difference()
{
union()
{
cylinder(r=16, h=32);
translate([0, 0, 0])
cams();
}
translate([0, 0, -0.5])
cylinder(r=12, h=33);
}
}
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
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:
> 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:
>
>> Is it possible to make something disappear periodically? Maybe by making
>> one dimension (radius or linear_extrude etc.) of a shape alternate between
>> zero and a positive value at regular intervals?
>>
>> The problem: the cams in the animation go 180° at half-speed then jump
>> 180° so they effectively catch up to end up going at full speed. If they
>> could be made to disappear every second pass, and a second cam in each case
>> pops up and continues where the first disappears, until after 180° it is
>> replaced by the first cam, that would give the illusion of continuous
>> half-speed motion.
>>
>> I know the standard solution would be to double all the speeds. But there
>> is a further shaft with gears that already run at double speed, so they
>> would have to run at quadruple speed. Instead of at least 180 frames, it
>> would need 360 frames to avoid the artefact of gears appearing to run
>> backwards or just looking fuzzy. That gives a rather large file and, with
>> max. 50 fps, a slow animation.
>>
>> $vpr=[ 170, 315, 45 ];
>>
>> $vpt=[ 0, 0, 0 ];
>>
>> $vpd=700;
>>
>> module cams()
>>
>> {
>>
>> hull()
>>
>> {
>>
>> cylinder(r=19, h=5);
>>
>> for ( i = [0, 20])
>>
>> rotate([0, 0, i])
>>
>> translate([14, 0, 0])
>>
>> cylinder(r=10, h=5);
>>
>> }
>>
>> translate([0, 0, 12])
>>
>> rotate([0, 0, 90])
>>
>> hull()
>>
>> {
>>
>> cylinder(r=19, h=5);
>>
>> for ( i = [0, 20])
>>
>> rotate([0, 0, i])
>>
>> translate([14, 0, 0])
>>
>> cylinder(r=10, h=5);
>>
>> }}
>>
>> // Timing gear
>>
>> rotate([0, 0, $t*360])
>>
>> color(steel1)
>>
>> linear_extrude(6, center=true)
>>
>> gear(30, 24, 2);
>>
>> // Timing gears
>>
>> for ( i = [0:1:3])
>>
>> rotate([0, 0, 90*i])
>>
>> translate([72, 0, 0])
>>
>> rotate([0, 0, 3*i+4 - $t*180])
>>
>> color(steel1)
>>
>> {
>>
>> linear_extrude(6, center=true)
>>
>> difference()
>>
>> {
>>
>> gear(60, 48, 2);
>>
>> for ( i = [1:1:8])
>>
>> rotate([0, 0, 360/8*i])
>>
>> translate([30, 0])
>>
>> circle(8);
>>
>> circle(12);
>>
>> }
>>
>> translate([0, 0, -28])
>>
>> difference()
>>
>> {
>>
>> union()
>>
>> {
>>
>> cylinder(r=16, h=32);
>>
>> translate([0, 0, 0])
>>
>> cams();
>>
>> }
>>
>> translate([0, 0, -0.5])
>>
>> cylinder(r=12, h=33);
>>
>> }
>>
>> }
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
R
Rudolf
Mon, Jul 7, 2025 6:09 PM
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:
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:
A moving “now you see it, now you don’t” difference() might be
worth a try (but not right now).
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
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:
> 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:
>
> A moving “now you see it, now you don’t” difference() might be
> worth a try (but not right now).
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
JB
Jordan Brown
Mon, Jul 7, 2025 9:23 PM
On 7/7/2025 10:24 AM, Marko Kleine Berkenbusch via Discuss wrote:
Could you use the alpha channel in 'color(r,g,b,alpha)' perhaps?
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.
On 7/7/2025 10:24 AM, Marko Kleine Berkenbusch via Discuss wrote:
> Could you use the alpha channel in 'color(r,g,b,alpha)' perhaps?
>
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.
M
mikeonenine@web.de
Mon, Jul 7, 2025 10:01 PM
What about generating a new image every 2nd, 3rd or nth step?
Absent manually matching up values in your program with your animation
settings, no.
Could you expand on that? Is program = my script/code?
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?
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.
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.
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 :-)
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!
Jordan Brown wrote:
> > What about generating a new image every 2nd, 3rd or nth step?
>
> Absent manually matching up values in your program with your animation
> settings, no.
Could you expand on that? Is program = my script/code?
> > 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?
>
> 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.
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.
> 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 :-)
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!
JB
Jordan Brown
Mon, Jul 7, 2025 10:40 PM
On 7/7/2025 3:01 PM, Caddiy via Discuss wrote:
What about generating a new image every 2nd, 3rd or nth step?
Absent manually matching up values in your program with your
animation settings, no.
Could you expand on that? Is program = my script/code?
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?
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.
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.
Er, maybe, kind of, but mostly no. After n-1 comes 0.
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 $t360. Running
them at $t180 won’t help!
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:01 PM, Caddiy via Discuss wrote:
>
> What about generating a new image every 2nd, 3rd or nth step?
>
> Absent manually matching up values in your program with your
> animation settings, no.
>
> Could you expand on that? Is program = my script/code?
>
Yes.
> 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?
>
> 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.
>
> 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.
>
Er, maybe, kind of, but mostly no. After n-1 comes 0.
> 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!
>
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.
JB
Jordan Brown
Mon, Jul 7, 2025 10:58 PM
On 7/7/2025 3:40 PM, Jordan Brown via Discuss wrote:
On 7/7/2025 3:01 PM, Caddiy via Discuss wrote:
What about generating a new image every 2nd, 3rd or nth step?
Absent manually matching up values in your program with your
animation settings, no.
Could you expand on that? Is program = my script/code?
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.
On 7/7/2025 3:40 PM, Jordan Brown via Discuss wrote:
> On 7/7/2025 3:01 PM, Caddiy via Discuss wrote:
>>
>> What about generating a new image every 2nd, 3rd or nth step?
>>
>> Absent manually matching up values in your program with your
>> animation settings, no.
>>
>> Could you expand on that? Is program = my script/code?
>>
>
> Yes.
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.
SP
Sanjeev Prabhakar
Mon, Jul 7, 2025 11:18 PM
Motion with disappearing effect.
In python, i could do this by comparing the time value with some set of
numbers and excute commands like translate the item in case the numbers are
with in a certain range.
Here is the video
Motion with disappearing effect.
In python, i could do this by comparing the time value with some set of
numbers and excute commands like translate the item in case the numbers are
with in a certain range.
Here is the video
