@akien-mga Force pushed with your suggested changes!

Thanks!

Hi @clayjohn, the CanvasGroup docs state to use this:

shader_type canvas_item;

uniform sampler2D screen_texture : hint_screen_texture, repeat_disable, filter_nearest;

void fragment() {
    vec4 c = textureLod(screen_texture, SCREEN_UV, 0.0);

    if (c.a > 0.0001) {
        c.rgb /= c.a;
    }

    COLOR *= c;
}

But what exactly is this? Why is it exposed to the user? Why not just automate it behind the scenes, bundle it up so that we can simply use texture(TEXTURE, UV); to represent the CanvasGroup?

The most powerful use of CanvasGroup is being able to apply a shader to 100 nodes which have their own individual shaders and materials (Use parent material doesn't work for this since it replaces each node's material/shader). So I'm curious as to why this feels like an afterthought?

But what exactly is this? Why is it exposed to the user? Why not just automate it behind the scenes, bundle it up so that we can simply use texture(TEXTURE, UV); to represent the CanvasGroup?

CanvasGroup does automate this behind the scenes. As the note I added to the docs says, this code is only if you choose to override the built in behaviour and implement your own custom shader. For most users CanvasGroup just works automagically. But power users have the option of completely overriding the built in behaviour if they want.

I think it is important for documentation to document both the advanced use-cases of a feature and the ordinary use case.

Finally, CanvasGrouping can be used by ordinary nodes like Sprite2D. So we can't override the regular TEXTURE built in.

The most powerful use of CanvasGroup is being able to apply a shader to 100 nodes which have their own individual shaders and materials (Use parent material doesn't work for this since it replaces each node's material/shader). So I'm curious as to why this feels like an afterthought?

I'm not sure what you mean.