Add custom shader support to SpriteBase3D #103274
Open
+148
−40
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes godotengine/godot-proposals#3266
godot-sprite3d-custom-shader-demo.mp4
This PR lets custom shaders (via Material Override) access the sprite texture used by SpriteBase3D. (and its child classes Sprite3D and AnimatedSprite3D by extension)
Validation is implemented to warn the user if a Material Override without the necessary uniforms (namely
uniform sampler2D texture_albedo
anduniform ivec2 albedo_texture_size
) is being used. The "Flags" group properties of SpriteBase3D are also hidden when a Material Override is being used, as those properties are used in the default automatic material generation. (StandardMaterial3D::get_material_for_2d()
) The user can reimplement those features in the custom shader code anyway, so they have been hidden.Side note: This pattern of requiring the shader to have uniforms of specific names and types can be turned into a reusable "shader interface/trait" system if needed. Users could make their own high-level 3D nodes that send data to shaders like SpriteBase3D does. (Maybe a more advanced version of Sprite3D that assigns normal maps and SDF texture maps as uniforms) The main benefit of such a system would be to reduce the amount of builtin shader types, though. (No need to add a new
sprite_3d
shader type) Though this probably would have to be a separate proposal.This PR was originally made to add custom shader support for AnimatedSprite3D in particular, but it is evident that implementing the support for SpriteBase3D makes more sense here.