It appears (based on discussions in various places), that shadows in EeveeNext are no longer supported at the material level - only at the object level.
If so, this removes our ability to control shadowing in particular situations, such as when objects are used in a geometry node with multiple materials. Example in Eevee (the successful goal):
Now the instances with the green material is casting a shadow, which is not wanted.
This problem would also be present if the cross objects were parametrically created within the node, and assigned the green material - so, it is not just a matter of the instanced object cast/dont cast a shadow. That would not solve the problem.
If there’s a button/feature that I’ve not found, or there’s an existing alternative workflow that makes it correctly work in Eevee Next, please do let me know.
One of the most common situations I need to disable shadows by materials is on tree leafs, grass and other vegetations… specially grass can become extremely heavy. I think it can still be made by Object… but by material is a cool feature I often use.
Is this thread still being reviewed by developers? There hasn’t been a reply by a developer in weeks, none of the linked issues have had any commits made, and none of the recent Eevee/Viewport meeting notes have mentioned any of these issues (or really much at all, the last couple months of notes have been extremely sparse on Eevee Next notes). If feedback is no longer wanted, I think this thread should be closed. If feedback is wanted, why is it no longer addressed?
Vegetation was another common use that I thought of. As well as - suppose, a character that’s all joined together as a single object and has multiple materials assigned. You want the body to cast a shadow, but not necessarily the eyebrows.
It’s great to be able to control shadows at the object level, this is something I’ve missed in Blender after using other software. But that cannot be a replacement for material level control.
Thanks everyone for the feedback. I have been less available for personal reasons. We are still working on the last bits of core changes before looking more into bugs and workflow issues. That said the feedback allows us to discuss the problems we need to focus on.
Yes we are aware of many issues with shadows and that makes up many of the remaining tasks.
As for the replacement of material level shadow toggle, as stated in the related task, it is to make it future proof and easier to integrate with ray-traced shadows and make it closer to what cycles does. The way to disable shadows per material is to do it like cycles does. You mix a transparency node with a is_shadow ray visibility and it should work in both Cycles and EEVEE. We will optimize this simple case so that it has no impact on performance.
I never use cycles, so am not familiar with how its users do things. This appears to hide the material, not the shadows it’s casting - are my nodes incorrect?
You can use that node group to separate object and shadow. It works in Cycles, and looks like it will work in Eevee-next too once shadow ray is there. Weirdly enough reflection ray works, so you can output only shadow.
I love the new Eevee Renderer But i think shadows has a disappearing issue. Parts of the shadow map disappear when moving the camera around. This is a render vs viewport comparison i noticed this happened for the first time when i switched my web shader from Dethered to Blended Rendering method. And it presists now
Bug with ssgi eevee
Blender: blender-4.1.0-alpha+main.8933284518a2-windows.amd64-release
Strange behavior with ssgi Imgur: The magic of the Internet - screenshots
Eevee-next have some bugs like the Surfels density are fully borken…Normally the surfels give not a result like fully white like in my screenshot and the surfels do normally been propaged like the tea pot… ANd isn’t the case in eevee-next… The surfels density and the GI are like broken… If the surfels density not works you can’t bake normally the Gloab Illumination and this is the case actually even if you bake something and disable the raytracing the result are closely the same … and actually give wrong result… or broken result due to the bad surfels density computed in more area and some area aren’t computed like everywhere when you don’t have the spot (Surfels)
To continue the conversation from Gitea:
I think it would be preferable to have the diffuse ref ball (aka grey ball) albedo set to 0.18 as it is the standard mid grey value used in every vfx studio.
Additionally, it would be beneficial to include a parameter that allows for a custom value to accommodate various use cases.
PS: “Reference Balls” or “Ref Balls” would be a more accurate name than HDRI preview.
Hi, can this issue (EEVEE Next crash if there’s VDB/geometry nodes volume) get some attention? This seems like a recent regression and makes testing volume rendering impossible.
After testing, the ShaderToRGBA was kind-of working as expected. There was a bug that I fixed, but the main issue that most of you encountered is that using ShaderToRGBA on Materials with Dithered render method was not planned in the design. Previously, I was expecting to promote such materials to the Blended render method. But with many of the parameter changes, this didn’t work anymore. But most importantly, this behavior would be quite weird from a UX point of view, with materials suddenly disappearing from reflections and render pass support if one happened to add a ShaderToRGBA node.
So long story short, I made it so that ShaderToRGBA is also supported in Dithered mode. The only downside is that the Material will loose some texture slots but still less than if we did the promotion.
So if everything works, any old material using ShaderToRGBA from Legacy EEVEE should work with EEVEE-Next.
EDIT: Apparently there might also be some huge performance penalty which I will try to mitigate.
This is definetely worthy work around. Most of my EEVEE work has been stylic nowadays, and I know many people use Blender for the cartoon style rendering which heavily relies on the ShaderToRGBA node. So thanks for making it work.
due to the bad surfels density computed in more area and some area aren’t computed like everywhere when you don’t have the spot (Surfels)
,