2023-06-19 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: June 26, 2023, 11:30 AM to 12:00 PM Amsterdam Time (Your local time: 2023-06-26T09:30:00Z2023-06-26T10:00:00Z)


  • Jeroen
  • Michael
  • Miguel


  • Subsurface scattering has landed in main. [#107407 - EEVEE Next: Subsurface Scattering - blender - Blender Projects]
  • Viewport HDRI selector is being worked on. Initial version would not support blurring.
  • Modified the way how textures are bound to shaders. Eevee-next used to bind internal textures and buffers to slots upto 15, leaving the lower slot numbers for user textures. This has been switched; internal textures and buffers are now occupying lower slots, and user textures the higher slots. Freeing more slots for user textures. Slot 0 and 1 are reserved still for Grease pencil [#108984 - EEVEE Next: Improved sampler indices - blender - Blender Projects]
  • Improved validation messages so it is easier for developers to track the reason that raises the messages.


Metal backend

Vulkan backend

  • Added support for compute indirect. [#108879 - Vulkan: Indirect Compute - blender - Blender Projects]
  • Some experiments have been done to for device selection. Current outcome is that it is to early to add support for these configurations. The backend should mature more, before this could be tackled. It has been investigated to speed up platform support by installing GPUs of multiple vendors in a single case. Currently we switch GPUs multiple times a day.

Is there a list of differences/improvements over Eevee’s? From the wording of “port” I assumed that there would be no big differences but after some test I see they are actually different.

I guess “New algorithm that eliminate light leaking between objects and supports per pixel radius” (from the main task list) is still valid?

Hi and thanks for testing! SSS algorithm hasn’t changed, only defaults. In Eevee the SSS translucency is a per material setting, in Eevee-next this is always active. Can you check if this is also the case for your scene?

@sunkper @Jeroen-Bakker It’s actually a different method, based on this paper.

The port is from the eevee-rewrite branch (where Clément started the development of EEVEE Next), not from the current EEVEE implementation.


Short answer: no but we try.

We try hard to get very good performance within the scope of a 3d content creation suite. It is not that we are trying to make Blender slow :slight_smile:

Blender isn’t a game engine and has different requirements. For example you cannot edit a mesh in unreal engine in the same detail as Blender. Even with their development budget and large development teams they still import their assets from other tools including Blender.

What if using the same technology as Unreal engine means that you’re not able to edit any mesh in Blender in material preview/render preview mode. Unreal also renders different result based on your actual hardware. Many options or design decisions that unreal (or any game engine) have that doesn’t make sense in the context of Blender.