Timeline issue

Hi guys,

I am trying to emulate a clock timekeeping using the geometry nodes, following a tutorial online; the timekeeping system itself works great. However, when I play the animation, the timeline plays the frame range I created (1440 frames, for 60 secs at 24 fps) and the minute pin resets itself instead of continuing counting forward. I can move beyond the frame range by scrubbing the play head without a problem and everything works as expected.

Is it possible to playback beyond the frame range, so my clock driver will be able to tick time indefinitely rather than being limited by the frame range?

Please help, I’m really stuck here.

I am using the brand new Blender 3.1.0. Let me know if you need the BLEND file.

Kind Regards,


You need to set up your driver so that it makes X number of full rotations between the start frame and the end frame, right? Let’s break that down.
At 24 FPS, one minute is 1440 frames. You want 1/60 (1 minute/1 hour) rotation every 1440 frames. If you want two minutes, you need 2880 frames- 2/60 rotation. If you want a full, non-broken rotation, you need 60/60 rotation- 1440 * 60, or 86400 frames.

@ josephhansen

Thank you for your answer. There must be a way of playing the driver over the frame-range; the guy in the video does it and doesn’t even comment on it. Bear in mind I am not talking about rendering the animation, but simply playing it back.

I include the BLEND for reference here. Please help.


Let me clarify, I’m not understanding you here. You have an animation that goes from frame 0-1440, and you want to see things happen beyond the end frame of 1440 during playback? This isn’t possible, playback ends at the end frame. Nothing is rendered outside the frame range, not in the viewport or rendered to a file. That’s the whole point of a frame range.

If you want to see something outside the end frame during playback, you have to increase the end frame.


Thank you for your fast answer; sorry if my posting seems confusing.

If I scrub the timeline beyond the frame range there is no issue at all; all I need is for the playback to continue playing the same as scrubbing.

I totally agree with you in case of conventional key frame driven animations, but it seems to me this is a driver operation: the logic of my node network is not based on key frames but on a #frame driver which needs to be fed a higher frame number each time to continue ticking forward; if I cannot do that, the usage of #frame seems quite limited to me. Am I misunderstanding #frame here?

Thanks in advance for all your help.


I totally get where you’re coming from, and I understand why logically drivers could be able to extend playback. Realistically, though, playback only goes to the end frame, even with #frame driver. There has to be an upper limit on frame count.

That’s not a very helpful answer, so let me describe why drivers can’t extend playback. This is going to be long, I’m sorry, I just know the feeling of having a logical idea and being frustrated when no one will explain why it wouldn’t work.

Think about it like this: in the situation you describe, with a #frame driver, playback doesn’t stop at the end frame. It stops whenever you stop playback, right? Seems simple enough.

Here’s the problem: if you’re rendering this as an animation, how many frames does it render? “Whatever the end frame value is”, you might say. Ok, so we now we have a different frame end for renders and viewport preview. This is already a problem, because viewport preview needs to show what the render will be, but let’s put that aside and say you CAN have two different end frames.

Now we have a new problem: every frame in the viewport requires memory. In this case, not very much, since you just have one driver, but imagine you have a full armature with bones, constraints, etc, all being driven by a #frame driver. If you were to press play on the viewport render and let it keep going without an end frame, it will keep going infinitely, it will keep using memory, and you’ll run out of both RAM and disk space eventually.

We also have another problem- any fluid caches, physics caches, soft bodies, anything like that, is also using memory every frame. Without an end frame, you can’t have physics, fluids, volumes, or even particles.

Ok, so why not just have drivers extend playback unless there’s a physics simulation, or volume, or particles? Sure, we’ll run out of memory eventually, but to be fair, that will take a long time.

Two problems with that: can you imagine the confusion of trying to figure out if you could have extended playback or not with those restrictions? Having extended playback switch on and off based on a long list of memory-hogging factors would be HORRIBLE user experience, you’d never know if it was on or not.

More importantly, at this point, we’ve removed the functionality of the “viewport preview”- it’s not previewing the render accurately, and all we’re gaining is the ability to extend playback. Even that is under very limited circumstances and it comes with the GIVEN that Blender and your computer will crash eventually. It might take ten minutes or it might take a week, but eventually, you will run out of memory if you’re processing infinite frames (or approaching infinite frames.) Baking in functionality that’s guaranteed to break is something no software developer would ever do.

There’s also an upper limit to what the end frame number can actually be- it would be hard to reach, since I’m assuming it’s 9,223,372,036,854,775,807, which would take 12186300361.6 years to reach at 24 FPS, but still, once Blender reached that frame, you’d have another 100% guaranteed crash.

To summarize- yes, it would be POSSIBLE for frame-based drivers to extend playback. It would create a bunch of confusing functionality that could only turn on under very specific circumstances, and it would eventually crash your computer, so that’s why it’s not PRACTICABLE.


Thank you so much for your help. What you say makes a lot of sense, and those were my original thoughts. But the tutorial seems to be doing it no problem, plus the fact that I can scrub beyond the frame range really confused me; and, indeed, even with scrubbing after scrubbing over three hours worth of frames the output starts getting wonky.

Once again, thank you for your help.


“over three hours worth of frames”… ???

1 Like