Nope, and I don’t think we will be able to implement it for the prototype. 
The way EEVEE-Next renders shadows makes very hard to implement self-shadow detection, and implementing a new shadow system would be way out of scope.
You can work around the issue using shadow linking, though, but it requires manual setup.
Thank you for getting back to me! Unfortunately, as much as I love the new shadow linking system in Blender, and this amazing prototype (goodness knows it’s been a long time coming) disabling the shadows would actually turn them off for BOTH self and cast shadows. Maybe there will be some luck with this in the future.
I mean you can do something like this:
disable-self-shadows.txt (660.8 KB)
(This is a .blend file, but .blend file uploads are not supported, rename the .txt to .blend to open it)
How did you do this? I get artifacts like Thorn
Edit: I didn’t notice the .Blend thing. Gonna check it out!
@thorn-neverwake and @Patting_Pawz Pragma achieved this result by:
Both of you are probably missing the light linking/shadow linking setup.
It works PERFECTLY! 
Yeah, without the groups, the whole thing falls apart.
@Lateasusual how are you doing it on the backend with Goo?
Aha. You’re right, I didn’t even touch the light linking… Brain dead moment here.
we used a shadow ID map (which is sort of the only way to do it) but that’s not compatible with the virtual shadow mapping eevee next uses, which is why it won’t be supported.
Ok - have revisited the Suzanne “flat normalize” scene this morning, and added a basic constant NPR ramp to it as well.
The view result is what I expect (i guess), but I don’t see the practical use of it. It basically just flattens all the shading, as if i were just using an emission shader for the whole monkey.
As an aside, with regards to the light groupings used - honestly, I cannot wrap my head around this light linking in Eevee Next. I cannot determine what is needed in each shading tab, and what isn’t. The use of collections for light linking in Eevee Next is just completely obtuse. When it works in the example Suzanne scene, I’m just accepting that it works. When I try to recreate this in my own scene, I’ve no idea why something that isn’t working, isn’t. I don’t understand the logic nor expected setup.
I understand this is not Goo Engine, and am trying to approach this renderer using it’s own rules and methods. But the light linking is just … day and night comparison, of “goo: this is easy to understand” and “eevee: I have no idea what I’m supposed to do here.”
The use was showing that self-shadows are not there, you don’t have to do that on your own models.
Light linking in EEVEE works exactly the same as Cycles, this is not a new design.
The idea is that you duplicate each light so you have one for self-shadow enabled objects (group A) and other for self-shadow disabled objects (group B).
So the light for group A lits only A objects, but receives shadows from both A and B.
The light for group B lits only B objects, but receives shadows only from A.
The main limitation is that B objects can’t cast shadows onto each other, so in practice you may need more than 2 groups and 2 light copies, which I agree is a pain to set up.
We discussed how to automate this, but it would still be group-based since having a separate shadow map for each object would be massively costly.
Thank you for your answers, very useful! And those Light loops, if that means colored lights without having to do RGB lights recolored in the shader, that in itself is awesome news! Please don’t stop 
The use was showing that self-shadows are not there, you don’t have to do that on your own models.
Ah, gotcha.
Light linking in EEVEE works exactly the same as Cycles, this is not a new design.
Well, i never use Cycles - so… i suppose I’ll extend my sympathies for Cycles users. But point taken, not the fault of the NPR system.
Also for me the UI/UX implementation of Light Linking feels clunky, but just so you know, it’s in the plans to change the interface (probably make it its own separate editor), and make it easier and more versatile to use.
Hard to tell when precisely it’s gonna be developed though.
Since this probably fits under NPR (since I assume NPR isn’t just anime/cel shading), will the new tools allow for replicating the look of old scanline renderers (like Blender Internal) and overall the look of old specular workflows? Think some kind of way to do Phong/Blinn/CookTorr shading. This sounds like it would fit under the Custom Shading part of the proposal but I’m not sure if that’s gonna be covered by that (since Light Loops don’t seem to be it), plus this should be something supported in Cycles so accurate reflections are possbile (unless eventual EEVEE HW RT allows for that).
Take this with a grain of salt because I’m not very versed on this, but maybe there could be a “BSDF Loop” node in the shader editor, which would basically let you make simple custom BSDF nodes, so you could for example make one that does Phong shading.
This reminded me of another niche style that exists, one where people try to replicate the look of old 3D games. For that some way to do vertex shading could be of use.
There are new features available in the latest build, including:
Also, now you can switch between Material and NPR nodes with Ctrl+Tab.
(There are still many missing/broken things UX-wise, though)
I’ve also started making some basic example node groups:
That’s what Light Loops are for.
You get the light vector so you can roll your own shading models.
The example node groups have one that computes Lambert, Half-Lambert, Phong and Blinn-Phong.
The main catch is that this only works for direct lighting, indirect lighting always comes from the PBR side.
I’d love to get all the NPR features working with Cycles as well, and my initial proposal aimed for that, but it’s not a decision that I can just make on my own.
I’m trying to understand how light loops work- I can see the potential and they seem absolutely amazing, but I’m just not fully grasping the paradigm here. I may have missed it, do you have some examples showing how to use light loops?
Light loops based on this example seem to not take light Radius/Angle into account, I think that should be looked into.
