I saw that the light leak through bump/displacement problem was fixed in 3.4.1 https://developer.blender.org/rB3d29bbcc387feea063b48ce747668d1143f312f7
and in my old scenes that were experiencing the issue, they are now fixed.
However, just now I threw some random textures on a simple room and got the same problem with one of them.
Is this the same bug or am I doing something wrong?
Attached file with packed bump map:
displacement light leak problem 2022-12-23.blend (518.0 KB)
Indeed, it looks like the fix focused on use of lamps and is neglecting case of Sun Disc from Sky texture.
If you replace Sun from Sky Texture by a Sun lamp, problem should disappear.
Mesh lights seems to be problematic, too.
Tizian Zeltner is happy to help implement his 2022 SIGGRAPH Paper âPractical Multiple-Scattering Sheen Using Linearly Transformed Cosinesâ into the new principle BSDF V2! 
Did you make a bug report for this?
nope. too lazy.
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.
This two improvement will be much more important than other for ArchViz and Animation artists I guess. Keep going on, guys! ))
These are not the same thing than the Octane texture though. Also Karma still doesnât allow adaptive subdivisions yet
Just a quick note - a new Path Guiding branch build has dropped (cheers Sebastian) which now includes techniques that have glossy guiding as well as diffuse.
Some tests are being posted here - but early results look promising.
edit - the algorithm has been updated to include a user editable glossy threshold, which should improve guiding for glossy materials with lower levels of roughness.
With glossy guiding
Without glossy guiding
(note these are intentionally noisy test renders to help highlight differences, rather than show off the full potential).
Promissing indeed. Just hope GPU implementation will not take too long
For some scenes, CPU with path guiding converges much faster than brute forcing it with GPU - so even without GPU support currently, path guiding is still of benefit.
But I agree - path guiding on GPU will be a welcome addition, although it may take a while because I think the intent is to get various ray types guiding in a stable manner before trying to port it to GPU.
The main problem is, and I guess everyone can easily test that, that even without path guiding GPU is a lot faster. Thanks to modern denoising.
So if Octane and Redshift can do it, its just a matter of time end effort.
On the other side, Cycles development has tons of work to do, but seems to lack man power. I donât know why the BSDF 2 branch isnât progressing since a half year.
YupâŚthatâs the one that Iâm looking forward to the most. When I heard the presentation at the Blender conference I thought that this was on a fast track to be implementedâŚbut unfortunately it doesnât seem to be, nor is it really mentioned in the 2023 roadmap.
IMHO, getting Cycles to produce more realistic renders should be paramount to anything else. The âlookâ of cycles is a massive problem with Blender IMHO.
/hides under desk
PleaseâŚstop. Youâre giving me nightmares. Mental Ray in 3dsMax was the first proper raytracer I ever learned/used. There was such a crazy amount of fiddling and hacking with renderers back then. 
I do not know why people keep bringing up the âCycles lookâ (that is unless they are only using the stock filmic settings with the Principled Node).
What I use instead is my own node groups made using the building blocks along with the new AgX, not using Principled already makes a difference, but my work now has another layer of realism with the new Tonemapping. Also do not forget the BFâs rich tradition of having bad default values (ie. min bounces being 0 when it should be 2 or higher, distance value in the bump node being 1 when it should be 0.1 or lower, default albedo values of 0.8 which is actually considered bright ectâŚ).
Thatâs simply not true in a lot of cases.
Here is an equal time render (1 minute) - GPU vs CPU with path guiding.
Also - the denoising works on CPU too - so whatever advantage denoising gives you is also applicable to path guided CPU renders.
I always use sRGB linear output. I do that since 20 years and see no point yet to switch. ACES is an improvement focusing on red tones, for better skin color grading. Its not really important for 3d and unless you render 8 bit color outputs, there is no need to do that before compositing.
Its partly used in Advertisement so, especially if you need to follow very precise coloring guidelines. And also because the Redshift integration is so smooth and deep, that a lot people simple did that step.
Even the AI-based denoising benefits greatly if it has a more converged image to work with. I am sure that you could potentially get something passable with an insanely undersampled image with the right data in the passes (mainly with Optix as it often guesses higher brightness levels than OIDN), but you will never get the more subtle and/or smaller details that would bring it well above the imagery that made use of photons with final gathering.
Slowly but surely it has gained momentum and is now standardised in programs like Maya/Houdini/Mari/Substance tools. I suppose ACEScg is just the next stage on from sRGB.
I would prefer to see what the render output looks like directly in the buffer. Same applies for authoring textures.
As for âswitching to ACESâ, the way I see it is that there isnât much to switch. The workflow is pretty much the same.
