Cycles: Adjust resolution divider to achieve a more usable viewport #105581

Merged

Brecht Van Lommel merged 1 commits from Alaska/blender:cycles-adjust-minimum-viewport-resolution into main

2023-03-17 11:16:09 +01:00

Alaska commented

2023-03-09 04:14:30 +01:00

Member

This patch changes the maximum viewport resolution divider for Cycles
to help users get a more responsive viewport.

This is done by changing the maximum viewport resolution divider
to a divider that aims to have the largest axis of the viewport
roughly equal to 128 pixels.

Depending on the circumstances, this change can result in a few
noticeable differences:

Users with slow hardware and a large pixel_size, or slow hardware
and a low resolution screen, may observe a higher resolution viewport
during navigation, making the scene more readable. However this comes
at the cost of reduced responsiveness.
Users with slow hardware and a low pixel_size and high
resolution screen may observe a lower resolution viewport during
navigation, providing a more responsive viewport during navigation.

Along with that, how Cycles iterates through resolution dividers
is changed to promote quick transitions between resolution dividers.
Meaning users don't need to wait through as many iterations to get
from a low navigation resolution to a 1:1 viewport resolution.

This patch changes the maximum viewport resolution divider for Cycles to help users get a more responsive viewport. This is done by changing the maximum viewport resolution divider to a divider that aims to have the largest axis of the viewport roughly equal to 128 pixels. Depending on the circumstances, this change can result in a few noticeable differences: - Users with slow hardware and a large pixel_size, or slow hardware and a low resolution screen, may observe a higher resolution viewport during navigation, making the scene more readable. However this comes at the cost of reduced responsiveness. - Users with slow hardware and a low pixel_size and high resolution screen may observe a lower resolution viewport during navigation, providing a more responsive viewport during navigation. --- Along with that, how Cycles iterates through resolution dividers is changed to promote quick transitions between resolution dividers. Meaning users don't need to wait through as many iterations to get from a low navigation resolution to a 1:1 viewport resolution.

Alaska requested review from Brecht Van Lommel 2023-03-09 04:14:51 +01:00

Alaska requested review from Sergey Sharybin 2023-03-09 04:14:52 +01:00

Alaska added the

Render & Cycles

label 2023-03-09 04:15:02 +01:00

Alaska commented

2023-03-09 04:15:42 +01:00

Author

Member

@blender-bot build

@blender-bot build

Blender Bot commented

2023-03-09 04:15:44 +01:00

Member

Only blender organization members with write access can start builds. See documentation for details.

