The original intent of this meeting was to cover both the Render & Cycles and Eevee & Viewport modules, but in practice it was mostly about Cycles. We’ve now made that official, with the addition of a separate Eevee & Viewport module meeting.
Planning
The main Blender 3.2 high priority bugs are related to ray-tracing. Brecht is working on solutions but it’s difficult, unclear how much we can fix before the release.
AMD HIP status:
Linux RDNA2 support appears to be stable for the 3.2 release.
Linux RDNA1 support has a critical bug with image textures. This is being investigated, hopefully fixed for 3.2 but uncertain at this point.
Windows and Linux Vega support is aimed at 3.3.
Hardware ray-tracing support is aimed at 3.4 or earlier.
On Windows, the HIP SDK needs to be upgraded for compatibility with AMD drivers. Brecht will do this upgrade for 3.2. Old drivers should also work with this new HIP SDK, however old Blender versions may not work with new AMD drivers.
MNEE: there are some known limitations in the method still, none planned to be fixed for the 3.2 release. As a reminder, MNEE is not a general caustics solution, though some limitations may be solved still.
NanoVDB: Patrick added support for rendering half float and variable precision, which helps significantly reduce volume memory usage. Half float is enabled by default and generally renders the same as full float. Variable precision seems to lose more detail than expected, needs to be investigated why.
Intel OneAPI: work continues to make this ready for integration in an official release. Currently work is ongoing on setting up automated building of the required LLVM forks and other dependencies.
Intel OpenImageDenoise recently gained GPU supported, that should also work on NVIDIA, AMD and Apple devices. Stefan started prototyping an implementation in Cycles. Quality is identical to CPU denoising with improved performance, so this looks very promising.
Principled BSDF: Lukas is investigating an upgrade to the Principled BSDF, adding more features and solving some long standing issues. A task with a plan for this will be created. There are many things to balance: usability, production vs. game engines, compatibility with other apps and file formats. The first step is to replace the multiscatter GGX with a regular GGX that uses albedo scaling for energy conservation, which should be faster and reduce noise.
Practical Info
This is a weekly video chat meeting for planning and discussion of Blender rendering development. Any contributor (developer, UI/UX designer, writer, …) working on rendering in Blender is welcome to join and add proposed items to the agenda.
For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.
So 3.4 is scheduled to release December 7, 2022, 1 year after 3.0 and 2 years after ray tracing on RDNA2 was weeks away. Don’t forget to post when the nightly builds need testing, I wish you better luck this time around.
Currently not planned to be honest, it has several bugs and removing it would simplify the code considerably.
As for clearcoat: Yeah, the new version will scale all components using the same albedo table approach that is used for the multiscattering approximation - so both the main specular lobe and diffuse/subsurface will be scaled by 1-clearcoatAlbedo, and diffuse/subsurface additionally by 1-specularAlbedo.
Great to hear about clearcoat! During refactor do you consider adding ggx/multiscatter ggx info fresnel node: Cycles Requests - #450 by Eneen or maybe even separate clearcoat node with absorption?
The most notable difference is the amount of saturation on con-
ductors, with the reference looking slightly more saturated at high
roughnesses, even with us using Fms of Eq. 15, rather than the more
justified one of Eq. 12, that saturates the result a bit less (Fig. 7 left)
But maybe multi will only disappear from principled but not glossy node?
What I’m trying to say is that conductors and coated dielectrics are not perfect (no spectral rendering), but taking multiscatter away would limit them further. I’m not jewellery guy but having good metals or coated glass for archviz is IHMO common thing.
Hope this combined info is somehow helpful to you.
There’s no news besides what is in the meeting notes.
Also, I assume you are asking about two separate topics? Because there will be no hardware ray-tracing on AMD cards through Metal, it’s unlikely Apple will add such functionality to macOS.
It’s not really possible to accurately represent Fresnel on microfacets as a separate node, since the Fresnel factor depends on the half-vector, which in turn depends on the incoming and outgoing directions. At the time of shader tree evaluation, only the view direction is known. This is fine for smooth materials, but the rougher it gets, the less accurate it gets. You could return the average, but that’s only an approximation of course.
The proper way to handle this is to have closures that include the Fresnel term in their evaluation. This is what the current principled BSDF already does, and the new one will do it as well.
Once that is done, I’ll probably look into implementing some of its parts (e.g. clearcoat and metallic) as separate nodes as well for people who want more control, that way you could then get the accurate effect.
But yeah, the strength of this effect can be surprisingly high, especially for glass - the current Cycles Glass node computes the Fresnel term based on the surface normal and then mixes reflection and refraction lobes. Replacing that with code that first samples the microfacet normal, then evaluates Fresnel based on that and then makes the reflection/refraction decision brings the result way closer to the full multiscattering result, even if the lobes themselves are only single-scattering and there’s no albedo correction.
The option is not going away, only the internal code. The approximation that’s replacing it will still have the same (or a very similar) saturation increase.
