I’m one member of a team working on a project that uses Unity to generate videos. We’ve been using AVPro Movie Capture by RenderHeads, however as the tool is expected to make a public release soon, its intended use case will most likely require deployment on a Linux machine.
As AndrewRH’s definition of “soon” seems to match Valve’s in relation to porting AVPro Movie Capture to platforms outside of Windows (I know I saw a post from 2012 from them promising it’s coming “soon” somewhere) I’m looking for alternatives to that specific solution.
The main point I’m looking toward is trying to figure out how best to attempt to render a video as fast as possible in relation to real time, while producing a video with a fixed framerate. While the tool can be used in real time with user input, we’re also expecting deployments that utilize semi-massive render farms to generate the videos via command line arguments. When used in this manner, the app launches, produces the visualization, and quits; no user input is used after launch.
I’ve looked at Time.captureFramerate however it says nothing about what happens if the frame rendering takes more or less time than 1/captureFramerate. Is there another alternative that is platform agnostic and can provide the functionality I’m looking for?
If rendering takes too long, Unity pretends it was quicker, meaning the video will appear at a fixed frame rate, even though the game is not running at a fixed frame rate.
If rendering to too quick, it will wait until the desired time has passed.
Ah, I see. If a frame takes too long, I’m guaranteed an Update with a constant Time.deltaTime (give or take inaccuracies). However, I’m concerned more about the frame popping out too quick - even though I want a video at, say, 30 FPS, I would like Unity to try to pop those frames out as quickly as possible, without artificial delays. I don’t suppose setting Time.captureFramerate to something high like 1000 would be valid to produce such a video?
It already does produce the frames as quickly as possible and doesn’t do any delays at all, artificial or otherwise. Using 1000 for Time.captureFramerate would generate a video that runs at 1000 fps. Good luck trying to play that back properly.
Ah, so using captureFramerate simply removes limits on the “real” framerate and does nothing but pass a constant Time.deltaTime, then (thereby uncoupling internal realtime from wall-clock time)?
EDIT: Silly question. I just looked through what C# code that AVPro has, and they also reference Time.captureFramerate. That would’ve answered my question sooner…
Yep. Of course, the drawback is that actually trying to play a game with captureFramerate on may be challenging, so it’s more useful for purely scripted stuff.
Considering the intended use case of “people set up render farms with this application and use a web portal to request videos” the input issue part doesn’t seem like that big a deal to me…
You’ll want to double check the lisencing. There are some rules in there about exposing functionality and using Unity in cloud services that you should be aware of.
