2023-04-17 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: April 24, 2023, 11:30 AM to 12:00 PM Amsterdam Time (Your local time: 2023-04-24T09:30:00Z → 2023-04-24T10:00:00Z)

Attendees:

  • Brecht
  • Clement
  • Jeroen
  • Michael
  • Miguel

Regressions

  • The fix to support Eevee on Intel HD4400-HD5500 on Windows introduced a regression that made Eevee unusable on MacOS/AMD using the OpenGL backend. This has been fixed. Thanks to the Blender community for validating the fix works on the problematic platforms. The fix has been marked to be backported to Blender 3.5.1.

Planning

We spent time during the meeting to go over the current state of active projects. Here is an overview.

Eevee-next

  • Indirect lighting
    • Indirect light baking working, but still needs to be added to be used during drawing/rendering.
    • Expect several weeks to polish to a MVP. After that more polishing is needed but that will be postponed after all core features have been implemented.
  • Volume
    • Expected to land in the upcoming week.
    • Smaller changes are needed afterwards.
  • Other
    • SSS has been ported, but still needs to be reviewed
    • SSRT and reflection probes would be prioritised after the core features are available in main.
  • Polishing
    • Shadows still requires more work to be reusable. (bugs, performance). We can still delay it a bit to focus on other areas before that.
    • After the bigger changes have landed the properties that needs to be controlled by users should be clear and work on the UI/Properties can start.

Overlay and selection

  • Overlay and selection will be merged into a single engine. The selection will be done by swapping out the overlay shaders with selection shaders.
  • The selection shaders won’t be using GPU-queries anymore, but use atomics to match the previous behavior.
  • Initial feedback from Campbell is desired to validate the approach. After that the implementation can be extended to other selections, before users can test.
  • Overlay and selection isn’t a requirement for Eevee-next and could also land in a different release.

Workbench

  • Workbench next almost finished; curve rendering and tweaks are still to be done.

Grease pencil

  • Grease pencil next is handled by the GP team members.

Eevee-next

Previous section was about the global state. This section is about the developments that have happened since the last meeting.

  • Irradiance cache is now stored per object
  • Volumes is working with some limitations. Volumes is implemented as a graphics shader and needs to be ported to compute shaders.
  • Eevee-next running on Metal has some unknowns. Most risk would be on platform compatibility. SSBO and bindpoint PR needs to be reviewed and feedback addressed. Platform support could be done after initial Apple Sillicon implementation.
  • Challenge could be supporting Intel iGPUs and we might also bump the minimum requirement for it to match Windows/Linux bump for Blender 4.0.

Vulkan backend

  • Initial development was done to the graphics pipeline (#106224 - WIP: Vulkan: Initial Graphics Pipeline - blender - Blender Projects). This includes the immediate mode support. The initial development was done to find areas that require engineering. The next areas have been found so far:
    • Some vulkan commands have to run inside a VkRenderPass. Other commands (including data transfers) are not able to run inside a render pass. This require changes to the VKCommandBuffer to keep track of what is needed and perform a late render pass binding to reduce unneeded context switches.
    • A better internal API is required to support both the graphics pipeline (using VKBatch/VKVertexBuffers) and immediate mode (using VKImmediate/VKBuffers).
    • Reuse temporary buffers to reduce allocation/deallocation. As buffers are constructed with a specific memory profile these buffers also needs to be managed so in different pools. Idea is to have a VKReusableBuffer that will move its ownership back to the pool when it has been used. This solution is expected to work together with the submission/resource tracker that was introduced for the push constants fallback.
  • Parameter has been added to GPUOffscreen to specify the needed texture usages of its internal textures. This was needed to reduce validation warnings in the Vulkan backend when used in test cases where the data was read back for validation. By default the host visibility flag wasn’t set. (#106899 - GPU: Add Texture Usage Parameter to GPUOffscreen. - blender - Blender Projects)
14 Likes