[3.x] Implement glow map effect

[Chaosus]

• Production edit: 3.x version of [4.0] Add support for glow maps #54574.

This will make it possible even on 3.x:

Adds glow_map and glow_map_strength properties to Environment and a new method called environment_set_glow_map to VisualServer (I did not add additional parameter environment_set_glow because then we need to add a 14 parameter support to D_METHOD and several other internal method for bindings). Yes, I understand that this in incompatible with 4.x, but it's better than expand the existed bindings too much (If not, I will try to fix it) ?

You can test this change with this asset library template:

[Mickeon]

Documentation itself is fine

[lawnjelly]

This looked good to me from preliminary look last week, however we are in feature freeze for 3.6 so will bump to 3.7 (I don't think we have a 3.7 milestone yet but leaving as 3.x).

[KYRYAMBA]

Great! I hope it will be included in 3.6, there is still a lot of time between beta -> RC1-2 -> release.

[lawnjelly]

Would be nice to have a review from @Calinou or @clayjohn before merging, as you guys are familiar with the 4.x PR.

[Calinou]

Tested locally (rebased on top of 3.x 26405db), it works as expected.

Testing project: truck_town_at_night_3.x.zip

[lawnjelly]

@clayjohn

The only thing I'm slightly wary of here is whether the glowmap is having a cost even when not used in the shader. It seems to create the sampler and use an if statement to branch into the texture lookup, even if the texture is not being used.

I don't know whether the shaders on mobile especially will be able to optimize this out. An alternative might be to add a USING_GLOWMAP_DEFINE or some such and only pull in the extra code when in use.

[clayjohn]

@clayjohn

The only thing I'm slightly wary of here is whether the glowmap is having a cost even when not used in the shader. It seems to create the sampler and use an if statement to branch into the texture lookup, even if the texture is not being used.

I don't know whether the shaders on mobile especially will be able to optimize this out. An alternative might be to add a USING_GLOWMAP_DEFINE or some such and only pull in the extra code when in use.

You can see the impact on various Mali devices using the Mali Shader Compiler. I've set up a demo in ShaderPlayground with this code https://shader-playground.timjones.io/8878ac907e47866464793e70c46da22d. You can just delete the lines to see the impact.

On the default Mali G78, this code doesn't harm "best case performance" which measures the case where the branch fails. It does increase typical case texture fetchs by 25% and texture fetches are the bottleneck here, so I would expect some performance impact.

Looking at older devices (Mali G31, T720), the texture fetches are impacted more, however, on such low end devices, we become instruction bound on the arithmetic unit instead. So the impact of the extra texture might be minimal.

[lawnjelly]

We decided that #define may be overkill for now, so will merge, and watch for any performance regressions.

Actually, @Chaosus would you be able to rebase just in case as it's been a few months since this was updated?

[Chaosus]

Actually, @Chaosus would you be able to rebase just in case as it's been a few months since this was updated?

Done

[lawnjelly]

Thanks!