Search Unity

프로젝트를 가장 높은 프레임 속도로 렌더링하는 것이 늘 바람직하지만은 않은 데, 모바일 플랫폼에서는 특히 더 그렇습니다. Unity 개발자는 그동안 Application.targetFrameRate 또는 Vsync Count를 사용해 Unity 렌더링 속도를 억제했습니다. 이러한 접근 방식은 렌더링뿐만 아니라 Unity가 실행하는 모든 부분의 주기에도 영향을 줍니다. 새로운 온디맨드 렌더링 API를 이용하면 플레이어 루프 주기에서 렌더링 주기를 분리할 수 있습니다.

온디맨드 렌더링이란 무엇인가요?

온디맨드 렌더링을 이용하면 플레이어 루프의 나머지 부분을 높은 빈도로 실행하면서도 프레임 렌더링을 건너뛸 수 있습니다. 이는 모바일 환경에서 특히 유용한데, 렌더링을 건너뛰면 애플리케이션이 터치 이벤트에 대한 반응성을 유지하면서도 성능에 미치는 영향은 줄고 전력은 크게 절약할 수 있기 때문입니다.

 

온디맨드 렌더링을 사용해야 하는 이유가 무엇인가요?

다음의 경우에 프레임 속도를 낮추는 것을 고려할 수 있습니다.

  1. 메뉴(예: 애플리케이션 진입점 또는 일시 중지 메뉴): 메뉴는 비교적 단순한 씬인 경우가 많으므로 최대 속도로 렌더링할 필요가 없습니다. 낮은 프레임 속도로 메뉴를 렌더링하더라도, 렌더링되지 않은 프레임 동안 입력을 수신하므로 소모되는 전력 을 절감하며 CPU 주파수가 스로틀링될 수 있는 수준까지 기기 온도가 상승하는 것을 방지하는 동시에 원활한 UI 인터랙션을 유지합니다.
  2. 턴제 게임(예: 체스): 턴제 게임에는 플레이어가 다음 수를 생각하거나 상대방이 움직일 때까지 기다리는 동안에는 활동량이 낮아집니다. 이 시간 동안 프레임 속도를 낮춰 불필요한 전력 사용을 방지하고 배터리 수명을 연장할 수 있습니다.
  3. 정적 콘텐츠: 자동차 사용자 인터페이스(UI)와 같이 콘텐츠가 장시간 동안 정적인 애플리케이션에서 프레임 속도를 낮출 수 있습니다.
  4. 성능 관리: 어댑티브 퍼포먼스 패키지를 사용하고 있을 때와 같이, 전력 사용량과 기기 발열을 관리하여 배터리 수명을 극대화하고 CPU 스로틀링을 방지하려는 경우, 렌더링 속도를 조정할 수 있습니다.
  5. 머신러닝 또는 AI 애플리케이션: CPU의 렌더링 작업 시간을 줄이면 애플리케이션에서 집중해야 하는 대용량 프로세싱에 성능을 조금 더 활용할 수 있습니다.

 

어디에서 지원되나요?

어디서나 지원됩니다. 온디맨드 렌더링은 Unity 2019.3에서 지원되는 모든 플랫폼(시스템 요구 사항 참조)과 빌트인 렌더 파이프라인, 유니버설 렌더 파이프라인, 고해상도 렌더 파이프라인 등의 렌더링 API에서 사용할 수 있습니다.

 

온디맨드 렌더링은 어떻게 사용하나요?

온디맨드 렌더링 API는 UnityEngine.Rendering 네임스페이스의 단 세 가지 프로퍼티로 구성되어 있습니다.

OnDemandRendering.renderFrameInterval
가장 중요한 프로퍼티입니다. 이 프로퍼티를 활용하면 Application.targetFrameRate 또는 QualitySettings.vSyncCount의 분배 계수(dividing factor)인 렌더 프레임 간격을 가져오거나 설정하여 새 프레임 속도를 정의할 수 있습니다. 예를 들어, Application.targetFrameRate를 60으로 설정하고 OnDemandRendering.renderFrameInterval을 2로 설정하면, 두 프레임당 한 번씩 렌더링하기 때문에 프레임 속도가 30fps가 됩니다.

OnDemandRendering.effectiveFrameRate
이 프로퍼티를 사용하면 애플리케이션에서 렌더링하게 될 프레임 속도를 추정할 수 있습니다. 추정값은 OnDemandRendering.renderFrameInterval, Application.targetFrameRate, QualitySettings.vSyncCount의 값과 디스플레이 새로고침 속도를 사용하여 결정됩니다. 그러나 이는 추정값에 불과하므로 정확한 값을 보장하지는 않습니다. 스크립트, 물리, 네트워킹 등의 다른 작업에 CPU를 사용 중인 경우 애플리케이션의 렌더링 속도가 느려질 수 있습니다.

