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: August 21, 2023, 11:30 AM to 12:00 PM Amsterdam Time (Your local time: 2023-08-21T09:30:00Z → 2023-08-21T10:00:00Z)
Attendees:
- Clement
- Jeroen
- Michael
- Omar
Eevee-next
- New solutions for shadow rendering are being researched and prototyped. When rendering a scene most time is spent on updating the shadow textures. This lead to undesired performance. Some solutions that were looked into didn’t scale to all the platforms we need to support. Other solutions would reduce the shadow quality when navigating or editing in the scene, which leads to a different kind of usability issues. A possible solution have been found and is currently being implemented and tested. We are not replacing the VSM method, but optimizing the implementation to be better suitable for our use case.
Metal-backend
- EDR support landed in main
- Work continues in stabilizing and adding features for Eevee-next to the Metal Backend
Vulkan-backend
- Development on the Vulkan backend has started again. After reviewing the current state the plan is to improve the command encoding. The current command encoding is deliberatly not flexible. The problem of command encoding is now better understood (with the experience we got on using Vulkan the past half year).
- The goal of command encoding is to track the commands that are sent to the GPU and where possible reorder, combine commands or add detailed memory barriers. Eventually this would lead to faster rendering, without loosing the flexibility that is required by the user interface code of Blender.
GPU Compositor
- A question was raised if it was possible to use a software rasterizer (LLVMPIPE) to implement the CPU part of the compositor. Discussion went into the impact and potential benefits and drawbacks with this approach.
- Current GPU module uses globally state to keep track of device features. LLVMPIPE will have a different set and this should be kept separated
- Some features might be missing and can lead to issues later on
- Approach could also be used for other cases to streamline CPU and GPU execution
- Multi device in a single application can work, but gets into context issues when using the OpenGL API. Vulkan might be a better target for this.
Blender 4.0
- Blender BCon2 will start upcoming week. Any breaking changes will be prioritized
- Moving some settings from cycles to DNA so we won’t break the API in a later Blender version
- Wireframe Fresnell patch code wise is fine, some changes have been asked on usability side.