Segmented Dimming for Magic Leap

christian_68652_0 · April 9, 2026, 1:58pm

Godot Version

4.5.2

Question

I need to implement Magic Leap segmented dimming, which requires writing to the alpha channel of the final composited framebuffer.

Is there a way in Godot to modify the final frame before display, for example through a render hook or post‑processing stage?
How should this be handled for stereo rendering (left and right eye)?
Can this be achieved using a custom XR extension, or would proper post‑processing require modifications to the Godot rendering backend?

Any pointers appreciated.

normalized · April 9, 2026, 2:07pm

Look at the Compositor.

mux213 · April 9, 2026, 11:50pm

Not possible with the compatibility renderer, but with the mobile renderer you can use compositor effects to add a post process in.
Do note that this disables a number of optimisations so there may be a performance impact on TBDR GPUs. It depends a bit on how well the GPU drivers are able to recognise passes can be merged.

It may be smarter to work the other way around and render your alpha before rendering geometry but i don’t know if that is possible in your use case.

christian_68652_0 · April 13, 2026, 8:46am

Thanks for the hint about the compositor!

I followed the tutorial and the color-changing post-processing effect works fine in Forward+. But when switching to Mobile, the effect no longer works in the editor (Windows 11, v4.5.stable.mono.official [876b29033]). I get this error:

Image needs the TEXTURE_USAGE_STORAGE_BIT usage flag set to be used as uniform.
servers/rendering/rendering_device.cpp:3738 @ uniform_set_create()

I see the same issue when running on Magic Leap 2.

There’s a GitHub issue about this, but I haven’t found a usable workaround.
Do you have any idea what I could try?

christian_68652_0 · April 16, 2026, 12:24pm

With this change, post-processing works when using Mobile.
Replace the parameter can_be_storage by true:

github.com/godotengine/godot

servers/rendering/renderer_rd/storage_rd/render_scene_buffers_rd.cpp

6ce3de25a


      
          
          	vrs_mode = texture_storage->render_target_get_vrs_mode(render_target);
          
          	update_samplers();
          
          	// cleanout any old buffers we had.
          	cleanup();
          
          	// Create our color buffer.
          	const bool resolve_target = msaa_3d != RS::VIEWPORT_MSAA_DISABLED;
          	create_texture(RB_SCOPE_BUFFERS, RB_TEX_COLOR, base_data_format, get_color_usage_bits(resolve_target, false, can_be_storage));
          
          	// TODO: Detect when it is safe to use RD::TEXTURE_USAGE_TRANSIENT_BIT for RB_TEX_DEPTH, RB_TEX_COLOR_MSAA and/or RB_TEX_DEPTH_MSAA.
          	// (it means we cannot sample from it, we cannot copy from/to it) to save VRAM (and maybe performance too).
          
          	// Create our depth buffer.
          	create_texture(RB_SCOPE_BUFFERS, RB_TEX_DEPTH, get_depth_format(resolve_target, false, can_be_storage), get_depth_usage_bits(resolve_target, false, can_be_storage));
          
          	// Create our MSAA buffers.
          	if (msaa_3d == RS::VIEWPORT_MSAA_DISABLED) {
          		texture_samples = RD::TEXTURE_SAMPLES_1;

I am not sure what side effects this change may have.

mux213 · April 19, 2026, 12:51am

Yeah, that’s something that we hasn’t really been addressed yet.

There is a cost to this on actual mobile hardware. There are optimisations on mobile hardware where texture data being written from tile memory to texture memory gets compressed. Which has positive effects on bandwidth and with that performance.
If however a pass after this needs to read from and write to that texture again, it either needs to be decrypted, or disables the optimisation fully.
The latter being the more likely when you mark the texture with TEXTURE_USAGE_STORAGE_BITso obviously we don’t want that set by default..
On PC hardware this doesn’t matter.

system · May 19, 2026, 12:52am

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.