2023-04-03 Eevee/Viewport Module Meeting

Practical Info

This is a weekly video chat meeting for planning and discussion of Blender Eevee/viewport module development. Any contributor (developer, UI/UX designer, writer, …) working on Eevee/viewport in Blender is welcome to join.

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

  • Google Meet
  • Next Meeting: April 17, 2023, 11:30 AM to 12:00 PM Amsterdam Time (Your local time: 2023-04-17T09:30:00Z2023-04-17T10:00:00Z)


  • Clement
  • Jeroen

Blender 3.5 release


  • Issues detected when using Intel HD5500 on Windows. Current state is to reproduce it on a developer machine. Most machines we have access to are more modern or use Linux as that platform is more stable when using legacy hardware.
  • Hang when rendering Cycles in Viewport on Apple Silicon. (Patch already landed in main)


  • Continued work on GI solution.
    • EEVEE-Next Irradiance Baking: Due to time constraints it isn’t possible to start implementing a solution that leverage raytracing. So the implementation will try to minimize the amount of changes to the current system while cleaning up the implementation and changing the baking algorithm (#105643 - EEVEE-Next Irradiance Baking - blender - Blender Projects)
    • With the rewrite of the light-cache system, it became clear that the current way of storing the light-cache per scene has its limitations. Going forward we would like to separate the actual stored data and the engine lighting representation. This mean the lighting data would be stored per object then loaded by the engine into its own data structure. (#106449 - EEVEE-Next Irradiance Grid Cache per probe - blender - Blender Projects). This is still in design phase as there are other limitations and differences compared to current implementation. This requires more investigations.
  • Shadow tagging, Volume rendering. Volume rendering is more difficult than expected

Viewport Compositing

  • New Fog implementation based on Eevee Bloom.

Metal backend

  • Optimize EEVEE/SSR for Apple Silicon, 20% improvement by using packed data.
  • Optimize Texture usage flags in Workbench, Eevee (still in review)

Vulkan backend


A bit of a controversional suggestion for Eevee-next.
I think viewport denoising should be removed from Eevee. It tries to solve something that’s actually not a problem, but it just makes it way worse, especially since it’s on by default.

The noise itself is neglectable, you won’t even notice it’s there unless you specifically try to look for it, especially if you don’t even know about it.
Viewport denoising makes the image very blurry durning transforms or animation playback. Which makes the image borderline unreadable.

Just to show an example of how bad it can get. The material here is very exaggerated to show the issue more clearly but this happens in basically every scene i work on.

Another big problem is that people often mistake viewport denoising ghosting for a motion blur preview, which they aren’t able to turn off until explicitly told the cause of it.
Speaking of, motion blur preview in Eevee-next is currently broken with viewport denoising turned on, so I believe fixing it would just be a waste of time, and the feature should just be removed altogether because it brings more harm than good.