How to re-render the scene only when something changes in Unity?

Question

I am building a social/chat/dating app which I would like to build in Unity as I want some 3D graphics, geo-location functions, and possibly mini-games you can play together with others.

From a functional perspective, Unity seems perfect for this. It allows all the features I want in one easily adaptable and expandable package that supports Android and iOS.

However, I read one post on unity.com from a few years ago where someone said regarding using Unity for a similar purpose: "Unity is first and foremost a GAME engine. Therefore it does many stuff that doesn't make sense in the regular application, such as redrawing everything every frame. This would just make a battery eater."

I am wondering if this is still the case or if there is any practical solution for this. Does Unity continuously refresh the screen or constantly render 3D objects on screen with each refresh?

For example, let's say hypothetically you had a screen where you were just text messaging through the Unity app with someone (mimicking basic SMS but through the Unity app) and at the top of the screen there was a 3D rendered header graphic like a logo or 3D graphic menu.

In principle, you would only need to refresh/re-render the screen when a new message is exchanged, the screen is scrolled, or someone clicks a menu option to trigger a menu function or animation. If it continuously re-renders the entire screen and top 3D graphic every frame endlessly at say 30 fps, this would be incredibly wasteful.

Would there be any way to limit re-renders to only happen on certain events and thus make this practical?

Answer 1

The comment that you found is accurate. Unity was developed as a game engine, designed to run games that are animating on-screen elements continuously. In that context, adding logic to detect when something has changed and re-render only on demand would actually increase cost, because you spend extra CPU time doing this validation, when 90%+ of the time the answer is "yes, re-rendering is needed".

Unity is quite flexible and does give you control to render when you want, but since minimizing re-rendering is not a core engine feature, it would be your responsibility to track when you need to render and switch rendering on & off.

Here's a quick proof of concept script that demonstrates this:

public class RenderControl : MonoBehaviour
{
    new public Camera camera;

    float _renderFor = 0.1f;
    int _continuousRenderRequests = 0;

    public void RenderFor(float duration = float.Epsilon) {
        _renderFor = Mathf.Max(_renderFor, duration);
    }

    public void StartRenderingContinuously() {
        _continuousRenderRequests++;
    }

    public void StopRenderingContinuously() {
        _continuousRenderRequests--;
    }
    
    void LateUpdate()
    {
        camera.enabled = (_renderFor > 0) || (_continuousRenderRequests > 0);
        _renderFor = Mathf.Max(0, _renderFor - Time.deltaTime);
    }
}

This disables the camera from rendering after it's had a chance to display the initial state of the scene. After this, rendering can be enabled for a set duration or until stopped by calling one of the public methods on this script.

While the camera is disabled, no new drawing commands will be issued, and whatever you last drew to the screen stays there. But game logic (like the update loop that handles user input and checks whether it's time to re-enable the camera) still ticks every frame.

Note that in the Unity Editor view, you'll see a warning overlaid on the game window "Display 1: No cameras are rendering" to alert you to this, because it's usually a sign of an error if it happens in a game. But this warning is not present in the built executable.

If you use the UI system, you'll want to set the canvas mode to "Screen Space - Camera" so that the rendering of the UI is tied to the enabled state of the camera. With "Screen Space - Overlay", the UI will still render continuously over the frozen 3D scene.

You could take this further by computing the screen rectangle bounding the changed area, then change the camera's transform and viewport parameters to limit rendering to just that rectangle.

However, you'll likely find this more laborious than it's worth. You'll save the work of rendering your chat window, which is likely quite lightweight, but still be paying the costs of updating all Unity's other game systems - as well as the download cost of a full-featured game engine. So the efficiency will not match frameworks that are purpose-built for making this kind of mobile app.

Your use case is probably better served by using a dedicated framework designed for building mobile-conscious apps, and then running your minigames either as WebGL apps in a web view, or chaining control to a separate executable for those parts.