OnDemandRendering.willThisFrameRender
이 프로퍼티를 통해 현재 프레임이 화면에 렌더링되는지 여부를 알 수 있습니다. 렌더링되지 않은 프레임을 사용하여 복잡한 수학 연산, 에셋 로딩 또는 프리팹 생성 등 CPU가 집중적으로 사용되는 작업을 추가로 수행할 수 있습니다.

 

알아야 내용이 있나요?

  • 프레임이 자주 렌더링되지 않더라도 이벤트가 스크립트에 전송되는 속도는 평소와 같습니다. 따라서 렌더링되지 않은 프레임 동안에도 입력을 수신할 수 있습니다. 입력 지연을 방지하려면 입력하는 동안renderFrameInterval = 1을 호출하여 버튼, 이동 등의 반응성을 유지해야 합니다.
  • 다량의 스크립팅, 물리, 애니메이션 등의 작업이 이루어지지만 렌더링하지 않는 상황에서는 온디맨드 렌더링으로 큰 효과를 보지 못할 수 있습니다. 결과물에 끊김이 발생할 가능성이 있으며 CPU 및 전력 사용량 절감 역시 미미한 수준에 그칠 수 있습니다.

다음 예는 메뉴에 온디맨드 렌더링을 사용하여 입력이 발생하지 않을 때 20fps로 렌더링할 수 있는 방법을 보여줍니다.

 

이 예시 프로젝트를 통해 다양한 상황에서 온디맨드 렌더링을 활용하는 방법을 확인할 수 있습니다.

온디맨드 렌더링을 사용 중이신가요?

포럼에서 온디맨드 렌더링을 어떻게 활용하고 있는지 알려주세요. Windows, macOS, WebGL, iOS, Android에서 Unity 에디터와 스탠드얼론 플레이어를 대상으로 테스트를 완료했으나, 피드백은 언제든지 환영합니다.

20 replies on “온디맨드 렌더링을 이용한 모바일 성능 개선”

I think on-demand rendering is an excellent solution for achieving performance. My team has not tested yet, but thanks for the article!

“Where is it supported?” – Now it has become popular to use pre rendering (SPA), even in e-commerce projects. For example – https://firusas.com/, this is just a fashion website!
But even in e-commerce, they work on productivity, creating SPA.

Above all, aim to create a website that can balance aesthetics and performance on mobile, and achieve real conversion metrics. A collaborative, iterative performance optimization process will help you achieve this.

Right from the start of the project, encourage the internal team to work together under a mobile mindset by setting a strict performance budget. Build an understanding of the client and server-side factors that determine website performance on mobile. Then you can meet the goal set by implementing a mixture of the targeted optimization techniques I have described. Of course, there’s still a trade-off between having a striking design, high performance and security in some cases; a collaborative design and development team can decide what’s best for the business, checking with relevant project managers and stakeholders.

————————————————————-
Editor: https://mangazuki.site/

What are the differences between use of OnDemandRendering.renderFrameInterval 2 with Application.targetFrameRate 60 or directly use Application.targetFrameRate 30 manually? Also, if you recommend using OnDemandRendering.renderFrameInterval 1. Where do we gain performance? Thanks in advance!

1) Application.targetFrameRate will affect how often Update is called. OnDemandRendering will keep your Update cycle at the targeted rate, but rendering will only be performed once every n cycles.

2) targetFramerate is not intended to be manipulated frequently at runtime. Using it as an alternative to renderFrameInterval seems to function well enough on iOS, but can cause flickering on some Android devices.

I submitted a bug report regarding OnDemandRendering on Jan 28th and haven’t heard back. (1214921)

The issue seems to be that cameras rendering into render textures don’t get throttled correctly, and update their textures additively, affecting transparency.

Should I also start a forum thread to actually get attention?

I think that any resource can be used unethically. I had not considered this way of discussing a bad habit of on-demand rendering, but this sounds to me an easy case to be verified in stress tests.

I’m getting errors upon opening the example project.
“The name ‘RenderPipeline’ does not exist in the current context”

Thank you for adding this feature! This see this feature helping the application I am developing significantly.

Recently there were a lot of smartphones coming with advertised 90 & 120Hz screen refresh rates, which in reality are refreshing screen at 60Hz or less most of the time.
With 120Hz Samsung and iPhone phones coming this year, I foresee already an avalanche of mobile games coming soon with *120 screen refresh rate support!!!* ads labelled all over them, which in reality won’t reach even 60FPS most of the time. With developers saying “oh, you know, our game actually runs at 120FPS, we are just using on-demand rendering at 30FPS most of the time to save your battery, you know”. So this feature will come in handy for developers who want to cash in on the newest hype of high refresh screens, I suppose. Not so good for customers, who will be fooled again by yet another creative marketing.

I was hoping to see “Rendering layers”, still its a cool feature and absolutely will use it as soon as possible. Thanks Unity, Keep it up

What about rendering in layers e.g. Onion Skybox’s so basic turning without moving can work with minimum rendering overhead?

Comments are closed.