What’s the shader compilation speed on scene open like for others? I’m getting extremely long times for the past several builds - on first opening a scene, we’re talking around 20 seconds for Blender to go from shaded to rendered view in a scene with 1 light and 3 simple materials.
Area light in eevee next have some bugs like make the probs not working correctly or creating some wrong shadows… This light give some hards problems for devs Stay patient !
Will do.
RE: other Next usability/feature, not related to bug issues - mentioned previously, but just to keep it on the radar:
-
Shadow on/off at the material level - not just object - is of great value in many situations. An easy example is a character model, which has various features joined together as one mesh. One might not want the eyebrow material to cast a shadow, but the full character itself of course should. So, having this functionality from Legacy is very important.
-
The Horizon Scan /Indirect Light feature set: I believe this needs some checkbox, or menu option similar to the Raytracing and Motion Blur tab sections that allows the user to simply turn if OFF, and know that it is disabled.
-
FILM tab: While this is outside the scope of Eevee Next, I’d like to mention that Film/Transparent is not the best language labeling for a user looking for the ability to activate the overall Alpha Channel for the scene. It feels as if the Transparency checkbox was just stuck in that tab at some point in the past because there was no where else to put it. (What is “film”? There’s no film here.) The label of “transparency” also does not simply just identify itself as what it is - scene alpha.
I’m OK with the film tab!
…Although my wife keeps asking me where is the background transparency setting… I have the feeling she as asked me this more than 100 times (some writers exaggeration may be present on this statement…feels it was) over the last 10 years… so definitely is not very memorable no.
Filed…
You can already disable shadows on materials, this was already discussed and implemented. EEVEE next supports Light Paths node, so you can make shadows disappear same way you do it in Cycles. It’s not as easy as one click, but if you make asset it’s one node with added benefit that it gives same result in both engines
If some people really really want it to be button rather than node making it in python is super easy so it will pop-up in first days its released.
I’d completely forgotten about that discussion, Nick - thanks for the reminder on it.
That group does perform the job, yep. (And, you can switch the outputs’ order to just get the shadow) We’ll need to go one-by-one on older scenes and sub it for the old option, but speaking just for myself it won’t be too much of a hassle (as it’s more rarely done than not.)
I would recommend that group be included as a shader group in the default install - perhaps one for no shadow, another for only shadow. Yes, it’s a bit redundant but also user-friendly.
I made a small add-on that adds the Transparent checkbox in the world tab just for this reason.https://pastebin.com/nCankpkS
Would it be possible to add support for older 2GB GPUs to have the same editor responsivity and better rendering times in Eevee Next?
EEVEE-Next recently got a Pixel Size
feature can be used to increase performance while navigating, at the cost of reduced quality when updating the viewport, and reduced quality on some asset types when the viewport stops updated (a limitation at the moment that may be fixed in the future). You may want to checkout this setting to see if it helps you.
As for improving performance in general, developers are still working on it, and there are some features that may be added that could allow for settings tweaks that can improve performance (E.G. Adjusting the shadow resolution scale per light).
I’ve set pixel size to 1x and this makes viewport much smoother. Thanks. But activating the viewport shading still takes a long time. GT 1030 2GB
Something i’d like to quickly mention, since 4.1’s smoothing changes Cycles now renders flat faces as triangles instead of quads/ngons, but EEVEE and Next still render them as before, wouldn’t it be more optimal to have the behaviors match?
100% Agree here. This, apart from the horribly janky shadows (will share in a sec), hehe, which is still being worked on.
It’s horrible not to have individual toggles for SSGI and AO - very different elements that need to be controlled separately. You don’t always want SSGI and you don’t always want AO… And you DEFINITELY do not want them together in every situation, hehe.
I think they are fused because AO and SSGI relate to the same kind of lighting - a new form of global illumination - ie indirect lighting, but the two are VERY different when it comes to putting together a scene.
Ambient Occlusion is the dark you get in corners when bounces face.
SSGI is when you get more light into the scene via bounces through open spaces.
Now, why separate these two?
1 - Ambient Occlusion is not always super obvious and is often relegated to corners - despite limited depth awareness in Eevee. It’s darker and doesn’t stretch as far as your typical SSGI would. Plus, the overscan feature usually covers it and reflections quite well around the edges of the screen.
2 - SSGI is additive and affects every surface around a light opening. The second that light opening passes into the void, you are done. This is not functional. Plus, you don’t always want SSGI, just AO, because (HDRi’s and) you want to darken the corners, you don’t always want to bloom the space and I’m talking for realism here. This is a big problem for lights in spaces as well as reflective light from bright flat surfaces.
I do regular architecture related videos, primarily interiors and I am begging here to separate the two. I want separate controls for AO and for SSGI. These are not the same and should really not be lumped together under one slider… Same area in the UI, absolutely, but no shared sliders… Please…
Reply to Clement - my new-user status…
Thank you very much for responding to it!
Yes, that is correct - it will definitely darken interior spaces. What worked EXTREMELY well in Eevee, is HDRi’s, because they kinda work through walls, so you get a very similar world lighting effect like you did in Blender Render. That as a fallback when disabling SSGI would be fantastic, because in my head and my guess is others’ too, it could optionally combine with AO and/or SSGI, which would look incredible - implementation is up to you guys, but yes, you hit the nail on the head - artistic choice - you would not believe the distances I’ve used for AO just for it to look like what I wanted, LOL.
I’m not sure what you meant by the volume and sphere probes, as I don’t have much experience using those so I can’t really speak to that. If you mean they’ll have a generic fall-back when SSGI is disabled, like the world lighting example, that should be a very fine solution. If anyone else has more experience on this, that would help.
In regards to reflections, the same handling as-is with old Eevee would be fine - reflection plane/probe with SSR? I am not familiar with the technical side on how Eevee next’s is handled. I did notice that even with half-res trace disabled, reflections have always been half-res if not less than (fuzzy in a way) - just a headsup on that.
Shadows and sun lamp are a bit of an issue:
On the floor there are artefacts and the smoothing is inconsistent based on camera distance as well as viewport zoom. This is a very simple solidified and windowed cube scene.
The new shadow system is incredible for being noise based based on the camera - which is awesome, but lots of issues around soft shadows and weird light leaks, like the massive bright blotch on the wall, hehe.
EXCEPTIONAL progress and I’m very excited to use it on projects!
It appears to be tied to Normal Bias, but even on it’s lowest, there’s still a spot on the wall. It might also relate to Pool size, as it creates more or less tiles for the viewport and can disappear based, again on distance.
Sounds like a problem for Cycles users (or a “weird not benefit”? whether intentionally coded that way or not). I certainly do not want Eevee to shade quads/ngons as tris.
“Fixing it” is simple enough (albeit not obvious), you need to use Add Custom Split Normals Data
under the Data tab, or add a Triangulate Modifier and enable Keep Normals
.
Perhaps I’m misunderstanding what you’re getting at. But if not, it sounds as if you were suggesting that Eevee should do what cycles does, which is show triangles instead of quads.
Then you want me to select every object I’ve ever made - or will make - and perform that normal/modifier procedure on everything, so that my shaded view in the future will look like it does today.
Am I understanding that correctly? Not a fan of that idea. At all.
Currently when I see a triangle in any view, I know that it is a triangle that I modeled to be a triangle. I don’t want everything to look like a triangle.
Setting it to 1x shouldn’t improver viewport smoothness. Only lower values like 2x, 4x, and 8x should improve smoothness. If there is a frame rate increase by selecting 1x, then that may need investigating.
By “takes a long time”, what sort of time frame are experiencing. Depending on the time frame this may be abnormal and need investigation, or it may be expected based on the current state of EEVEE-Next.
For reference, on my computer the first time enabling EEVEE-Next takes about 13 seconds (shader compilation). But switching to EEVEE-Next in future tests takes a small fraction of a second. This was just in the default cube scene with a RTX 4090 and Ryzen 9 5950X setup.