Default scene or…?
Yes, using the default scene.
In my case (3600X / GTX1660) enabling EEVEE-Next takes about 5-6 seconds, but my default scene also has three additional materials.
1 Like
When EEVEE-Next is run for the first time or when bigger features (Shadows/Raytracing) are used for the first time some internal shaders will be rebuild/optimized. When working with daily builds this can be confusing as you’re downloading a new version on a regular basis, which needs to recompile those shaders for that build.
When working with a official release this will only happen once and would not be that noticeable.
11 Likes
Just been making speed comparisons.
On a full scene, with everything from geometry nodes trees and plants, mist, lights (area, sun and spots) complex shaders with several principled shaders mixes (like roads/grass zones) and with the motion blur turn off Eevee-Next is feeling perceptually faster about 20% when navigating on viewport.
Edit:
Observing carefully… at the first moves is actually slower, but then seems to gain speed as we rotate and navigate the viewport. So, I’m not sure anymore about my first claim… it’s not terribly worse, that’s for sure 
Edit2:
I’m having a super weird World shift when changing from Eevee to Eevee-next… like not only the world HDRi shifts position but all the geometry also does 
I can’t replicate it on a clean file, but if I select the objects the outline of them are in the correct place, just when in Eevee-next rendered mode all shifts position. It’s like everything gets 10 meters bellow.
That’s not what i’ve been seeing on nvidia/win64. I looked into the blender startup time not too long ago, a large amount of time (multiple seconds) was spend caching shaders on startup (including things that i guarantee will never use like some of the greasepencil shaders, caching was seemingly hurting startup perf more than it helped), even running the exact same binary over and over i think on average it took about 5 runs before shader compilation was no longer the largest contributor to the startup time. I’m not entirely sure how nvidia manages the shader cache, but it’s definitely not run it once and you’re good.
Edit several days later:
since this post is still getting quite a bit of likes and such, i have rerun the experiment and while the first time start has a significant penalty at ± 5.3 seconds, the second and subsequent runs are down to < 200 ms for all shaders. looks like a recent driver updated may have fixed the odd “you need 5-6 runs before caching works behaviour”
4 Likes
First of all, I really appreciate your hard word for eevee-next! I tried the latest build and got some weird shadow behaviour.
Eevee
Cycles:
5 Likes
Startup as in booting into the default scene?
I’m on Nvidia + Windows too and it boots instantly.
Also, not sure about GP, but shaders in general are never compiled until they’re actually needed.
AFAIK, we can’t control how the driver caching works, but it should be possible to keep our own shader cache. I suggested doing so some time ago, but there are many other higher priority tasks.
@JanErik Open a report, please. Issues - blender - Blender Projects
I’m confused by “Horizon Scanning” pannel.
Is it suppose to be named like that and not “Horizon-Based Indirect Lighting” or “Horizon-Based Global Illumination”?
and should it be placed there and not under raytracing panel?
Cuz it does not work without raytracing panel enabled. (without that parameters does not change anything)
And how to enable only hbao/gtao without lightning part?
2 Likes
The problem here is that shader compilation in Blender takes way too much time. For example, when I open one of my scenes and switch to the EEVEE-Next, it takes more than a minute to compile mere 30-40 simple shaders. For the sake of comparison, UE would compile hundreds of shaders in the same amount of time.
Nope. Usually, I download new build only once a week, yet, Blender randomly recompiles shaders for EEVEE-Next almost every single day for no reason.
3 Likes
Hmmm that is a pitty, but we have no control over shading caches and compile times when using OpenGL (that is an OS/Driver responsibility). Vulkan in the other hand we have control about shading caches and compile times.
Sadly the Vulkan backend cannot handle EEVEE/EEVEE-next yet. Perhaps would also bring us to the same performance as you mention. It is on my task-list and hope to continue on that after EEVEE-Next issues are settled.
13 Likes
Please, please fix the long compilation times. I’m really tired of having to wait up to 2 minutes before I can see my textures. Sometimes I start Cycles preview because it’s just quicker. This and the denoiser not being able to be cancelled are big problems right now.
2 Likes
I see a some of request about splitting the ambient occlusion and the global illumination. It is certainly possible but introduce questions about how to do it in a consistent way. In a raytracer you would disable bounce lighting for a certain type of ray. In EEVEE, the bounce lighting comes from:
- Screen-Space Raytracing
- Horizon-Scan
- Sphere Lightprobes
- Volume Lightprobes
Lightprobes already have the lighting composited with the environment so it is quite difficult to extract what is bounced lighting and what is world lighting.
So the only thing we can do is disable indirect lighting at the Horizon-Scan and Raytracing level.
Disabling it per ray-type is doable and is certainly what one wants (very few people want to have black reflections).
But this pauses a compositing issue with the fallback probes (volume and sphere) that would be always contained bounce lighting. Would this be a acceptable limitation?
Also there is the issue that HorizonScan and SSGI do not currently have a maximum trace distance parameter. So disabling indirect light would make interior scenes way darker and be heavily view dependent. This could be mitigated with a maximum trace distance parameter that would limit the effect of the darkening.
This would definitely break PBR and be an artistical option disabled by default.
9 Likes
Yes the UI of this is going to be reworked.
I’m also opened for a better generic name than “Horizon Scanning”.
The exact technical definition is that it is a low frequency screen space global illumination technique that affects all BSDF if their roughness is higher than the raytracing threshold.
8 Likes
I added a mitigation to this exact issue yesterday. Hopefully, it is good enough for some usecases but will definitely be visible under extreme cases. As stated by Miguel we still want to introduce jittered soft shadows back. But that needs some development time that we might not have for the first release in 4.2.
8 Likes
About the shader compilation time issue:
It is mostly related to the complexity of EEVEE-Next and our source dependency system. Most shader have ~10k lines of code because our shaders gets more verbose (cleaner) code that uses code from bigger shared library files.
The material shaders (now deferred) should already be quite faster to compile in most cases than their EEVEE counterpart, but not as much as I would like (library complexity grew during development and decreased this advantage).
We acknowledge that this is a big issue and have some ideas about improving the system, but this requires resources that we simply don’t have right now for the initial release.
15 Likes
Prefer disabling shadow ray visibility on the object or their material (with the setup mentioned earlier in this thread). This is because it will be compatible with “real” shadow ray-tracing when we implement it. Also you get compatibility with cycles for free.
10 Likes
Hi, I wish to know when eevee equirectangular support will be added? Is there a roadmap for this feature? Thanks.
2 Likes
Try this:
1 Like
but we have no control over shading caches and compile times when using OpenGL (that is an OS/Driver responsibility)
While not at extent of Vulkan/Metal/D3D12, OpenGL does have some control over this.
GL_ARB_get_program_binary allows you to build a compiled shader caching system.
Wrt the “compilation” itself, yeah it’s a bit of a mess. Some software try to mitigate that with various ways, e.g. doing shader compilation on another thread that has another GL context that shares resources with the “main” context. Additionally, do glCompileShader / glLinkProgram but not immediately check the return result – instead, proceed to do “something unrelated” (which might be even compiling/linking other shaders). Some drivers with this pattern actually go and do compilation “in the background” up until you check the result, query resource locations or use the program.
3 Likes