- Brecht Van Lommel (Blender)
- Kévin Dietrich (Blender)
- William Leeson (Blender)
- Brian Savery (AMD)
- Christophe Hery (Facebook)
- Feng Xie (Facebook)
- Patrick Mours (NVIDIA)
- Juan Gea Rodriguez
- Cycles X merge into master is planned for next week, Monday earliest. In preparation, Brecht has been fixing bugs, updating code documentation and release notes. Artists are welcome to contribute images and videos to improve the release notes.
- Many of the display, tiled rendering and OpenEXR cache file changes landed, but this is still under development by Sergey. In particular, some work is still needed to make this is a full replacement for the old Save Buffers option by making it more memory efficient.
- AMD HIP support will be submitted to code review soon, review will be prioritized by William and Brecht to make the deadline. As mentioned before, the required graphics drivers will not be available at the time this is expected to be merged, so it will not be immediately available for user testing. There is also a bug in ray intersection with instances, it is being investigated.
- The improved PMJ sampling pattern was committed to cycles-x by William. It improves convergence and solves some correlation artifacts when using adaptive sampling, and is close to Sobol quality now. William will update the sampling pattern code documentation for this.
- William is porting the ray-offsetting patch contributed by Ha Hyung-jin to cycles-x and checking how it works on various scenes, and investigating how to improve it. It definitely helps on some scenes but in the current state also causes artifacts on scenes like the barbershop.
- Scrambling distance was contributed as a patch by Mathieu and is under review, as an option in the advanced panel to improve performance when not using adaptive sampling. Juan notes it is also useful for non-photorealistic rendering. It would also be good to make this compatible with the PMJ pattern as soon as possible, so we can make that pattern the default in all cases.
- The sampling UI and defaults were changed. The recommended workflow is now to set a noise threshold (instead of number of samples), and let Cycles adaptively refine the image until the denoiser can eliminate the remaining noise. The default sampling settings and user interface are geared towards this workflow. There was a long discussion regarding the overall vision and trade-offs here. In any case, there is much work to be done still in making sampling more automatic and adaptive.
- Christophe noted the inconsistency between the diffuse and subsurface scattering BSDFs in the Principled BSDF and individual BSDF nodes at grazing angles. It would be good for the individual BSDF nodes to support the same diffuse fresnel term with an option, as found in the principled BSDF. And also that the behavior is strange at roughness zero, which may be possible to fix by changing the BSDF implementation.
- Kévin wrote a draft of the blog post regarding the cooperation with Facebook. Feng and Christophe are reviewing it.
- Multi GPU rendering in Cycles X does not appear to scale well beyond 2 GPUs right now, whereas previously Cycles scaled better up to 8 GPUs. The cause is unclear, Feng and Patrick will investigate it. Brecht and Sergey currently do not have access to such a setup, but may be able to help when there are profiles, backtraces or debug logs to look at. Brecht will list it as a bug to be fixed for the 3.0 release.
Eevee & Viewport
- OpenSubdiv patch is under review. Campbell, Sergey and Clément gave feedback and Kévin updated the patch accordingly. The aim is still for this to make it in time for 3.0, Kévin should poke the reviewers if review is going too slow to make the deadline.
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.
- Google Meet
- Time: Tuesday 5 to 6 PM Amsterdam Time
- Next Meeting: September 28, 2021
That’s some good news for AMD GPU Users.
Any news on MNEE? I thought it was close to review.
I hope the next step amd open RT ray tracing
Please tell me what is mnee
Manifold Next Event Estimation. Brecht replied to me in another thread confirming it’s not going to make it to 3.0.
I made this fully with the Cycles-X builds (to test the speed and the flow originally), on Win 10, 2070 Super. It actually does not render properly with the regular 3.0 Alpha builds, I get large dark blocks across the image.
This whole 1920x1080 composited image (with couple view layers) renders at 2:28 with 256 samples and 0.001 noise threshold which what I used for my test renders and it is pretty good for the workflow in my view. The final render used 2000 samples for the main face.
I used 96 samples with denoise (had quite a bit of fireflies at that rate) while roughing out the look and I think the render time was around 1 min.
Overall this is a complicated scene with a lot of displacements, geometries, detail levels at different frequencies, a bunch of metal and dielectric materials, lots of subsurface calculations and Cycles-X performed very well.
Sinektronaut: The maggot invasion in space
This is genuinely amazing.
Thanks for the image, it looks great. We may be able to use it.
Note that in general for the release notes we are looking for renders that demonstrates a particular new feature. For example showing the new shadow catcher, or a before/after image to show improved denoising quality.
I can do the before and after renders if you think that it is a good idea to provide those with the release notes.
I want to help with some images comparing denoiser.
Blender 2.93 - 128 samples
Blender 3.0 - 128 samples
Blender 2.93 - 64 samples
Blender 3.0 - 64 samples
Is something like this too “simplistic” to be useful?
-Lights visible to camera-
Is it just me, or do the 3.0 renders lose quite a lot of detail ?
Is there a specific feature or improvement that can be demonstrated with this render? It’s not clear to me that a before/after by itself would show a big difference.
That foggy scene looks like a good demonstration for improved volume denoising, we should be able to use that. The kitchen scene doesn’t really show much difference to me.
Taking one of the demo scenes from blender.org and modifying them can be an easy way to get a better looking demo image. A simple object on a plan can also be enough, but I would try to make a more realistic composition and use another mesh, A monkey intersecting a plane is a bit too much programmer art.
Mainly, for this kind of smaller feature I think just 2 images is enough. A 43 second video is too long, and we also try to avoid having the entire Blender UI visible in demo images/videos like this.
The kitchen shows little difference to me. For the foggy scene there is a lot of low frequency noise in the foggy regions that gets eliminated, not sure if that is the detail you are referring to or something else.
The gods rendered really well, I wonder if they are interested in adding to the blender demo library
For denoiser I personally think this comparison to be the strongest:
You are right that this was not a comparative purpose scene. To me, it was mainly an iterative workflow enhancement that came with the improved render speeds and the simplified settings with the noise handling. My main goal was to use Cycles-X for quicker iterations. I felt like Cycles-X viewport updates were less laggy.
Switching between both detail images shows a stark difference especially on surfaces that are obscured by volume, yes -especially prevalent near light sources. Surface detail is lost, specks of rust on the pipes are completely gone, high frequency noise in the concrete texture (overhang right over the passageway) is blurred into a homogeneous surface.
The very dark spots (metal grates at the top, etc) seems to preserve detail better in 3.0 however.
It’s hard to say what the result is supposed to look like without comparing to a converged image without denoising, it can also be that previous some contrast was incorrectly boosted due to the volume not affecting the albedo pass. But yes, in some of the areas that presumably have significant noise, it’s choosing to remove low frequency noise artifacts at the cost of some detail.
I understand that this comparison lacks a ground truth, however it seems reasonably obvious to me that some of the detail in the 2.93-rendered image is not denoising artifact in nature, but texture detail.