Some games need to build an image while they run. A minimap that fills in as you explore. Fog of war that you erase by walking through it. A painting tool. Bullet scorch marks on a wall. The common thread is the same: draw onto a texture at runtime, then show it.
In older Godot, the standard trick was a SubViewport. You'd render into an off-screen viewport, grab its texture, and display that. It worked, but it was a lot of ceremony for "put a circle here." Godot 4.7 adds DrawableTexture to cut out the middle step.
The old way, so you can see the gap
Here's the shape of the SubViewport approach, roughly:
# Set up a SubViewport, draw into it with a Node2D child,# then read SubViewport.get_texture() and assign it somewhere.@onready var viewport: SubViewport = $SubViewportfunc _ready() -> void: # configure size, render mode, clear behavior... $Sprite2D.texture = viewport.get_texture()It's not wrong. But you're spinning up a whole rendering context and a node hierarchy just to get a surface you can paint on. For anything beyond a one-off, it adds up.
What DrawableTexture changes
DrawableTexture gives you a texture you can draw onto directly, without standing up a viewport to do it. You make one, draw to it, and use it anywhere a texture goes: a Sprite2D, a TextureRect, a material parameter. The point of the node is to take the technical noise out of the way so you can just do the thing.
Because the exact method names are brand new in 4.7, check the in-editor class reference for the precise calls (hover any class name in the script editor and press the help shortcut). What matters for deciding whether to use it is the shape: create the texture, draw, display, no viewport in the middle.
What it's good for
This is one of those features that's niche until the day you need it, and then it's exactly the thing. The real use cases:
- Minimaps and discovered maps. Paint explored areas onto the texture as the player moves.
- Fog of war. Start opaque, erase a soft circle around the player each frame.
- Paint and decals. Player-drawn signs, splatter, scorch marks, footprints in snow.
- In-game editors. Anything where the player builds an image: a character tattoo, a banner, a tile they stamp.
- Procedural detail. Generate a noise or gradient texture once at load instead of shipping the file.
When to reach for something else
If your "drawing" is really a shader effect (a swirling distortion, an animated gradient, a dissolve), that belongs in a shader, not a drawn texture. DrawableTexture is for cases where you're genuinely accumulating marks over time or responding to gameplay, where a shader would have to track too much state. Rule of thumb: if the result depends on a history of player actions, draw it. If it's a function of time and position, shade it.
The bigger picture
DrawableTexture is a small quality-of-life win on its own, but it's part of a pattern in Godot 4.7 of taking jobs that needed an awkward workaround and giving them a clean front door. The VirtualJoystick node does the same for mobile input. For the whole list of what shipped, see Godot 4.7: Everything New.
And if you're newer to Godot, the thing that unlocks features like this isn't the feature itself, it's being comfortable wiring systems together. That's what our free Inventory System quest builds: the habit of connecting data, logic, and display into one working whole.
FAQ
What is DrawableTexture in Godot 4.7?
It's a new texture type you can draw onto directly at runtime, without setting up a SubViewport to render into first. You create it, draw to it, and use it anywhere a normal texture works.
What was the old way to draw to a texture in Godot?
You rendered into a SubViewport with a Node2D drawing inside it, then read SubViewport.get_texture() and displayed that. It worked but added a lot of setup for simple cases, which is exactly what DrawableTexture streamlines.
When should I use a shader instead of DrawableTexture?
Use a shader when the visual is a function of time and position, like a moving gradient or a dissolve effect. Use DrawableTexture when you're accumulating marks based on gameplay over time, like fog of war or player painting, where a shader would have to track too much state.