2024-03-05 Render & Cycles Meeting


  • Brecht Van Lommel (Blender)
  • Thomas Dinges (Blender)
  • Weizhen Huang (Blender)
  • Lukas Stockner (Blender)
  • Patrick Mours (NVIDIA)
  • Nikita Sirgienko (Intel)
  • Christophe Hery (Meta)


  • Brecht is working on high priority bugs regarding OptiX OSL and Metal AMD support. We keep running into compiler bugs for Metal AMD, and are considering to drop support for it in 4.1 if we can’t solve it within a reasonable time.
  • Nikita is working on a pull requests that adds support for OIDN GPU denoising for CPU denoising, and improves usage of preferences to determine the denoising device. There was some discussion about the implementation details of this.
  • Nikita brought up the topic of using OIDN for all GPU devices, as NVIDIA is the exception now that defaults to OptiX. Brecht mentions that it was already the plan to change this so OIDN is the default everywhere for consistency between devices and final renders. Nikita volunteered to implement this change.
  • Lukas continued work on pull requests submitted last weeks. For thin film color management was improved. For dithered sampling, the most practical solution seems to be a simple heuristic like using it for the first sample in viewport rendering, if the max number of samples is higher than 16.
  • Weizhen landed support for near-field microfacet hair, and committed some fixes for this BSDF.
  • Weizhen is investigating ReSTIR algorithms for Cycles. The plan is to first get a simple case working for direct illumination and point lights. For sampling patterns it seems best to add a new dimensions for new sampling strategies. There are some questions regarding shadow rays to be figured out.

Practical Info

This is a weekly video chat meeting for planning and discussion of Blender rendering development. Any contributor (developer, UI/UX designer, writer, …) working on rendering in Blender is welcome to join and add proposed items to the agenda.

For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.


As there’s work at the denoising done right now - is there a chance to add the option to cancel the denoising as well when the rendering is cancelled. Right now, when I cancel a rendering, the denoiser is still engaged and the canceling takes much longer - especially when you cancel a rendering that is really big.

IIRC this was already implemented, at least if I understand this commit here correctly:

It’s an early abort for the Compositor, but the commit log mentions “Similar implementation to what Cycles does.”

EDIT: Forget what I just said. I quickly tried it in latest main and it does not early abort when stopping a Cycles render.

1 Like

Unfortunately not. I just tested it in 4.1. After hitting ESC the status line goes to “Reading full buffer from disk” and then goes to “Denoising”.

Yes, I noticed this too. If it works for the Compositor it could also work for Cycles. Especially when working with larger resolutions it can indeed become very annoying to always have to wait for the Denoiser to finish.

1 Like

Are there any sort of min specs requirements for using OIDN on GPU?
I’m asking because when trying Blender 4.2alpha (on my RTX2080Ti) the viewport denoising checkmark is grayed out, and the denoising speed is indeed that of the CPU

On NVIDIA side you need Volta or newer. So that includes devices like:
Titan V
GTX 16 series
RTX 20 series (What you have)
RTX 30 series
RTX 40 series

To use GPU denoising, you must also be using your GPU for rendering, but this may change in the future.

If you meet all those requirements and it’s still not working, then you’ll want to try updating your GPU drivers just in case, and if that’s not working, make a bug report.

Refer to GitHub - OpenImageDenoise/oidn: Intel® Open Image Denoise library for hardware supported by OIDN (which may deviate from Cycles as new releases come out). Or refer to Cycles - Blender Developer Documentation for the list of supported hardware according to the Blender foundation.


I’ll try updating drivers, and report back here the outcome

So in the end it was that: updating drivers did the job, and now I can enjoy supersmooth denoising. Yay!