Is it me, or does the Denoise node ignore anything rendered with EEVEE Next? It still works fine with renders from Cycles.
I normally use the Denoise node to remove hair noise from EEVEE Legacy, but with Next nothing happens.
No image of Next, because there’s no difference between with or without Denoise
Please report a bug.
And I solved my rendering crashes by activating the “Lock Interface” option… The shots that were persistently crashing, regardless of attempts of changing resolution, motion blur and other options, are now rendering fine
For how long has this been here 
Might has well call it “press this to solve all your render issues” 
Bug reported.
May I ask what the plans are for a Shadow Catcher in EEVEE?
Legacy allowed to create one with ShaderToRGB.
Will Next be without this functionality? Is it planned for the future?
…but, now that the render it finished, it presented shadow errors… Seems there wasn’t enough shadow pool and gave wrong results… so back to Legacy for these two problematic shots.
… but again, this file I’m working on was created by another artist for Cycles, so not the ideal case for EEVEE… it feels a miracle that it works this nice.
Edit:
It’s the world… the world just went crazy from yesterday to today. I was using simple HDRi. I’ve now attempted to have it just in 1K instead of 8K and doesn’t solve it. From the outside the buildings look good, but from the inside is just a huge white circle on the ceiling
I think the shadow catcher trick works for Blended materials, but not the default Dithered?
Assuming it’s the one where you use the output of ShaderToRGB as a mixing factor for a Transparent BSDF.
That’s the one. But the ShaderToRGB in EEVEE Next doesn’t transfer any of the raytraced GI or AO. Which is really needed for a proper Shadowcatcher.
Can’t agree on that. Viewport is smooth, and it doesn’t render that long. Even though it can be sometimes laggy as hell, for which bcon3 is for.
For bugs please make a bug report…
On Linux, with the RTX3060, tested on several types of scenes, it’s rendering more or less in equivalent speed. I would say that, in my current animation, if in Legacy takes 12 seconds per frame on Next is 14 seconds per frame (this at 4K).
In my case I use the Compositor a lot, which in GPU mode is way faster than on Blender 4.1, thus actually speeding up the render if we account for both.
The same scene in Cycles, so that it’s as noise free and sharp, would take no less than 10 minutes per frame.
Viewport playback is similar to Legacy… on the things I do both are, on most of the cases, slow… not real time therefore, it’s great performance compared with Cycles!
Fixed 
thanks to fast fixing
Hi, I’m sorry if this was asked/answered before, it’s been a while since I checked the builds of 4.2.
The first time it has to load all the stuff (objects, materials, compile the shaders, etc)… it’s expected that the first frame takes longer to render yes… and even if I’m talking stupid (I’m only a blender artist) I confirm that the first frame at the first time takes longer to render indeed 
When we switch to Rendered mode, for the first time, that’s the shaders compilation time and was broadly discussed above.
Ok thanks, but then if the first time you switch to rendered mode it has to calculate a bunch of stuff and it may take a while to do it, shouldn’t there be any indication of it on the UI?
Right now it just freezes and it’s easy to think that there’s an error or the program stopped working…
Like the good old Playstation and Sega Saturn “now loading” screens I personally would love that as I’m a sucker for classic games… but if you open Blender by terminal you’ll see some info on it.
I tried to edit the comment but failed.
So in this zone it could actually work.
It’s optional info anyway, so who wanted it on would see something like this:
Or actually on the already existing progress bars for rendering and baking the light… yeah, probably better there.
This sounds like it would be a good option, it’s visible enough so it catches the eye of the user and being a progress bar it would clearly show what’s being done under the hood
My feeling is that only to implement such thing would take someone a full month of work
It definitely needs something to indicate that the software has not died.
Even without a progress indicator, I’ve noticed that if I click too much in the window while it’s compiling, the software application menu bar flashes up “Not Responding” - which, normally does indicate a crash has occurred.
But if you wait another 30 seconds to a minute for it to finish, eventually the alerts goes away and you can go back to working.
I saw this in the last UI meeting under Design and Discussion: #111096 - UI: Indeterminate Progress Indicators - blender - Blender Projects
Could be a contender
