Then the system requirements are wrong. According to them the Intel Mac should be supported. System and drivers are up to date so I have no idea what else might be wrong.
Like Theironlefty said, it looks like shadows are turned off in the world settings. It is disabled by default in older files because previous version did not cast shadows from the environment (and also for performance reasons). But I did overlook that they were shadowed by ambient occlusion.
But if we did disable sun extraction on olderfile we would have regression in shading accuracy from environment. Enabling the shadows by default would create hard shadows that would change the output too much too.
So it is a situation where there is no best option.
But even for non-shadowed lights, shouldnât the screen space reflections occlude also specular highlight component? I believe that interaction is separate from shadow mapping.
It was never the case. I did consider at some point using AO to shadow lights without shadow maps. But thatâs a whole different feature.
Regardless of whether it is a whole different feature or not, the current situation as it stands is that out of the box, Eevee next requires some obscure technical knowledge to get good looking results, especially with legacy (most people wonât realize the problem is lack of shadows enabled in world setting, especially when that setting is not even in the same plane as Eevee settings). That should not be the case. Also, when opening legacy file, the roughness threshold ends up being 0.0 instead of default value of 0.5, further increasing the confusion, as the visual issues it causes get combined with the world light issue.
This learning curve is unnecessary and should be reduced by better out-of-the box UX.
This is clearly a bug which was never reported. So please report it so we can fix it.
The original plan tableâs parallax, will there be further development on it?
In 3.0.1 in World the Nishita Sky Texture would show âNishita not available in Eeveeâ, by 3.4.0 that had changed to âSun disc not available in EEVEEâ. As of 4.2.0 (and 4.3.0 alpha) EEVEE has shadow-casting from HDRIs in World (tried it a few days ago, works nice).
In both 4.2.0 and 4.3.0 alpha the Nishita Sky Texture still shows âSun disc not available in EEVEEâ. I donât use EEVEE (outside of the Viewportâs Material Preview) much anyway, and I know that World HDRIs and Worldâs Nishita Sky Texture arenât the same thing, but these still seem kinda related to me â like if HDRI shadows are now possible, then Nishita Skyâs Sun Disc (and its shadows) should be also.
Is there an EEVEE Render Properties checkbox I should be checking to make this happen, or is this not implemented yet? Should it be?
Sun Disc is displayed above the texture sky gradient. It is a supplementary option, like Cycles point lights visible as light bulbs, when their Camera ray visibility is enabled.
If you use Cycles as render engine, you can see a white disc in Viewport, where should be located the Sun. If you disable the Sun Disc option, this disc disappear but ambient lighting of scene is not changed.
Only illumination and shadowing from Sun are removed.
The inability of EEVEE is not related to the support of a sky texture and its illumination or shadowing.
It is to be unable to handle the two parts of Nishita Sky texture, at same time.
If you need a shadow from Sun in an EEVEE render, you can use a Sun lamp.
The real issue is just that, you can not have the Sun Disc in the sky.
You have to represent it using another way.
Well, thatâs frustrating. Seemed like an easy fix, turns out itâs not. But a minor issue for me, thanks for (however inexplicably) explaining it.
Is this limitation related to the number of BSDFs or something else? If it is, could Next support the sun disc now, given it is not bound by that anymore?
AO is still leaking light in gaps, what bothers me is why settings in release doesnât affect it at all? In beta it was possible to somewhat negate it, also changing âMax Roughnessâ doesnât change as much as before. Also why HDRI shadows was removed?
The issue with the sun disc may be more than a âSomeone forgot to add the sun disc to the shaderâ
The Nishita sky texture is really low resolution (done for performance, and because most of the time it doesnât make a meaningful difference). This means that in the vast majority of scenes that use the Nishita sky, the sun is too small to be captured by that low resolution texture, and as such probably canât be used by EEVEEâs sun extraction feature (because the sun isnât properly visible in the sky texture).
This is a issue that Cycles had to deal with. But sadly most of itâs approach can not be carried over to EEVEE.
Iâve baked a low-ish (1024x512) resolution version of my fave (itâs in my startup.blend) Nishita Sky setup into an hdr (over here if you want it). In 4.2.0 (with Render Properties > Sampling > Shadows checked) EEVEE is showing shadows from the sun disk in my bake in the Environment Texture node just fine (and thanks again). Shadows from the procedural setup (including Nishita Sky) it was baked from? No. No sun disk available (not even a low-res sun-square), no bright spot for the latest EEVEE innovation to make shadows from.
Iâm not technically competent enough to understand the issues, and the explanations so kindly provided arenât helping (yâall tried). What Iâm seeing is that we were told that EEVEE couldnât make shadows from HDRIs, now it can (with a kinda-hacky-but-it-works method that grabs the brightest bit and makes shadows from it). But not from the Sun Disk of the Nishita Sky node, and the reasons given sound remarkably like why EEVEE couldnât make shadows from HDRIs prior to 4.2.0.
As I said uptopic, this a minor issue for me, I donât use EEVEE much (outside of the Viewportâs Material Preview) anyway. Just frustrating, and thatâs my feedback.
I have an issue where EEVEE is not generating shadows from the HDRI images, however in 4.2 beta it worked as expected. Additionally, whenever I switch to material preview Blender gets unresponsive for a while.
Greetings everyone,
I am currently using Blender 4.2 with. In render mode, objects appear completely black, despite having lights in the scene.
Iâve attached a screenshot of the render for reference.
Thanks for your time and assistance.
For me,new shadows mapping (VSM) is far more demanding than old CSM method on the legacyâŚ
Weird shadowing and shadow buffer full error on next made me switch back to legacy⌠Plus,removing contact shadows option is such a huge deal breaker for me. Also,jittered shadows is far slower compared to eevee legacy.
This feels like when 2.80 first release when eevee legacy uses ESM/VSM and it caused a lot of headache. Same thing all over again lol in 4.2
My graphic drivers cannot be updated, so 4.2 EEVVEE renders with giant rectangular spots. Any chance there will be a 4.2 or 4.3 which offers the choice of EEVEE Vintage along with the new EEVEE.
Is there some way to make Light Probe Volumes falloff work the same in Eevee Next/4.2 as they did in Eevee 4.1?
In 4.1, there were two boxes - a inner region of full influence and a outer falloff region - that existed independent of the light probes themselves. With 4.2 it seems that thereâs only a single box (indicating falloff), and full influence only occurs when inside of the light probes themselves.
Example Difference:
(Two overlapping boxes, white world shader, probes baked inside one box)
This makes the light probes almost impossible to use with walls and interiors, since the only way to fully shade the walls is to position the probes directly above the wallsâ surface, but probes located that close to the walls surfaces actually ignore the wall when baking, meaning that thereâs no contribution. (Closest Iâve gotten is baking at a normal interior distance, then manually scaling the probes to fit directly the against walls.)
This has really messed up several interior scenes I was working on, where the lighting was primarily driven by sky light coming in through windows. Previously, the light probes would be influenced by the walls (shading the interior), and in turn the walls would be fully influenced by the probes (avoiding the world lighting).
(Also, the Sphere Light Probes donât help anything, since they use the light probe volumes and world lighting in order to determine object/wall lighting.)