shader node "blur"

Duplicate Another Another Again You see where I'm going with this Please search

A quick edit that I can refer to the next time this gets posted- a blur node is not impossible , but it's not as easy as you think either. If you'd like to know why, keep reading.

A shader is essentially a pixel processor. This is what makes a shader really fast- the GPU can process huge numbers of pixels per frame because each one can be processed independently of one another in its own parallel task. Because of this, cycles and eevee shaders have no concept of what their neighboring pixels are doing when processing a pixel. In order to blur, you need to take the value of pixel A, look at pixel B and C, and then change the value of pixel B to something between A and C.

This is a gross simplification of how gaussian blur works of course, it's not very complicated but it expects that neighboring pixels can be accessed. There's no way to do this on the GPU with parallelization, you're pretty much guaranteed race conditions where one process decides pixel B should be 55, and another decides it should be 62.

So now that you know why it's not as easy as "just make a blur node", I'll explain how it could be done- hopefully the reasons why this is difficult are self-apparent.

Eevee could probably get away with some sort of screen space PCF blur, at the expense of numerous additional draws (this would slow scenes down dramatically , there's a reason why realtime soft shadows are expensive). It would not be accurate, but approximate enough to fall in line with most of eevee's other approximations. That said, current eevee nodes that access screen space data are very specific implementations which likely makes this impossible without redesigning how eevee handles screen space information. IE) when you access AO in eevee, AO data is already in a very specific place in the render buffer. Arbitrary texture you added and want to blur? not so much.

For cycles, a 'blur node' could bake the current texture to a temp file (or RAM), then use the compositor to blur the texture and output the results. Obviously, that's not an easy thing to do because none of the underpinning code to bridge those two aspects of Blender exists, and it would need to be created just to make this one node work- nevermind the potential edge cases and performance issues that it could cause. It's not impossible, just much more difficult than you think.

i see. the classic gausian approach is no good...

treating it like roughness ? with rays ?