How to get the rendered texture from a camera, save for later display on another camera?

There have been a few threads about this, but no one seems to have come up with a concrete answer.

I basically want to be able to "playback" the entire game. It would seem that the most efficient way to do this would be to just save all of the pre-rendered frames that the game is already generating, and then play those back in reverse order. I only need about a 5 - 10 second window of possible "rewind", so I won't be recording hours of video to the memory.

It seems like a possible way to do this might be to use:

// We should only read the screen bufferafter rendering is complete
yield WaitForEndOfFrame();

// Create a texture the size of the screen, RGB24 format
var width = Screen.width;
var height = Screen.height;
var tex = new Texture2D (width, height, TextureFormat.RGB24, false);
// Read screen contents into the texture
tex.ReadPixels (Rect(0, 0, width, height), 0, 0);
tex.Apply ();

Then to save the `tex` var in an array. Then when I want to play back the scene, perhaps use:

GUI.DrawTexture (position : Rect, image : Texture, scaleMode : ScaleMode = ScaleMode.StretchToFill, alphaBlend : bool = true, imageAspect : float = 0)

Where the `position` rect would fill up the entire screen, and the `image` would be the previously-saved texture.

However, when texting the first part of this (the texture-saving), the game slows way, way down. I haven't even tested the GUI.DrawTexture function yet, but I'm sure it's not going to fair much better. It seems like saving all of those textures eats up a ton of memory (going from 400 MB to well over 1.4 GB while running in the Unity Editor on my Mac), as well.

Any thoughts on how to optimize this?

I also know that Unity Pro has the RenderToTexture functions. Perhaps those are better optimized (i.e. I could save the Texture created by the RenderToTexture calls and then use GUI.DrawTexture?) Has anyone tried anything similar to this with those functions?

1 Answer

1

There's no way you can save actual frames in real-time in a performant way. You're much better off recording objects' positions instead, which will be far faster and use far less RAM.

Thanks, that's what I was thinking, but it was helpful to have someone else confirm my suspicions.