Attribute Statistic Node in Shader Nodes
The Attribute Statisic Node in the shader nodes will actually be helpful in many scenarios. As of now I am kinda using geometry nodes and trying my best to match the nodes. But in a few cases it's just not possible. In those cases I do a lot of guess work and try to emulate the node using my dumb brain.
For example there is a range of values present and I want to use the min and max value in the map range node. Currently I just use the Greater and Less than nodes to kinda find the min and max values. But if the Attribute statisic node were present, I wouldn't have to go about this workaround. Even worse, this workaround is just too impractical for dynamic values. This is just one example. Another very common used one would be the mean output. There are sooooooo many use cases of this node while shading.
4 Comments
TLDR: No, shader nodes don't work like this.
Geometry nodes are evaluated for a finite number of things (vertices, edges, faces, etc.). There's vertex 1. Go do geometry nodes for it. We have 8000 vertices, time to average them. You can easily whip up a correct statistic for them.
Shader nodes are evaluated for wherever the renderer asks for (or, for in-shader stuff, whatever other parameters you ask for, which is even more arbitrary). Although there isn't infinite precision, there might as well be. There is no fragment 1. Shaders end up as pixels in the end, but they're not pixels. They're a mathematical function that gives you some outputs for its parameters (e.g. Fragment [pixel] coordinate, normal). Giving a proper statistic is impossible as it's impossible to enumerate every point in that infinite space (or, even though it's not really infinite, it would probably take you a good number of days to compute). Or, otherwise, rendering would be solved and no one would be buying 4090s. Maths does have tools to start doing this, like integrals to find the total, but god help you teach a computer to find the integrals of arbitrary functions, and especially whenever the user decides they want sin(x^2) or something.
There are naive ways to do it, but they all will have downsides. You can sample a finite number of points. For a 1D thing, this will be pretty good. For a 2D texture, it starts getting meh, and beyond that the performance would be atrocious or you'd have way too massive errors from not enough data. You can render everything once and use what's rendered - which is only feasible with Eevee, and would give you incorrect statistics and be very unstable when you move the camera around.
More complex applications are not really possible and/or give even more headaches. Let's take a practical example: I want statistics for a fresnel node on a normal mapped suzanne while using Cycles, inside the shader with the fresnel to do something else. What should the node even output? The statistics of all rays so far? The statistics of what's rendered on-screen? What if I'm looking at a mirror, or through glass? It's not feasible to give you statistics for all possible rays as that would obliterate performance.
Ok, so from what I am able to understand, this is "sort of-kinda" possible in eevee but absolutely not in cycles, right?
It's not possible in a useable way in either renderer. You can make some very rough approximation that is a statistic of what was rendered in Eevee, and that's it. That's likely not a very good statistic.
Make the attribute in GN first, then save it in named attribute and read it in shader editor.