Question 24p or 30p lock Game View at this rate, how?

What are all the steps to successfully lock the Game View (in Play Mode) to a frame rate of 30 or 24 fps?

Using Builtin and Cinemachine.

And is there a way to cap the Game View to this same frame rate (24 or 30) during playback of Animation, Animator or Timeline in Edit Mode?

Ideally, if possible, lock Scene View to these rates, too, but can understand if that's not possible.

Using Unity 2019.LTS

Apologies for asking here... figured that these frame rates would have been of interest to those making product demos, commercials, television content etc with Unity and Cinemachine, so thought this neck fo the woods more likely than any other to know the surefire way to achieve this kind of Game View Preview at 30 or 24 fps.

ps, tried to attach tags "fps", "game view" and "24p" to this post, can't because they're new/unavailable.

 

Application.targetFramerate = 24 in the Start or Awake of a script

 

I've done all sorts of experiments with this feature. It's epically inaccurate.

At 30, it's fluctuating between 65 and about 35, never 30.

At 24, it's fluctuating between about 30 and 60.

At 60, it's fluctuating between about 110 and 130

Oddly, the lower you go, the more accurate it becomes. At 6, it's fluctuating between 7 and 9

 

A while loop to keep things busy until it's time to progress? That's not going to be that much more stable, will flutter the other side of the frame rate... rather than going higher, will go stutter and flutter slower than the target frame rate.

Which will always be worse, as frames will be missed.

I'd settle for being able to record exactly the frame rate I want, through "offline" like rendering. Am trying to make promotional materials from Unity. Thought this would be a solved problem, given how popular the engine is, and how heavily it's promoted.

 

Perhaps it's good for quick vids to share with coworkers, but it's not good for making anything for an audience.

 

Apologies, I mentioned it in another post, and presumed this was more widely known:

The little stutters from performance issues and/or GC and/or OS interruptions and/or Unity frame timing issues and/or GFX.waitForPresent etc.

Any/all of these can/will cause Recorder to drop frames, in much the same way that using a screen recorder will record dropped frames, because they were dropped/skipped by Unity as a result of a time step being missed due to the overload. There's also a frame sync or rhythm problem, wherein every now and then a frame is dropped, sometimes, ANYWAY, regardless of these issues being somewhat absent. There's something funky about frame timing, sometimes, all the time.

I'm sure it's possible, on a fast enough workstation that's isolated from OS interruptions and easily able to keep Unity running flawlessly to use the Recorder, or screen capture, but I'm on a humble MacBook Pro, so need a means to capture, assuredly, every frame, regardless of load issues during any given frame.

_EDIT add:
For game makers, not film makers, the path is very different. Pick a Unity version early on, and stick with it. Upgrading is folly, for reasons that are very well documented. At a certain point, it's time to make some promotional materials... how to do that well should be a solved problem, that's well presented and promoted for those older versions of Unity - that these poor souls are stuck on for all sorts of reasons of customisations, hard fought for optimisations etc etc. And they're little people, without the teams to investigate cutting edge options, and they're already exhausted. I speak from experience. It's yet another round of uncertain investigation to find out how to get good video output.

At this point, printing out sequences with Time.captureDeltaTime is working to do "offline" rendering. I've not yet seen it skip a beat, only done a few short preliminary tests with it, not fully taxed it yet. For those that need audio... too. I wince in pain wondering how they're going to do it without finding the budget to buy a machine that can run everything assuredly.

I'm on 2019.LTS, and using Builtin and PP2, which I mention because it's faster and leaner and lighter than everything that follows.

 

I'm going to sound like an arsehole here. Or may be am one to think and say this:

I was truly shocked to see Unity suggesting time pestering via a while loop to get a stable frame rate. It blew my mind that time stepping was done so badly by the engine that scripting this kind of thing was required of users to get good time stepping. It's certainly given my mind some rest about the weird funky little odd steps/flutters I see that aren't (or don't seem to be) the result of OS/GC interrupts, which I'd previously had to circumvent when doing custom audio by making a buffer able to be pulled from ahead of time in case these flutters occurred.

 

Agreed. And thank you for reinforcing my new belief that captureDeltaTime is what I'm looking for in terms of a stable frame printer.

On the 24p stuff, my main reason for investigating it was to get better motion blurs, that are more smeary, as I had a suspicion that Unity, if left to its own devices, is running very fast frame (shutter) times, and then not updating whilst it awaits the chance to do another frame, resulting in far less than 360 degree (shutter at desired/supposed frame rate with a slow shutter speed) motion blur.

My line of thought was that if I could lock it to a sure 24p, then perhaps the PP motion blur would consider the full frame to frame of this slower frame time for true 360 degree motion blur across a more specified/exact/long shutter time. I haven't got this to work, yet. Just locking the frame rate, reliably, is very tricky, seemingly. It (motion blur) is better, at a slower frame rate, but not nearly as good as I'd hoped.

I'm going to have to think, it seems, about how to make Unity consider its shutter time. At the moment it looks/feels like Motion Blur is calculated at a very high shutter rate compared to the frame rate. eg if shooting film (real camera) at 24p rate with 1/200th of a second shutter, that's what it feels like, rather than the ideal of 24p at something like a 1/30th of a second shutter rate. In this digital realm, I'd hoped that 24p would be doing shuttering at 1/24th of a second and motion blur just pure creamy dreamy stuff... but it's not near that.

The lack of object motion blur (objects moving relative to a static camera) is also a huge miss, I think. It looks like some of the notes in the post processing stack code from a long time ago indicate it was being considered, but never happened.

 

Can you give any specifics of how they're achieving this success?

Machines, SRP vs Builtin, Versions of Unity, Versions of Recorder, Formats being used. Etc.

it's gone beyond being unreliable in terms of output, for me, to straight up hanging and crashing Unity, for me, with the latest correct versions for a 2019.LTS install... which ain't gonna see any update or fixes. So I'm willing, unusually, to consider "upgrading".

AND... could unity add a way to directly upload video? I don't want to have to publicly upload somewhere to demonstrate here.

 

I've tried with a high powered PC workstation, with dual CPUs, and pushing affinity for the processes under control to separate cores/CPUs. And with very fast single function SSD storage for receipt of the output.

If your want is high quality without frame loss, without codec oddities and production quality, you simply must, MUST render each frame with captureDeltaTime, I think.

In doing this, the cap on Unity post processing time considerations goes out the window. Which it must, otherwise just anti-aliasing will kill stable frame rate capture at fuller resolutions.

It seems the best usage of video from Recorder is as a proxy and "sync" track, kind of as an audio capture device with visual references via the lowest quality video rendering you can tolerate (small dimensions, all visual effects, shaders, particles, post processing and lighting off) so that it's got the absolute least likelihood of stuttering.

This provides a near perfect frame stream with audio that's got basic geometry references for alignment, and an audio track that the fully rendered still frames can be synced with, and then enables adding in multi-pass frames, along with post-post processing muxing audio as desired.

Due to the way Apple aggressively uses background processes to constantly check and update all manner of things, it's quite difficult to get this frame accurate rendering securely. A "Flight Mode" optimisation of the OS is required, and a Mac that won't throttle, at all. Won't even seek to sense if it should throttle. And the coreaudiod processes killed off.

Even on a PC Workstation, kill the internet, all networking and unplug anything that could interrupt, and close all other apps, and make sure there's no chance of anything even sniffing for a port or CPU cycle.

It also seems that the newer the Unity version the slower it is. And this isn't small decreases in performance. I now see that those folks complaining about performance degrading are not even remotely exaggerating. Everyone else complaining has seemingly not helped, so I'll stop...