2022-08-29 Eevee/Viewport Module Meeting

Meetings
1

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: September 5, 2022, 11:30 AM to 12:00 PM Amsterdam Time (Your local time: 2022-09-05T09:30:00Z → 2022-09-05T10:00:00Z)

Attendees:

  • Omar Emara
  • Clément Foucault
  • Jeroen Bakker

Draw manager

  • Main difference with the previous draw manager is that the new draw manager will generate commands on the GPU. It will reduce a lot of code and would improve performance.
  • Rewrite is progressing nicely. One demo file is still crashing. Root cause is not clear yet and will be investigated.
  • Currently performance gain cannot be detected. A cause for this is that EEVEE-Next doesn’t support instancing yet what would gain the most.
  • This week we want to review the changes mostly to share the new design and implications.

EEVEE-Next

  • Cryptomatte render layers for EEVEE-Next is being developed. Hopefully will be finished this week. Blender Archive - developer.blender.org
  • After the draw manager changes, the drawing of shadows will be picked up.

Metal Backend

  • New version of the patch was uploaded today.
  • Still some notes haven’t been addressed, but the main idea is there. We discussed to accept the patch as the left over notes are mostly code styles. It is faster to do these in master due to the time it takes (manual steps) to upload a new version of the patch to developer.blender.org.

Viewport compositing

  • Review of new nodes are mainly done by checking on compute shader solution. The actual testing are left to the community and Omar.
  • Worked on Scale, Bokeh Blur, and Dilate/Erode node.
  • There was a question why the size socket of the Bokeh Blur could lead to a different kernel. The reason for this is that the size isn’t the blur of the pixel itself, but the size of surrounding pixels that can bleed over the pixel that is being evaluated. Hence there is a more precise kernel that covers this when the size isn’t constant. The pre-kernel tries to optimize the area where bleeding can occur.
  • Next nodes would be Fast Gaussian and Glare.

AMD Support

  • It seems that the new AMD drivers (Adrenalin 22.7.1 or 22.8.2) are failing. We are considering to blacklist these drivers due to random driver-level crashes and blocky artifacts or failing drawing. Solving this from our side takes time especially with the current running projects.
  • These drivers are currently optional, but don’t have confirmation that the issues will be fixed before becoming main-stream.
  • When blacklisted the user would show a popup that they are running on a non-supported platform with a link to a page why they are not supported.
18 Likes
2

Yay, glare! You’re going to make a lot of people happy with that.

3

I am closely following the Cryptomatte development on the realtime viewport. The implementation is awesome news!

4

A cause for this is that EEVEE-Next doesn’t support instancing

Does EEVEE-Next will suffer the same performance issue with too many instances like normal EEVEE or is there some improvement beside just adding instancing to EEVEE-Next ?

Thanks

2 Likes
5

Pablo mentioned this during the lunch and I updated the notes as currently EEVEE-Next doesn’t support instancing “yet”. It should eventually support it before it lands in a release. On the actual gains is still to early to tell as this has more to do with how rasterizers work. In a future project we would like to look in different solutions, but our current goal is to be on par with EEVEE.

3 Likes