Feedback wanted on Cycles resolution divider changes

Feature & Design Feedback
1

I created a patch that has now been merged with Blender master, it includes some changes to the resolution divider Cycles uses in the viewport. Cycles: adjust resolution divider to achieve a more usable viewport · 0963ee559e - blender - Blender Projects

I would love to hear your feedback on it. Is it better, is it worse, do you notice the changes?

Note: I use the terms “slow computer” and “fast computer” here. But whether or not a computer is considered fast or slow is dependent on the scene it’s rendering.

What was changed with this patch:

The Cycles viewport navigations frame rate on “slow" computers with high resolution monitors is improved by decreasing the viewport resolution while navigating. I’m looking for feedback on this. Is the increase in frame rate at the cost of resolution worth it for you?

Example of increased frame rate at reduced resolution

Without the change is on the left, with the change is on the right:

Cycles viewport navigations frame rate on “slow" computers with low resolution monitors is now lower but the navigation viewport resolution is higher (other combinations can also trigger this. E.G. A large pixel size with a “slow” computer, or a small viewport window on a slow computer). I’m also looking for feedback on this. Is the increase in resolution at the cost of frame rate worth it for you?

People with “fast” computers should see no change in navigation performance.

My change also impacts the transition from navigation to a 1:1 viewport render. This should be faster for everyone (with the exception of one specific case, which is already fast).

I am also looking for feedback on this, but it’s less important. (Although the transition is faster, there are fewer transitions which could be considered a bad thing by some people)

Example of changes to viewport navigation resolution transition
Images
Video

Without the change is on the left, with the change is on the right:

