Regression: Cycles viewport pixels change if the UI is updated in a certain way. #103556

New Issue

Alaska · 2022-12-30T11:33:54+01:00

Alaska commented

2022-12-30 11:33:54 +01:00

System Information
Operating system: macOS-13.1-arm64-arm-64bit 64 Bits
Graphics card: Metal API Apple M1 Pro 1.2

Blender Version
Broken: version: 3.5.0 caused by b132e3b3ce
Worked: 3.4.0

Short description of error
When updating certain parts of the Blender UI, renders provided by Cycles (Viewport renders and render progress on the final render) will change. It's kind of like the pixels start mixing together.
This is most noticeable on scenes with lots of noise and high contrast between the noise.

I tested this on Windows and macOS and was only able to reproduce the issue on macOS.
I also test the openGL and Metal backends for Blender and could reproduce the issue on both.

Exact steps for others to reproduce the error

Create a high contrast noisy Cycles scene (E.G. Two lights, 1 spp, light tree off)
Enter the Cycles rendered viewport.
Update certain parts of the UI (E.G. Select an object) and notice how the noise appears to change as if the pixels merged a bit.

Here is a video and the .blend file I used:

High Contrast Noisy Scene.blend

Cycles pixels changing with UI updates.mp4

**System Information** Operating system: macOS-13.1-arm64-arm-64bit 64 Bits Graphics card: Metal API Apple `M1` Pro 1.2 **Blender Version** Broken: version: 3.5.0 caused by b132e3b3ce Worked: 3.4.0 **Short description of error** When updating certain parts of the Blender UI, renders provided by Cycles (Viewport renders and render progress on the final render) will change. It's kind of like the pixels start mixing together. This is most noticeable on scenes with lots of noise and high contrast between the noise. **I tested this on Windows and macOS and was only able to reproduce the issue on macOS.** I also test the openGL and Metal backends for Blender and could reproduce the issue on both. **Exact steps for others to reproduce the error** 1. Create a high contrast noisy Cycles scene (E.G. Two lights, 1 spp, light tree off) 2. Enter the Cycles rendered viewport. 3. Update certain parts of the UI (E.G. Select an object) and notice how the noise appears to change as if the pixels merged a bit. Here is a video and the .blend file I used: [High Contrast Noisy Scene.blend](https://archive.blender.org/developer/F14100330/High_Contrast_Noisy_Scene.blend) [Cycles pixels changing with UI updates.mp4](https://archive.blender.org/developer/F14100329/Cycles_pixels_changing_with_UI_updates.mp4)

Alaska commented

2022-12-30 11:33:54 +01:00

Added subscriber: @Alaska

Germano Cavalcante commented

2022-12-30 20:23:28 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Germano Cavalcante commented

2022-12-30 20:23:28 +01:00

Added subscriber: @mano-wii

Alaska commented

2022-12-30 22:35:30 +01:00

Added subscribers: @Jason-Fielder, @brecht

Alaska commented

2022-12-30 22:35:30 +01:00

Bisecting points to this issue being introduced with b132e3b3ce
CC @Jason-Fielder and @brecht

Bisecting points to this issue being introduced with b132e3b3ce CC @Jason-Fielder and @brecht

Germano Cavalcante commented

2022-12-30 22:42:52 +01:00

Thank you, @Alaska, for bisecting.
Since this is a regression, then it has high priority.

Thank you, @Alaska, for bisecting. Since this is a regression, then it has high priority.

Germano Cavalcante changed title from ~~Cycles viewport pixels change if the UI is updated in a certain way.~~ to Regression: Cycles viewport pixels change if the UI is updated in a certain way.

2022-12-30 22:43:24 +01:00

Michael Parkin-White commented

2023-01-03 11:57:20 +01:00

Added subscriber: @Michael-Parkin-White-Apple

Brecht Van Lommel commented

2023-01-09 20:21:48 +01:00

This issues here is with GPU_texture_filter_mode:

With the GPU API this should be called before GPU_texture_bind to take effect, which causes the delay
There is no GPU API equivalent option for the previous glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

This goes back to 2526a35, which I don't fully understand yet.

This issues here is with `GPU_texture_filter_mode`: * With the GPU API this should be called before `GPU_texture_bind` to take effect, which causes the delay * There is no GPU API equivalent option for the previous `glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);` This goes back to 2526a35, which I don't fully understand yet.

Michael Parkin-White self-assigned this 2023-01-10 11:20:45 +01:00

Michael Parkin-White commented

2023-01-10 11:20:45 +01:00

This could perhaps be achieved in a similar way to the GPU_SAMPLER_ICON which uses a custom sampler declaration if this is needed.

