Similar to @josephhansen, I kinda have the same question mark for multi-layer refraction.
I wasn’t able to reproduce what you showed in the screenshot and didn’t understand exactly its use and potential.
Still, very hyped for the advancements of this, still have to test light loops but can’t wait!
Light Loops are just like the Repeat zones, except they’re executed once for each light.
To accumulate the contribution of each light, there’s a default Color zone item where you can add the results.
The example file I linked has a working example, and the first post from this thread has an example image
Color is the light color * strenght/power.Direction is the direction from the surface to the light.Distance is the distance from the surface to the light.Attenuation is the (physically correct) scale of the light intensity at the surface distance.Shadow Mask indicates if the “ray” between the surface and the light is occluded or not.So Color * Attenuation * Shadow Mask gives you the light contribution at the surface without taking the normal into account.
Then it’s up to you to compute the shading using the surface Normal, the light Direction and the View vector.
If that sounds too complex, just use the Shading Models node group from the example file and put a Color Ramp after that.
I think the final node may need separate “simplified” and “advanced” modes, because right now it’s overkill for some things and at the same time it’s also missing outputs required for more advanced use-cases.
This is something that could be handled automatically in the “simplified” mode I mentioned, but for custom shading models this will have to be handled manually on the nodes side. But for that I need to expose the light types and sizes and I thought that would get too overwhelming for the initial version. I still need to figure out a good design for that.
You don’t even need to think about NPR use case.
Right now refraction materials in EEVEE can only refract opaque objects:
Isn’t this a for each loop? If so it might be better if the zones borders are the for each loops color (blueish):
After a very small tinkering session I think I find it confusing that we see the term “color” so much.
We have “color” at the loop input node twice, and once at the output node. Perhaps they should have different variations. For the output node “output color”, “cumulative color” etc. And I’m not sure what the difference on the input nodes two colors are. These should definitely be distinguished I feel.
Really cool what we can do with these already!
I agree it’s confusing.
Note that the bottom “Color” in the input node and the “Color” in the output node are the same “Zone Item”, so they must share the name.
It’s a regular zone item that is added by default for convenience, so you can remove it, rename it, or use it for whatever you want (even if using it for “color accumulation” is the most likely use case).
So I’m not sure if giving it a more specific name makes too much sense.
But yeah, having the name overlap with the light color is pretty bad.
Maybe it could be renamed to something different but equally “generic” like “Zone Color” or just “RGBA”.
The other option would be to rename the color properties to “Light Color” and so on, but that seems to go against the general naming conventions of nodes in Blender.
I can see that the connections on the input and output (currently labeled color) should have the same name, if that’s the intent of the function. And I suppose the label being color is possibly fine.
I think it’s the bottom color on the input node that is troubling me. Whether it breaks blender naming conventions or not, I don’t think 2 pipelines on the same node should have the same name.
Otherwise it’s impossible to discuss in a grammatically accurate way, as now everyone would have to talk about the top color or the bottom color output…
(Fwiw, I think the labels on the main npr node are nicely done)
Another bit of playing around with the curve/edge nodes… a slight bit of irregular lines instead of more blatant noise.
Try to use NPR to project light textures, but unfortunately this obviously has limitations;
Edit: Supplement, might you need something like a light ID? Or maybe it could be done in some other way within the functional framework that we have, I just don’t know
Try to restore the high-precision Tyndall effect of lights in Ev (and goo) in NPR;
During the test, the multiple layers of transparency (or transmission) did not seem to work properly: the slightly farther part was obscured by the transparency in front of it and did not show properly;
Expect normal effects refer to the second video (recorded in goo Engine, but should have nothing to do with the above problem)
To make a transparent effect in NPR, it seems that there is only transmission at present, but why can’t I see the back part specifically
Hi there, thank you very much for the work on this project. I’m new to devtalks, so please bear with me. I’m working exclusively in NPR workflows so I’m very exited how this turns out. Apart from all the cool new things, that are possible I’m most concerend about shadow quality. I recently switched to 4.2 just to find out that it breaks all my shaders and workflow by introducing these ditherlike softshadows with no possiblity for clean edges. I know it has been a topic on here as well, but I would like to know what the current status on this problem is and where I can push for a solution, as there are problems not only with the shadows but also some normal-artifacts, which really destroy any NPR-style that I am interested in. To be more precise than just the shadows are bad:
-the problem arises when trying to achive a cel-shaded look
-It is most noticable on close-ups of heads, hands etc. when the light source is point, spot or area light, less so with sun
Better?
We plan to add light-linking support to the Light Loop node.
We could also add a “UV” or “Local Space” output.
But, ideally, this should be solved with light nodes support.
The NPR Layers just allows rendering different objects in different layers, so refraction works between them (as long as they’re sorted in the correct order).
For a single (self-overlapping) object they don’t change anything.
I your case, it doesn’t look like you really need the refraction, so you could use regular material transparency?
If you want sharp shadows set the Radius/Angle to 0.
The shadow system is the same from EEVEE, so the same limitations still apply.
The artifacts from your image look like shadow terminator issues. A fix is in the roadmap.
Thank you for your answer,
I know, that the NPR-branch is build upon EEVEE, unfortunatley the way shadows are handled right now is not suited for clear shadows. When turning Radius, and Resolution to 0 the blurry shadows are gone, like in my example above, but the shadows themselves get an unacceptable stepped edge. If this remains EEVEE will not be usable for a wide range of NPR use cases including anime that require clean shadows. I see that a solution for this problem is not trivial, but at least I would like to raise awareness for this issue
I had the same issue when trying eevee next for the first time, raising the problem on the thread.
These are the 2 main answers from Clement, main developer of Eevee, you might want to read:
The situation is not ideal, especially since a couple of the solutions he proposed are features yet to be implemented, not exactly clear when.
I can just hope that those, plus the development of this NPR workflow, will solve the issue, but it’s true that as for now clean sharp shadows are harder to obtain, and limited, in current Eevee.
I see. It’s in the works in the roadmap. Wheew. I was getting worried.
