On Demand Rendering new in a7

I noticed the following release note:

• Graphics: On Demand Rendering. Ability to set the rendering speed independently from other engine updates.

I would like to know more about it. Any more information? How do you use it? Why was it created?

 

Plus one. More info please

 

An use-case I was always interested to implement, which requires this new feature:

On a mobile device...

• If there is little going-on animation wise and no user input, I wanted to reduce the frame-rate a lot, such as to 10 fps for example. This is to save battery power.
• If the user touches the display again, I wanted to immediately increase the frame-rate again, so the game feels responsive.

However, because rendering and input update rate can't be specified independently (in earlier Unity versions), as soon as I make the game run at 10 fps, input lags and you can't reliably detect immediate input changes.

If the rendering speed is separated from the other engine parts, I just could reduce the rendering speed to 10 fps but keep the rest of the game, such as input, at 30 fps and the game will stay responsive and allows me to immediately detect input changes to increase the rendering speed again.

 

Do you know how to start using it? What's the API?

 

Nope, I also wasn't able to find "On Demand Rendering" in the 2019.3 script reference yet.

 

something here perhaps,
https://github.com/Unity-Technologi...Export/Graphics/OnDemandRendering.bindings.cs

and old entry (not visible anymore)
https://feedback.unity3d.com/suggestions/on-demand-rendering-support

 

I'm actually more curious what that GetRenderFrameInterval() does (I mean technically the steps, it's obvious from the name what it returns) and if it would be possible to expose it.

 

Two questions come to mind:
* Is this approach similar to using the scriptable player loop to separate rendering functions from other subsystems?
* If not, does this work on WebGL where rendering is done on the same thread as everything else?

 

Same here

 

Great, this sounds exciting! Any chance that you will add the ability for us to cause the render, similar to Camera.Render(). Often I have nothing moving on the screen until user input is detected, would be nice if it didn't render at all.

 

Can that be accomplished by setting OnDemandRendering.renderFrameInterval to a large value when nothing is moving, and then to 1 when we want the next frame to render?

 

Is culling (and hence the culling callbacks) performed when rendering is not? If not, that would be useful as an optional feature to ensure script determinism regardless of the rendering interval.

 

Hm, the former just means being careful with anything non-visual being triggered by those callbacks, which is not that much of an issue. WaitForEndOfFrame being skipped is a bit more of a concern. Isn't there any way for this feature to force it, so that there is a valid callback after LateUpdate?

 

Cool. Generally, I use https://docs.unity3d.com/Manual/ExecutionOrder.html as the holy bible of event order, and that always had that callback outside the rendering block, so if it cannot be raised it might just be a case of updating the diagram.

 

I can confirm that this is a viable solution. What we did is, if nothing has changed since last frame (e.g. no calls to a custom RenderNextFrame() function), the current one will be rendered to an offscreen buffer that will be blit to the screen on every frame until something changes (skipping culling and rendering entirely).

You have to be careful about the few cases where you need to render the frame even if nothing has changed (typically the screen/window size changed). There are a few other potential issues, for example it seems that Unity uses the culling phase to do other work, such as updating the particle systems. If you skip culling completely, they will not be updated at all. It is unlikely to be a problem, but this caused a few oddities in our project.

 

I noticed that, seems the Animator acts odd when culling is shutoff. Hopefully Unity will address these culling-related issues in a future update.

 

So I just found this thread and just wanted to say that you could do this sort of thing before by simply rendering manually into a RenderTexture with Camera.Render() and having another camera display the texture.

 

Nope, input was still tied to framerate, so you'd still have to draw it 60 times a second if you wanted responsive input.

 

Only the camera displaying the rendertexture does so at 60fps, the camera that actually renders the scene (into the rendertexture) can be set to render to 1fps if you want to.

 

Which is the very problem that this feature solves. Rendering a full screen render texture at 60fps is not free. Not to mention that your frame time using your method would be slower overall since after the scene is rendered you then need to do additional work to blit that result to the frame buffer.

 

Is this usable in 2019.2? I'm about to build an application that would definitely need a feature like this.

 

Guys, what is your experience with this feature on mobiles so far? I had measured that a *static* 2d screen (with no calls inside update) drains +100% the battery that a static Flutter app drains in the same time period.

Does this feature brings energy consumption drastically down?

 

If I try this in WebGL it doesn't compile. Does work well on other platforms.

 

Has anyone else ran into problems with using this?

I'm working on a new project in 2019.4.21 for mobile and thought i'd give it a go.

Unfortunately it would appear this feature breaks WorldSpace Canvases as when I increase the renderFrameInterval they will disappear and only render for the single frame at the renderFrameInterval, which ultimately causes the canvas to flicker on/off.

Has anyone else encountered this?

I can only assuming there is something in the worldSpace canvas rendering that is dependent upon an internal render method being called every frame to render to the screen and its no longer getting called. Perhaps its related to the comment above that 'WaitForEndOfFrame' might not be called?

EDIT
Ah this is only happening when using the Unity Device Simulator and viewing the simulator as opposed to the Game view window. Though I've yet to test on an actual device, but hopefully this issue is solely related to the Device Simulator.

 

I too have experienced flickering bugs with OnDemandRendering and canvases, and unrelated to Device Simulator, which unfortunately makes the feature unusable until they fix it. I filed an issue about it 7 months ago which was confirmed but I haven't heard of anything being done to fix it.

https://issuetracker.unity3d.com/is...t-renderframeinterval-value-causes-flickering