Add function to update Atlases (such as DecalAtlas) with changes to individual textures.

[ColinSORourke]

This is a feature enhancement for DrawableTextures, based on Rendering Meeting conversations with @QbieShay.

The desired behavior was to use DrawableTextures to animate Decals, however because Decals are read from a Decal Atlas, blits to the DrawableTexture would not update the Atlas unless fully rebuilt. This PR adds new methods, in both rendering servers, to allow redrawing singular textures in the Atlas without a full rebuild. This is currently only invoked by Drawable_Texture_Blit_Rect, but could also be useful for other cases where an Atlas uses a Texture that may have its data changed, such as Texture Update Partial

draw-decal.zip
Attached is a minimal project featuring DrawableTextures being synced to a Decal Atlas - Decal Atlas instantiates new Decals, each of which with their own DrawableTexture being faded by periodic Blit_rect calls.

[AThousandShips]

Suggested change

	ERR_FAIL_COND(!decal_atlas.texture.is_valid());
	ERR_FAIL_COND(decal_atlas.texture.is_null());

[akien-mga]

Just a nitpick on the commit/PR title, it's not clear what "Atlas_Update_Texture" refers to. Identifiers with underscores should be reserved for actual references to code (with backticks), but there's no "Atlas_Update_Texture" code in this PR (there's texture_atlas_update_texture in GLES3 and it's named differently in RD.

So it would be better to use plain English than proto-code for this. See https://github.com/godotengine/godot/blob/master/CONTRIBUTING.md#format-your-commit-messages-with-readability-in-mind for details on how we prefer commit messages to be written.

[coobenguy]

This would also allow for animated light projectors right?

[Calinou]

This would also allow for animated light projectors right?

Projectors use their own atlas, but it works in the same way as decals. I didn't test if projectors work with animated DrawableTextures now, but it should be easy to implement if it doesn't work already with the PR.

[ColinSORourke]

@Calinou @coobenguy I just tested this, and it seems like the case!

I set up a Spotlight3D, and had a GDScript initialize the Light_Projector texture to a new DrawableTexture, and then a timer callback to blit the Light_Projector between two possible textures. It correctly 'animated' the light projector

[mertkasar]

A little test on DrawableTexture as projector... literally... 👀

control-projector-1080.mp4

[Calinou]

I wonder if this could be called in ViewportTexture when it's redrawn. While we want to encourage DrawableTexture when possible as it's less demanding, some use cases are better served by ViewportTexture.

If the Viewport has its update mode set correctly, it should only redraw when needed (or only redraw once), so there shouldn't be a significant performance cost otherwise. It should suppress the need for more demanding get_texture() workarounds, which should overall be a performance win. Implementing this would effectively close #73400.

[TheMagnat]

I wonder if this could be called in ViewportTexture when it's redrawn. While we want to encourage DrawableTexture when possible as it's less demanding, some use cases are better served by ViewportTexture.

If the Viewport has its update mode set correctly, it should only redraw when needed (or only redraw once), so there shouldn't be a significant performance cost otherwise. It should suppress the need for more demanding get_texture() workarounds, which should overall be a performance win.

I've created a PR on the branch from this PR to add this feature : ColinSORourke#1
But I'm not certain on my implementation, this feature require managing proxy texture, update the used variable so that the Viewport get updated on visible update mode. Maybe we should valid this feature directly and add the viewport feature on another PR ?