Yep both on. Everything is set to the defaults, other than turning raytracing on in eevee-next (but that doesn’t make any difference, its the same on or off).
I can also do a render, it’s the same as the viewport render preview (as it should be, really, unless I have it set up to be different which I don’t).
@fclem Sure thing, I’ll do a report, though I don’t think I have an unusual system. 3090 with a 7950x all running current drivers.
Funnily enough, I found a ‘fix’. If I toggle it back and forth between eevee-next and eevee a couple times, it seems to sort itself out. Weird.
I’ll report it later.
Edit: Oh except it doesn’t -always- fix it. But if I randomly just throw in a sphere light probe, it usually does fix it. Until I toggle off, then it’s broken again permanently unless I delete the probe and re-add it. I’m not even doing anything with the probe, I’m just throwing it in the world somewhere lol. And sometimes it fixes just by deleting the probe and not re-adding it lol.
Very odd.
Same problem,
also changing the world color does not affect the change in color of objects.
Objects flashing a red, blue and green colors
Mine are always just blue (but I don’t change world colour, I just leave that on).
Adding a sphere probe seems to fix it. Have to do it (and then delete it) everytime I toggle eevee-next off and back on.
eevee-next does at least look a lot more… correct though. Not as good as cycles, but way better than eevee.
I have been testing last build and looks pretty damn good to me. The only issue I found concerning is the shader compilation time, but it looks great.
I’m not sure but I think in previous versions, transmission in light “influence” panel made the beam visible inside a refractive material, now it doesn’t but as I said I’m not entirely sure, can someone confirm?
Latest build really damn good. Fastest build to my specs. Problem with Objects flashing is fixed
It’s looking great! I tested it on my heaviest scene and the only issue is a Error about the Shadow buffer being full even at 1Gb… I think that’s why things were turning black at a certain distance.
Why stop at 1Gb!? Why not 4Gb? For persons with 24Gb cards (not my case) the added memory could help to make a more complex scene, no!?
Hi, yesterday we made the choice to make EEVEE-Next default in new scenes. We did this because we need more user testing and because that is the rule for new feature to land before BCon2 (but that’s common to have 1 week of delay). However, this does not mean it is fully polished.
So please report on the bug tracker (using Help > Report a Bug) any inconsistencies, file conversion from EEVEE legacy gone wrong, visual artifact, crashes, workflow issues and so on. We do need your testing to make sure this transition goes as smooth as possible.
Note that there are a few remaining tasks that are still going to land:
This is because our system doesn’t support more than a certain number of shadow pages (4096). And 1Gb is the maximum size our system can support.
However, we are discussing reverting back to a scaling system where the maximum resolution is defined per light instead of always using the maximum resolution by default. This is especially problematic for older files which were not set up with 8K shadow map per lights.
Hi, little question, are the long loading times to initialize eevee (next) going to be tackle by #121471?
The problem im having its long initialization time just with the default cube, in my rig i have nvidia 1070 ubuntu 22.04, eevee legacy loads “normal” as usual.
I confirm that on Linux Mint 21.3 I also experience the same long initialization time.
(post deleted by author)
it depends, it may be a bug or it may be a WIP, thats why im asking.
Do we wait because its WIP? or do we report it because its a bug?
From the initial post, at the top of the page:
“We would like to get some feedback on how it is to use EEVEE-Next.”
Initialization and compilation times are completely worthy to mention in this discussion. One is so slow that one might think the program has just frozen and crashing, the other to the degree that working in Eevee Next gives the artist significant delays in production.
I’m aware both are being looked at closely (which is awesome. and sending everyone incredible hope that the efforts are successful, as i know it’s a challenge.)
Would it be possible that for the launch of EEVEE Next at least some feedback is being given to the user a la Unreal style? like initialisizing (percentage) and compiling shaders (x of n)? at least until improvements are done.
If I got it right, Initializing time is high but it only happens once when you are running EEVEE Next for the first time, so a hint to that would be helpful while it’s happening, but after the initialization, the shaders compile really fast for me, in a scene with raytracing, volumes, area lights and refractive and SSS materials it takes a couple of seconds
About compile times, I’ve been looking into ways to improve them.
We know where the compile times slowdowns are coming from.
It mainly comes for lighting evaluation, so Dithered materials are not affected (they’re actually faster than in EEVEE Legacy).
But Blended materials, materials that use ShaderToRGB, and some engine internal shaders are quite slow to compile.
The problem is that we can’t “fix” the compile times without impacting runtime render performance negatively.
So I’ve been looking into other ways to improve the issue.
For materials, we’ve already shipped a patch that reduces the number of compiled shaders required.
The other option I’ve been looking into is doing multithreaded shader compilation.
There’s an OpenGL extension for that, but the support for it is quite spotty, to say the least.
Here’s a WIP build with multithreaded shader compilation (only for materials).
I would appreciate it if you could give it a try and post your timings (and OS+GPU):
(More details here)
To actually measure the materials compile time difference you should delete your shader cache before opening Blender.
On Windows+Nvidia it’s on %LocalAppData%\NVIDIA\GLCache.
On my machine (Nvidia) it can make material compilation up to twice as fast, but it’s quite dependent on the scene.
However, we’ve seen that in some drivers it can make things slower because multithreaded compilation is not actually supported even if it’s reported as so.
I’ve already had to disable the feature on Mesa drivers for that reason.
There’s another potential route we could take for multithreaded compilation (spawning subprocesses), that at least on simple tests can yield much better results and doesn’t rely on any OpenGL extension.
But that would be way more complex and it may not be too realistic to get it ready for 4.2.
Would it be possible that for the launch of EEVEE Next at least some feedback is being given to the user a la Unreal style? like initialisizing (percentage) and compiling shaders (x of n)? at least until improvements are done.
If I got it right, Initializing time is high but it only happens once when you are running EEVEE Next for the first time
Yes, I have another PR ready that does pretty much that:
And yes, you’re right that this is an issue only the first time you run EEVEE Next for a given Blender version (and the same for materials), since after that the shaders should be cached by the driver.
Is it planned to add fixed HDRI rotation for built-in HDRI’s that is in legacy to EEVEE next as well? This little thing. It’s quite useful
This was removed for now. The old implementation was really not ideal so if we were to port it, we would do it the right way but we need more time than we have for the initial release.
Great, thanks!
Emm…, but how do i get accurate compile timings 
?
I dont see any report in debug logs about shader compilation time and eyebaling with stoper is not accurate 
.
And how to differentiate initial compile from file materials compile.
Hmmm. Could initial shader compilation be done during installation of Blender?
For working with materials, could we have checkbox auto-compile and compile button?
