The expected gains should be measured in seconds. So eyeballing should be enough.
Initial compile time is time to first shaded frame. Material time is time from first shaded frame to end of material compilation
That isn’t possible on all platforms. Also Blender should still be portable as a standalone application.
We would rather not go to for a solution like this which adds burden to the user. But that’s still an option we could choose.
Any one has a clue how to identify the blenders glcache en ubuntu 22?, this is a picture of one of the gl cache folders i found
My biggest problem with EEVEE-Next is its performance. On my PC (3600X/1660GTX) the Next version is 2-3 times slower than the Legacy. In some scenes Next performance is very close to Cycles FGI. On top of that, the viewport performance is also awful. PFR in EEVEE-Legacy never goes bellow 24 fps while EEVEE-Next is 11 fps on average.
I tried EEVEE Next on an old (2018) intel iMac and its completely unusable, you can’t even orbit the default cube but, alas, I guess that’s the price of progress.
@fclem isn’t light influence “transmission” supossed to make the light cone visible inside refractive materials?
It works like that in game engines and working with it is not bothering - At least to me. Its even other way around, when connecting each node freezes work for 0.5<= seconds i prefer to disable auto updates and execute manually compilation.
Other way would be to auto-compile it in background (as sub process?) to not block UI, and swap updated version when done.
I find the in “blended render mode”, shader emission is not lighting the other objects as the “dithered render mode”. Is it a bug or?
I also wonder if “dithered” being a default is really good, etc.
As I can’t do much in the scene until it’s finished compiling shaders, if auto being “off” - I don’t see the benefit.
Okay, I;ve just set screen recording with 2 fps with stoper, like that:
Is it normal that init frame is not consistent? Usually it takes exactly one minute on my system, but sometimes its 50 sec, or 1:30. I guess that’s just blender not refreshing.
Here are results :
Windows10 / RTX2060M / Studio Driver 552.22 (from 16 April 2024)
| Engine | Scene | init² (master¹) | Total (master) | First Frame (Build) | Total (Build) |
|---|---|---|---|---|---|
| EEVEE Legacy | Barbershop | 0:06 | 5:34 | 0:04 | 2:04 |
| EEVEE | Barbershop | 1:00 | 5:04 | 1:00 | 3:00 |
| EEVEE Legacy | 2.93 Dinosaurs | 0:03 | 0:23 | 0:03 | 0:11 |
| EEVEE | 2.93 Dinosaurs | 0:52 | 1:22 | 1:21 | 1:22 |
¹ master is daily build from 09.05
² init is first frame when text “Compiling shaders (x remaining)” appears
Sorry, I don’t know, I just delete the whole thing, but I imagine that might not be an option on Linux where the OS itself may be using OpenGL.
You can also disable the shader cache from the Nvidia panel (I would delete the folder after that too, just in case).
The barbershop timing improvements seem similar to mine.
However, is “init” the same measure as “First Frame”? In that case, the Dinosaurs timing looks weird.
Yes, that’s expected. It’s a known limitation.
Blended materials are rendered after the dithered ones so they can’t affect indirect lighting.
Delete them all. Perfectly safe to do, just means any application with pre-compiled shaders will need to recompile on the next use. If you are unsure, you can always backup the folder contents somewhere else first, but it’s not necessary.
I’ve finished the sun extraction patch. I would like to have feedback on how it feels to have to adjust the size of the sun for each HDRI.
The issue I am facing is that the automatic sun angle detection only works well with HDRIs with really strong lighting (with a real sun), for interiors or night scenes with lots of lights it fails short.
So my first idea was to have a parameter to limit to the sun size to a maximum. But that might be too limiting because one might want to adjust the shadow blurring or the specular shape to something a tiny bit bigger than then automatic size. But having to adjust the size of the sun for every HDRIs is quite cumbersome too, especially if unsure what size it is supposed to have.
So for now, I left the size of the sun to be set directly.
The settings are in the world data panel under Settings.
Here is a link to the build to test Blender Builds - blender.org the download should be available in a few minutes.
As artist we can spend hours moving keyframes and vertices around so I don’t think any of us would mind having more options to adjust parameters in Blender. The main issues artist bring up when talking about functional control is when it’s a critical function or something that is used multiple time during a project getting buried in a pulldown menu netherworld for the sake of minimalist UI. 
it crashes when i enter render or preview view
blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release
Ubuntu 22.04
bpy.context.space_data.context = ‘RENDER’ # Property
bpy.context.scene.render.engine = ‘BLENDER_EEVEE_NEXT’ # Property
bpy.context.space_data.shading.type = ‘RENDERED’ # Property
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0xf3e3c0]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0x847f40]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x72bdcdc42520]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0x56710a1]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0x11ad2f9]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0x11b1799]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0x119a904]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0x113b5f5]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0x113e371]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0x20c05a5]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0x1658dc7]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0xf8a842]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0xf85d10]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0x732044]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x72bdcdc29d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x72bdcdc29e40]
/home/belich/Soft/light extract/blender-4.2.0-alpha+main-PR121455.e5c573c60082-linux.x86_64-release/blender() [0x8439ae]
same here on windows 10
Sorry. I thought it contained a fix I didn’t push. This is the new link (edit: ha, it’s the same one! the old build will be replaced with the working one in a minute) Blender Builds - blender.org
Yes, that’s really bad. No one wants to be constantly wrangling some value parameter every time they switch HDRI map when doing lookdev. It’s really frustrating to constantly keep in mind that your HDRI lighting is wrong unless you manually tweak some parameter, and to know what value you have to tweak it to, you need to switch to cycles and make a reference render. 
Definitely not acceptable solution.
I wanted to try it in the build myself but I just get straight up crash to desktop every single time when I switch to non legacy Eevee and enable rendered viewport mode.
Anyway, can’t you do some preprocessing step, like:
Get all pixels of low mip level HDRI map that have their value above certain treshold (this one can be user defined, value of 10 used on the example).
These pixels will form islands of pixels. Iterate over these islands and assign them score based on their total luminosity, which would be calculated by adding up luminosities of all pixels on a given island. This will mean our island “winners” will not include tiny islands (just a few pixels) with extreme luminance values but also huge islands but with low luminosities. This score will aggregate both total luminosity and total size of each island.
Then keep just largest X amount of them, let’s say 3. This could be also user defined parameter.:
Iterate over these 3 isolated islands, and for each, calculate their bounds (in addition to already calculated total luminosity) on equirectangular sphere. The direction from each bounds center to the scene origin will be the direction of the virtual directional light, the bounding radius will be the size of the directional light sun disk, and the luminosity score will be used to drive the intensity/color of the virtual directional light.
In the end, this may sound more complicated, because one parameter gets replaced by two:
BUT: It will be much more pleasant to use because i don’t constantly need to tinker with size parameter and do Cycles reference render when swapping HDRIs during lookdev. The parameters are kind of more intuitive:
So let’s say with the default parameters of Threshold 10.0 and Max. Virtual Lights 1, I would know that any pixels with brightness above 10 will be used for world light extraction, and that at most 1 virtual world light will be created.
Yes, that is more or less what I have had in mind but that requires way more development time / R&D than we can afford for the first release unfortunately.
The problem is akin to the one of the decimate modifier. Each pixel is a vertex you want to merge with its nearest neighbor and keep the N most brighter pixels that represents the shape the best. But doing this on the GPU for good performance it far from trivial. Even doing it on CPU is far from trivial. Check the performance of the decimate modifier for a 262144 vertex mesh (equivalent to a 512*512 env map) to get the idea. It takes 4 seconds here.
Ideally, we would also make the threshold automatic based on the overall lighting. But that requires to do frequency analysis or histogram building, but in return we would get a relative threshold instead of absolute.