Only blender organization members with write access can start builds. See [documentation](https://projects.blender.org/infrastructure/blender-bot) for details.

Alaska force-pushed cycles-adjust-minimum-viewport-resolution from 441ff19c1e to 72445688b3

2023-03-09 06:04:46 +01:00

Compare

Alaska added this to the Render & Cycles project 2023-03-09 07:44:05 +01:00

Alaska added the

Render & Cycles

label 2023-03-09 07:44:20 +01:00

Alaska force-pushed cycles-adjust-minimum-viewport-resolution from 72445688b3 to 92b62fc0fc

2023-03-09 08:37:27 +01:00

Compare

Alaska force-pushed cycles-adjust-minimum-viewport-resolution from 92b62fc0fc to 909a68c45f

2023-03-09 09:19:58 +01:00

Compare

Alaska commented

2023-03-09 09:23:39 +01:00

Author

Member

Here is two videos that showcase the changes introduced with this pull request.

Note: This is the italian flat scene, and it is running in a viewport of size 2000x1000 with 4 threads from a Ryzen 9 5950X (emulating the performance of some modern laptop CPUs, and various older desktop CPUs).

Note 2: Main is on the left, my pull request is on the right.

Comparison of navigation performance on slow hardware
Comparison of navigation performance on slow hardware.mp4

As you can see, the code change is resulting in a lower viewport resolution while navigating to allow for more responsive feedback. However, as a result of the lower resolution, it is harder to make out what's happening. For some scenes the overall responsiveness is a benefit, for others clarity is preferred, and the loss in resolution is detrimental.

I set the "lowest resolution" to 128 pixels on the long axis to try and avoid the resolution dropping too low, and this value can be tweaked if needed.

Comparison of transition between navigating to 1:1 viewport render on slow hardware
Comparison of transition on slow hardware.mp4

My adjustments to the system that transitions the viewport from the low navigation resolution to a 1:1 preview results in a quicker transition between the two. And depending on the speed of the hardware, this change may or may not be noticeable.

For faster hardware, there is a benefit, but it's less noticeable.

Here is two videos that showcase the changes introduced with this pull request. Note: This is the italian flat scene, and it is running in a viewport of size 2000x1000 with 4 threads from a Ryzen 9 5950X (emulating the performance of some modern laptop CPUs, and various older desktop CPUs). Note 2: Main is on the left, my pull request is on the right. | Comparison of navigation performance on slow hardware | | -------- | | [Comparison of navigation performance on slow hardware.mp4](/attachments/c296842e-fdda-48dc-9039-981a56be70de) | As you can see, the code change is resulting in a lower viewport resolution while navigating to allow for more responsive feedback. However, as a result of the lower resolution, it is harder to make out what's happening. For some scenes the overall responsiveness is a benefit, for others clarity is preferred, and the loss in resolution is detrimental. I set the "lowest resolution" to 128 pixels on the long axis to try and avoid the resolution dropping too low, and this value can be tweaked if needed. --- | Comparison of transition between navigating to 1:1 viewport render on slow hardware | | -------- | | [Comparison of transition on slow hardware.mp4](/attachments/84cbd4d5-8a37-47b6-bf88-8ea2d5b4b0fd) | My adjustments to the system that transitions the viewport from the low navigation resolution to a 1:1 preview results in a quicker transition between the two. And depending on the speed of the hardware, this change may or may not be noticeable. For faster hardware, there is a benefit, but it's less noticeable.

Comparison of navigation performance on slow hardware.mp4

2.5 MiB

Comparison of transition on slow hardware.mp4

2.4 MiB

Alaska force-pushed cycles-adjust-minimum-viewport-resolution from 909a68c45f to 7dfaa5786c

2023-03-09 12:20:00 +01:00

Compare

Alaska changed title from ~~Cycles: Promote usable viewport by changing max divider and transition~~ to Cycles: Adjust resolution divider to achieve a more usable viewport

2023-03-09 12:21:23 +01:00

Alaska force-pushed cycles-adjust-minimum-viewport-resolution from 7dfaa5786c to ff0ce1dfee

2023-03-10 01:28:07 +01:00

Compare

Brecht Van Lommel approved these changes 2023-03-14 13:13:51 +01:00

Brecht Van Lommel left a comment

Owner

This seems to work fine testing with various scenes and CPU/GPU. It's a bit difficult to understand the full impact of changes like this, but I think we can land this and see what the feedback is, as I could not find cases where it's clearly worse.

This seems to work fine testing with various scenes and CPU/GPU. It's a bit difficult to understand the full impact of changes like this, but I think we can land this and see what the feedback is, as I could not find cases where it's clearly worse.

Alaska commented

2023-03-16 06:17:49 +01:00

Author

Member

This patch, excluding the changes made to how Cycles iterates through resolution dividers, can be argued as either a downgrade or an improvement depending on who you are. For example:

Some scenes and hardware combinations will see an improvement in responsiveness at the cost of resolution.
Other scenes and hardware combinations see an improvement in resolution at the cost of responsiveness.
While I assume a large number of people see no differences in a wide range of scenes as their hardware is fast enough, their monitor's resolution is in a sweet spot, and the scene is simple enough for them to avoid the area this patch modifies.

And the preference on whether or not you want a more responsive viewport or a higher resolution viewport changes depending on who you are, what you're currently doing in the scene, and the scene you have.

For example, if I have a scene mostly in direct light with clear object shapes and colours, then a more responsive viewport at the cost of resolution is acceptable if my main goal is navigation. This is because the scene is still "readable" at a low resolution due to low noise and clear distinction between objects.

But if the scene consists mostly of noisy indirect lighting, or doesn't have clear distinctions between objects, then a higher resolution may be preferred so the user can see what they're doing in the viewport.

So I'm just wondering, what if we let users choose between resolution and responsiveness? Some ideas are:

Add a setting that lets users choose between "Prefer resolution during navigation" or "Prefer responsiveness during navigation".
Add a "minimum viewport resolution" option. And it controls the "128 pixel minimum viewport size" parameter that I currently have hard coded.
Instead of the "minimum viewport resolution", maybe there's a "minimum viewport resolution divider" option?

I have proposed ideas similar to these in the past during Cycles-X development (https://archive.blender.org/developer/differential/0012/0012338/index.html), it was declined for various reason, and some of the issues about Cycles-X brought up in the comments have been fixed. But it's been some time, and the circumstances and solution is slightly different. So I'm asking again to see if thoughts on the matter have changed.

This patch, excluding the changes made to how Cycles iterates through resolution dividers, can be argued as either a downgrade or an improvement depending on who you are. For example: - Some scenes and hardware combinations will see an improvement in responsiveness at the cost of resolution. - Other scenes and hardware combinations see an improvement in resolution at the cost of responsiveness. - While I assume a large number of people see no differences in a wide range of scenes as their hardware is fast enough, their monitor's resolution is in a sweet spot, and the scene is simple enough for them to avoid the area this patch modifies. And the preference on whether or not you want a more responsive viewport or a higher resolution viewport changes depending on who you are, what you're currently doing in the scene, and the scene you have. For example, if I have a scene mostly in direct light with clear object shapes and colours, then a more responsive viewport at the cost of resolution is acceptable if my main goal is navigation. This is because the scene is still "readable" at a low resolution due to low noise and clear distinction between objects. But if the scene consists mostly of noisy indirect lighting, or doesn't have clear distinctions between objects, then a higher resolution may be preferred so the user can see what they're doing in the viewport. So I'm just wondering, what if we let users choose between resolution and responsiveness? Some ideas are: - Add a setting that lets users choose between "Prefer resolution during navigation" or "Prefer responsiveness during navigation". - Add a "minimum viewport resolution" option. And it controls the "128 pixel minimum viewport size" parameter that I currently have hard coded. - Instead of the "minimum viewport resolution", maybe there's a "minimum viewport resolution divider" option? I have proposed ideas similar to these in the past during Cycles-X development (https://archive.blender.org/developer/differential/0012/0012338/index.html), it was declined for various reason, and some of the issues about Cycles-X brought up in the comments have been fixed. But it's been some time, and the circumstances and solution is slightly different. So I'm asking again to see if thoughts on the matter have changed.

Sergey Sharybin approved these changes 2023-03-17 11:02:33 +01:00

Sergey Sharybin left a comment

Owner

I am still not really sure options like that will work good in practice. As you've said the different could be tricky to spot unless you do side-by-side comparison. Also, figuring out which of the ways works the best for the current file an artist is not something artists are invested into in my experience.

In a way, the interesting long-term plan would be to make the resolution divider balanced between speed and resolution, and for the rest rely on a GPU side denoising.

And perhaps even simplify the entire thing to 2 resolutions: navigation and final. Not sure those extra steps is something that is really making things better for artists.

In any case, this is not something that necessarily belongs to a code review. We can talk about it in the chat.

The patch seems to bring some improvement. Agree with Brecht, we should probably land the patch and see for a feedback.

I am still not really sure options like that will work good in practice. As you've said the different could be tricky to spot unless you do side-by-side comparison. Also, figuring out which of the ways works the best for the current file an artist is not something artists are invested into in my experience. In a way, the interesting long-term plan would be to make the resolution divider balanced between speed and resolution, and for the rest rely on a GPU side denoising. And perhaps even simplify the entire thing to 2 resolutions: navigation and final. Not sure those extra steps is something that is really making things better for artists. In any case, this is not something that necessarily belongs to a code review. We can talk about it in the chat. The patch seems to bring some improvement. Agree with Brecht, we should probably land the patch and see for a feedback.

Brecht Van Lommel commented

2023-03-17 11:11:15 +01:00

Owner

I think there's a point of diminishing returns here. We can keep fiddling with this logic or adding more or different options. But I would rather not change too much unless it's obviously better and focus on other areas of Cycles.

I think there's a point of diminishing returns here. We can keep fiddling with this logic or adding more or different options. But I would rather not change too much unless it's obviously better and focus on other areas of Cycles.

Brecht Van Lommel merged commit 0963ee559e into main

2023-03-17 11:16:09 +01:00

Brecht Van Lommel referenced this issue from a commit

2023-03-17 11:16:10 +01:00

Cycles: adjust resolution divider to achieve a more usable viewport

Brecht Van Lommel deleted branch cycles-adjust-minimum-viewport-resolution

2023-03-17 11:16:10 +01:00

Daniel Paul commented

2023-03-21 16:38:18 +01:00

First-time contributor

Tested it right now on an 3080 rtx with optix, it actually feels slower while navigating the viewport for me.

Tested it right now on an 3080 rtx with optix, it actually feels slower while navigating the viewport for me.

Alaska commented

2023-03-21 23:52:32 +01:00

Author

Member

@DanielPaul, can we continue this conversation over on devtalk? We can discuss what's happening and see if we can figure out what's causing it.

https://devtalk.blender.org/t/feedback-wanted-on-cycles-resolution-divider-changes/28374

@DanielPaul, can we continue this conversation over on devtalk? We can discuss what's happening and see if we can figure out what's causing it. https://devtalk.blender.org/t/feedback-wanted-on-cycles-resolution-divider-changes/28374

Brecht Van Lommel removed this from the Render & Cycles project 2023-05-24 19:05:20 +02:00

Brecht Van Lommel referenced this issue from a commit

2023-07-06 16:00:07 +02:00

Adjust resolution divider to achieve a more usable viewport

Sign in to join this conversation.

No reviewers

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

5 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#105581

No description provided.