Still stuck! HELP!

Hi all,

As I’ve previously written, I’ve created a system which renders out Unity projects as equirectangular stereo images to create VR movies. Whilst the principles of this are working 100% (I can generate the image I require), making it work with a Unity project is proving difficult.

The renderer takes roughly 40 minutes to render a frame. This isn’t a problem, as it’s an off-line process. The problem is that Unity ‘tries to catch up’ with where it should be, and as such ‘jumps frames’. In other words, if I tell the system to render frames 1-5, it renders them, but frames 1-5 are not the same as if you rendered frames 1-5 in real-time; they look like they’re essentially frames 1, 25, 50, 75, 100, for example.

I figured this wasn’t too big an issue, as I could spread the rendering across multiple machines. The issue here is that unless each machine is 100% the same specification as the others, frame 33 (for example) is not the same on machine 1 as it is on machines 2, 3, 4 and 5. This makes using multiple machines practically impossible.

I looked at Time.captureFramerate**,** but it seems that the slowest setting this supports is 1 frame per second.

There has to be a way I can simply lock Unity to ‘whatever frame-rate it runs at’ without the ‘frame correction’ in place? I’ve tried just about everything I can think of (setting timescale to zero etc), but as the stuff I’m trying to render isn’t physics dependent, and Update keeps running, this hasn’t helped at all…

My last thread on this went nowhere, hence me asking again. Does anyone with a deeper understanding of Unity (such as @Aras or @antenna-tree ) have any ideas that could help me with this? This isn’t a hobby project - it’s actually for professional work, and the output is amazing, so it would be very good if there was some way I could fix this final issue…

Thanks in advance for any help! I generally don’t need much in the way of guidance with Unity as I’ve been using it for so long, but I’m really stuck with this one!

Cheers,

SB

What processes in your app are actually changing from frame to frame? Is it camera animation? Animated characters? Something else?

If you set Time.captureFramerate to, say, 30, then Time.deltaTime should always be 1/30 and Time.time should always advance by 1/30th with each passing frame. If the processes that change your input data are using those values correctly, then it shouldn’t actually matter whether the time taken to render a frame is 40mins or 40ms; the processes just get told “1/30th of a second has elapsed” and they’re supposed to just trust that. In other words: you should be setting Time.captureFramerate according to the amount of time you want to have elapsed between successive renders.

Have you tried logging out Time.deltaTime / Time.time, along with Time.frameCount, to check that the values are coming through predictably?

Hey Superpig,

Nothing is timed - the applications in question just function as the update functions are called. There is animation in there, but it’s not time dependent as far as I’m aware.

I time the frames, and they’re taking 40+ MINUTES to spit out (lots of processing with rendertextures etc), but that’s the pinch - setting Time.captureFramerate to 1/30 of a second won’t help at all - I need to make the application run at “1 frame every 40 minutes” effectively…

The times are predictable - but this is a push to make the frame-rate as slow as possible as opposed to as fast as possible, if that makes any sense?

The animation system is always time-dependent - otherwise it doesn’t know which time index in the animation to sample from. How is your animation set up? My guess is there’s something you have set up which is not actually respecting elapsed time - e.g. if you have a flickering light that works by flipping emission on/off every Update call, that’s not going to work properly.

No, that’s my point. The actual time taken to render a frame is no longer supposed to matter when you’re using Time.captureFramerate - when you set it you’re effectively instructing Unity to lie to its systems about how much time has elapsed between each update. Setting “1 frame every 40 minutes” would be like making a time-lapse film, with each successive rendered frame of output showing the simulation as if 40 minutes have elapsed within it.

What you should be focusing on is the rate at which these images will be played back - i.e. if they’re playing back at 90FPS, you want captureFramerate to be 90, such that for each successive rendered frame - despite them taking 40mins to render - the simulation is only advanced by 1/90th of a second. Does that make sense?

1 Like

Thanks Superpig - it does make sense from the captureFramerate perspective.

On the animation front - I suspect that is unfortunately where we are (I didn’t write the original code). In other words, we may have a light which is flipped on and off every frame using the update function (LightOn = !LightOn or similar). This won’t work at all?

Actually, thinking about it, the specific example of flipping a light on/off should still work. The stuff that won’t work will be any situation where you’re using ‘real time’ (i.e. Time.realtimeSinceStartup), and perhaps Animator components that are set to use ‘Unscaled Time’ (I’m not sure if they respect captureFramerate or not).

You’re going to need to dig into the way your animations are set up, I think, and see if you can work out what assumptions they’re making about the passage of time.

The other thing I would check is that your rendering is actually taking place all within the course of a single frame - that you are not, for example, using a coroutine which spreads the rendering over multiple frames (using ‘yield’ etc).

2 Likes

Nice one Superpig - I’ll check it all out! :slight_smile:

@superpig - that appears to have worked! I’ll give it a proper test this weekend, but so far, so good! :slight_smile:

2 Likes

Awesome. Fully deterministic simulations for the win :slight_smile:

1 Like