Added material_overlay property to MeshInstance (gles2 & gles3)

[fbcosentino]

Current problem

Applying overlay materials (such as momentary visual effects) on multi-surface meshes currently requires adding a next pass material to all the surfaces, which might be cumbersome when the material is to be applied to a range of different geometries. E. g. an enemy plays a VFX when receiving a blaster hit, but each enemy type is a different mesh, with different number of surfaces.

This also makes it not very trivial to use AnimationPlayer to control the material. In the mentioned example, controlling the effect via animations require either adding a different AnimationPlayer to each different type of mesh, with manually set animations for each of the surfaces (which means only prepared targets could show the effect), or - if a same AnimationPlayer-based scene is instanced in any of the affected enemies - a script iterating over the surfaces of the mesh assigning the material, and exposing to the AnimationPlayer somehow (e.g. via export var).

The material_override property is not an option as it works replacing the active material for the surfaces, not adding a new pass.

Solution

This commit adds the material_overlay property to GeometryInstance (and therefore MeshInstance), which is a Material affecting all surfaces like material_override does, but rendering as a new pass on top of the active materials, instead of replacing them.

Implemented in rasterizer of both GLES2 and GLES3.

Example

Test model: mesh with 3 surfaces, each with a different material

Test effect added as next pass in first surface - provides a single point of access for an AnimationPlayer but needs scripting to be assigned to other surfaces - or repetition in the animation itself.

Test effect added as material_override - direct interface with single material, but underlying materials are lost

Test effect using material_overlay - effect covers entire model preserving base materials and providing single access for animations

GIF below demonstrates using "Next pass" to stack 3 material effects in material_overlay, all controlled via a single animation in AnimationPlayer. This AnimationPlayer can be saved as branch scene and instanced in any affected MeshInstance during runtime as needed. The only scripting required is assigning the material to material_overlay, which is completely independent from mesh materials or number of surfaces.

Edit:

master counterpart PR now at #53069

[Calinou]

This sounds like a good idea to me. To help get this merged faster, I would recommend opening a proposal that follows the template so we can discuss the feature itself separately from its technical implementation.

Also, we will have to figure out how to implement this in master once we agree on the implementation details.

[sairam4123]

Just tested your PR, everything works good.

Documentation's second paragraph seems to be not aligned properly.

Other than that, the PR is working good.

[Calinou]

Documentation looks good to me.

[fbcosentino]

A check failed due to a blank line and spaces in a comment. Do I need to make another commit or do I just leave it as is?

[Calinou]

A check failed due to a blank line and spaces in a comment. Do I need to make another commit or do I just leave it as is?

You need to remove trailing whitespace and follow clang-format guidelines. You can do so by amending your latest commit (git commit --amend and force-pushing (git push -f). Also, commits should be squashed into a single commit; see PR workflow for instructions.

[fbcosentino]

Done. Please forgive my clumsiness - first time PR'ing here

[clayjohn]

Implementation looks good to me! Reduz and I discussed the proposal over on the godot chat and agreed that the feature is acceptable in theory.

The only outstanding issue before merging is adding this feature to 4.0. We want to avoid adding new features into 3.x that won't be added in 4.0. You mentioned earlier that you are unsure how this works in 4.0. I think it actually works pretty similarly and should not be much more work for you. But if you are having trouble, please reach out to me here or on the godot chat

[akien-mga]

@fbcosentino Would you be available to port this feature to 4.0 in the master branch as requested? Or should another contributor do it?

[fbcosentino]

I will try my best to avoid taking time from other contributors who I know are already busy, but if somebody else would be willing to do it I wouldn't mind at all.

[fbcosentino]

Finally implemented in master - #53069

I'm terribly sorry for the delay on this. Darkness took me, and I strayed out of thought and time.

[sairam4123]

All works, tested on my game now.

[fbcosentino]

Just saw the 3.4 rc 3 announcement, where it is said "With this third Release Candidate, we have frozen feature development and are nearly ready to release the stable version."

So this means this feature is not going?

[Calinou]

Just saw the 3.4 rc 3 announcement, where it is said "With this third Release Candidate, we have frozen feature development and are nearly ready to release the stable version."

So this means this feature is not going?

Indeed, this will have to wait for 3.5 to be merged. It can't be merged in 3.4.1 either given patch releases are now reserved to bug fixes. Sorry for the inconvenience.

[clayjohn]

Can you rebase this on latest 3.x and just confirm that it is still working with all the changes made since?

Once you confirm that it is good to go, we will move forward with merging it. We want to merge feature changes early in the 3.5 release cycle.

[akien-mga]

Can you rebase this on latest 3.x and just confirm that it is still working with all the changes made since?

Bump :)

[fbcosentino]

Rebased.

[akien-mga]

Thanks! And congrats for your first merged Godot contribution 🎉