godotengine / godotengine/godot-docs
Using MSAA with custom render passes
- Dominant language
- reStructuredText
- Stars
- 5.7k
- Forks
- 3.8k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 25
Description
**Your Godot version:**
4.4.1
**Issue description:**
When rendering to a texture using RenderingDevice, as far as I have been able to tell, the ideal way to resolve a multisampled texture is through providing a resolve texture with `RDTextureFormat.is_resolve_buffer` set to `true` when creating the framebuffer. `RenderingdDevice.framebuffer_create()` then automatically sets the texture to be resolved as a resolve attachment in a subpass. From reading the [vulkan documentation](https://docs.vulkan.org/samples/latest/samples/performance/msaa/README.html), it sounds like this method should be much more efficient than `RenderingdDevice.texture_resolve_multisample()` which uses `vkCmdResolveImage()` under the hood.
This behavior of `RenderingdDevice.framebuffer_create()` does not seem to be documented, and as far as I can tell the only way to discover that `RDTextureFormat.is_resolve_buffer` exists is to stumble across it on the `RDTextureFormat` page.
I would create a PR myself except I am not 100% confident in my understanding of how this works.
When using `framebuffer_create_multipass()`, the same setup can be created by adding the index of the resolve texture to `resolve_attachments` in an `RDFramebufferPass` (where the `RDFramebufferPass` is a required input of the function). This usage does not depend on `RDTextureFormat.is_resolve_buffer` being set to `true`. This behavior is slightly more self-explanatory as people will need to look at the documentation for `RDFramebufferPass` anyways during this step, which probably has enough information on it already.
**URL to the documentation page (if already existing):**
https://docs.godotengine.org/en/stable/classes/class_renderingdevice.html
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.