/* Custom sampler for icons. */
  GLuint icon_sampler = samplers_[GPU_SAMPLER_ICON];
  glSamplerParameteri(icon_sampler, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_NEAREST);
  glSamplerParameteri(icon_sampler, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
  glSamplerParameterf(icon_sampler, GL_TEXTURE_LOD_BIAS, -0.5f);

Is this the case that only the min filter is set to nearest, with the others being linear, or should nearest filtering used uniformly for the cases where the image is zoomed in:

const float zoomed_width = draw_tile.params.size.x * zoom.x;
  const float zoomed_height = draw_tile.params.size.y * zoom.y;
  if (texture.width != draw_tile.params.size.x || texture.height != draw_tile.params.size.y) {
    /* Resolution divider is different from 1, force nearest interpolation. */
    GPU_texture_filter_mode(texture.gpu_texture, false);
  }
  else if (zoomed_width - draw_tile.params.size.x > 0.5f ||
           zoomed_height - draw_tile.params.size.y > 0.5f) {
    GPU_texture_filter_mode(texture.gpu_texture, false);
  }
  else {
    GPU_texture_filter_mode(texture.gpu_texture, true);
  }
``

As the true/false parameters on `GPU_texture_filter_mode` should toggle between GL_LINEAR and GL_NEAREST. So perhaps this case is as simple as moving the filter mode settings to before the bind call.

Secondly, could instead use `GPU_texture_bind_ex(..)` and specify a custom sampler config at bind time, rather than as a property on the texture. This could possibly be more efficient as no internal texture state gets modified. Though the details are likely negligible. It would just mean that the intent of the code with changing filter modes is clearer.

But I can look into fixing this.

I haven't yet been able to repro the exact behaviour however, but will play around with the viewport size to see if the bad path can be triggered.

This could perhaps be achieved in a similar way to the `GPU_SAMPLER_ICON` which uses a custom sampler declaration if this is needed. ``` /* Custom sampler for icons. */ GLuint icon_sampler = samplers_[GPU_SAMPLER_ICON]; glSamplerParameteri(icon_sampler, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_NEAREST); glSamplerParameteri(icon_sampler, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glSamplerParameterf(icon_sampler, GL_TEXTURE_LOD_BIAS, -0.5f); ``` Is this the case that only the min filter is set to nearest, with the others being linear, or should nearest filtering used uniformly for the cases where the image is zoomed in: ``` const float zoomed_width = draw_tile.params.size.x * zoom.x; const float zoomed_height = draw_tile.params.size.y * zoom.y; if (texture.width != draw_tile.params.size.x || texture.height != draw_tile.params.size.y) { /* Resolution divider is different from 1, force nearest interpolation. */ GPU_texture_filter_mode(texture.gpu_texture, false); } else if (zoomed_width - draw_tile.params.size.x > 0.5f || zoomed_height - draw_tile.params.size.y > 0.5f) { GPU_texture_filter_mode(texture.gpu_texture, false); } else { GPU_texture_filter_mode(texture.gpu_texture, true); } `` As the true/false parameters on `GPU_texture_filter_mode` should toggle between GL_LINEAR and GL_NEAREST. So perhaps this case is as simple as moving the filter mode settings to before the bind call. Secondly, could instead use `GPU_texture_bind_ex(..)` and specify a custom sampler config at bind time, rather than as a property on the texture. This could possibly be more efficient as no internal texture state gets modified. Though the details are likely negligible. It would just mean that the intent of the code with changing filter modes is clearer. But I can look into fixing this. I haven't yet been able to repro the exact behaviour however, but will play around with the viewport size to see if the bad path can be triggered.

Brecht Van Lommel commented

2023-01-10 16:30:14 +01:00

I think just using GPU_texture_bind_ex is fine in practice, and I will commit that fix.

What seems to be happening is that there is this small offset:

void wmOrtho2_region_pixelspace(const ARegion *region)
{
  wmOrtho2_offset(region->winx, region->winy, -0.01f);
}

If you have very high pixel values the linear interpolation becomes visible as even 1% bleeding into the neighboring pixel is still a big difference. In general I think the 1:1 zoom level should not have linear interpolation at all, but this is enough of a corner case that I don't think it's worth doing anything more complicated.

I think just using `GPU_texture_bind_ex` is fine in practice, and I will commit that fix. What seems to be happening is that there is this small offset: ``` void wmOrtho2_region_pixelspace(const ARegion *region) { wmOrtho2_offset(region->winx, region->winy, -0.01f); } ``` If you have very high pixel values the linear interpolation becomes visible as even 1% bleeding into the neighboring pixel is still a big difference. In general I think the 1:1 zoom level should not have linear interpolation at all, but this is enough of a corner case that I don't think it's worth doing anything more complicated.

blender-admin commented

2023-01-10 16:31:21 +01:00

This issue was referenced by df5ebd348b

This issue was referenced by df5ebd348b66c16084c47543f95a15fc53da5a0f

Brecht Van Lommel commented

2023-01-10 16:36:24 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Brecht Van Lommel closed this issue

2023-01-10 16:36:24 +01:00

valadaptive referenced this issue

2024-05-04 09:57:15 +02:00

Fix #104395: Fix blurry Cycles render preview at 1:1 zoom #120325