More detailed explanation of the changes (It may be harder to understand what's going on by reading this)

All the changes only effect the viewport rendering while you are navigating around the scene or modifying. Along with the transition from the navigation to a full resolution viewport.

  • The maximum resolution divider is now one that targets 128 pixels on the long axis of the viewport. This leads to a few differences:
    • If you have a scene that renders slowly on your hardware, and have a high resolution screen (1080p or higher) and a large viewport, the viewport resolution while navigating MAY now be lower, but the viewport will run at a higher frame rate in that specific situation when compared to before the change. See Footnote 1.
    • If you have a scene that renders slowly on your hardware, and have a low resolution screen, or small viewport, the viewport resolution while navigating may now be higher, but the viewport now runs at a lower frame rate compared to before the change.
    • If the scene renders at an alright speed on your hardware, you probably won’t notice a difference in this area.
  • The number of transitions between resolution dividers has been reduced in most situations.
    • In the old system with a slow rendering scene, it was Stop navigating -> Cycles renders a slightly higher resolution viewport -> Cycles renders a slightly higher resolution viewport -> Full resolution viewport
    • In the new system it’s one of these two depending on the specific conditions:
      • Stop navigating -> Full resolution viewport
      • Stop navigating -> Cycles renders a slightly higher resolution viewport -> Full resolution viewport See Footnote 2.
Footnote 1

Here is an example of the viewport resolution now being lower, but more responsive.
Without the change is on the left, with the change is on the right:

Footnote 2

Here is an example of one of the new viewport navigation transitions.
Without the change is on the left, with the change is on the right:

For anyone providing feedback, can you also provide this information:

  1. What resolution is your screen?
  2. How big is the viewport on your screen? (If you don’t know how to describe it, a screenshot should work)
  3. What is your Pixel Size?
Location of pixel size setting

It’s located in the Render Properties tab of the properties editor.
Location of pixel size

And if you are having a negative experience, screenshots/videos and a description of the issue would be helpful.

7 Likes
2

I did some tests at 720p on my 3600X/1660GTX. It ‘feels’ and ‘works’ faster. I guess because it switches to 1:1 rendering faster than before.

Switching to the full screen Rendering mode in the viewport on my HW at 720p. Rendering steps:

Before (3.4.1):

Resolution 1 → Resolution 2 → Resolution 3 → Final

Before_A
Before_A1280×720 206 KB

Now (3.6):

Resolution 1 → Final

After_A
After_A1280×720 205 KB

Also probability of getting higher viewport resolution from the start has also increased. Which means less ‘steps’ to the ‘final’ resolution i.e. faster viewport rendering.

UPDATE: Also Tested at 1080p and got the same results.

1 Like
3

Out of curiosity, do you ever adjust the “pixel size” parameter for viewport rendering in any of the projects you work on to achieve better performance?

Location of pixel size setting

Location of pixel size

Because if you do, I’d like you to test before and after this change in those projects. The changes I made could have a arguably positive or negative impact in that area for you and I would like to hear your thoughts on it. Is it a positive change or a negative change?

If you don’t adjust the pixel size parameter, then it’s not that important for you to test it as it’s not a real world scenario for you.

4

In the test scenes from the Blender repository (Scanlands, Secret Deer, etc.) I used default settings. In my own scenes I always set ‘Pixel Size’ to 1x.

I’ll test my own scenes with different values and let know if there is any changes.

UPDATE: Tested my own scenes with ‘Pixel Size’ set to ‘Automatic’ and got the same results in both 3.4.1 and 3.6.

5

The automatic setting just picks between 1x, 2x, 4x, and 8x depending on (I believe) the UI scale in Blender. I suspect your UI scale in Blender is low enough for the automatic setting to be 1x. Hence why you don’t notice a difference.

6

Changing it to anything other than 1x or at the very least Automatic is not an option for me because it ‘permanently’ lowers the viewport resolution.

PS. I set my UI scale (interface resolution scale) to 0.85

7

Hey @Alaska you mentioned me at project.blender.

Unfortunately, I can’t share the file, because it is from Chocofur.
Adaptive sampling is activated.

image
image1822×1039 148 KB

In 3.5 it clearly feels snappier especially when I render with cpu only, but I think it is also noticable over gpu. The navigation feels more “fluid” but I can’t tell you why.

In 3.5 it took 29 seconds to achieve 200 samples in viewport over cpu (b03866288728)
in 3.6 it took 30 in this example, so I think there isn’t a big difference (d3bab78d0540)

My System configuration is RTX 3080 with and Ryzen 9 7950x.
Tell me, if I should test something.

Cheers Daniel

8

Interesting. I tested viewport performance (200 samples) in my scenes with 3.4.1 (ef9ca44dee7f) and 3.6 (d3bab78d0540). The latter was 2 seconds faster when I used GPU (1660GTX) and 5 seconds faster when I used CPU (3600X).

9

So you’re saying 3.5 feels snappier and more fluid?

If so, can you provide this information:

  1. What resolution is your screen?
  2. How big is the viewport on your screen?
  3. Are you able to provide a recording comparing Blender 3.5 to 3.6 (Ideally doing CPU and GPU testing)? (The easiest way to keep testing consistent is to animate a camera moving through a scene, switching to the camera view, then playing the animation in the viewport and recording that)
  4. Have you adjusted the the Pixel Size value?
Location of pixel size setting

It’s located in the Render Properties tab of the properties editor.
Location of pixel size

The changes made do not effect the speed of rendering once the viewport reaches a 1:1 resolution. This slow down could just be “margin of error”, or it could be related to other changes made to Cycles in Blender 3.6, or something else. Or you started the timer before the 1:1 viewport resolution.

10
  1. 1440 x 2560
  2. Round about 80% of the Screen
  3. Unfortunately I’m busy right now
  4. Nope

If your changes increase the performance on smaller pc configurations, but not on high-performance ones, maybe it would be a good idea to make this an optional feature. In my case, it definitely feels slower.

Hope this helps a bit

11

Try one of these Blender versions:

Blender 3.6.0 Alpha (bad85fe8c74c) Windows

Blender 3.6.0 Alpha (42380ea99643) Linux

If you have the same ‘issues’ then it has nothing to do the resolution divider.

12

Just to clarify, the changes I’ve made can improve the navigation frame rate on “slow computers” with high resolution monitors by decreasing the viewport resolution while navigating. I’m looking for feedback on this. Is the increase in frame rate at the cost of resolution worth it?

Example of increased frame rate

No change on the left, My change on the right:

My change can also decrease navigation frame rate on “slow computers” with low resolution monitors (other combinations of settings can also trigger this. E.G. A large pixel size with a normal resolution monitor). But the viewport resolution is higher while navigating. I’m also looking for feedback on this. Is the increase in resolution at the cost of frame rate worth it in this specific situation?

People with “fast computers” should see no change in navigation performance.

My change also impacts the transition from navigation to a 1:1 viewport render. This should be faster for everyone (with the exception of one specific case, which was already fast).

I am also looking for feedback on this, but it less important. (Although the transition is faster, there are fewer transitions which could be considered a bad thing by some people)

I use the terms “slow computer” and “fast computer” here. But whether or not a computer is fast or slow is dependent on the scene it’s rendering.

Without the video, it’s hard to figure out why my changes feel less fluid to you. According to the information you’ve provided (resolution, viewport size, pixel size), your setup meets the criteria to see a increase in navigation frame rate or no change in navigation frame rate (this depends on the scene and how well your computer renders it). There shouldn’t be a decrease in navigation frame rate for your setup, but your original report suggests this is the case.

And I would like to investigate why it’s less fluid for you.

13

Looks like [Blender 3.6.0 Alpha (bad85fe8c74c) behaves the same. So maybe 3.6 feels slower in general. You can clearly see, that since 3.6 the subdivision is one step further than in 3.5.

First is 3.6 (bad85fe8c74c), second is 3.6 (2de2db0f79d1), third is 3.5 (d82ffb9787c3).

14

I know what’s happening here. The resolution divider is lower (the viewport is higher resolution) in Blender 3.6 due to this change: Cycles: Replace resolution divider loop with an analytical formula · 9fecf1f8b8 - blender - Blender Projects

This change is also in Blender 3.5, but not in the version you tested with.

A side effect of that change lead to the introduction of more possible resolution dividers for navigation, giving Cycles more granular control over the navigation viewport resolution, resulting in a higher resolution navigation viewport in some situations. I personally consider this a overall positive change.

Also, from looking at the video, your computer with this scene is not in the performance range to benefit from the resolution divider limit changes I made. But it does benefit from the transition changes I made. But they’re mostly invisible due to how fast your computer renders this scene.

1 Like
15

If anyone else has feedback they would like to provide about this change, please do.