Fix texture checks if stereo rendering is enabled#120876
Conversation
| return pipeline_compilations[p_source]; | ||
| } | ||
|
|
||
| RID SceneShaderForwardClustered::get_default_shader_rd(bool is_multiview) { |
There was a problem hiding this comment.
Note, for both Forward+ and mobile renderers I've added this access method to retrieve the correct version.
I've solved it this way because we have no guarantee multiview is already enabled when default_shader_rd is created. Versions are cached internally so the additional logic shouldn't add any measurable overhead.
This also means that if we run into further configurations where there are changes in the uniform set, we can extent the logic to capture this, but for now I think it's limited to multiview.
|
|
||
| RID sampler = RendererRD::MaterialStorage::get_singleton()->sampler_rd_get_default(RSE::CANVAS_ITEM_TEXTURE_FILTER_NEAREST, RSE::CANVAS_ITEM_TEXTURE_REPEAT_DISABLED); | ||
| cluster_builder->setup(p_render_buffers->get_internal_size(), p_render_buffers->get_max_cluster_elements(), p_render_buffers->get_depth_texture(), sampler, p_render_buffers->get_internal_texture()); | ||
| // Note: Color and depth buffer is only used for our debug mode, we don't support stereo rendering for this. |
There was a problem hiding this comment.
For our cluster debug shader, we don't currently have a stereo debug mode and likely wont ever need it. So this code makes the assumption the debug shader is only ever used in mono rendering.
If this ever turns out to be untrue, we'll need bigger changes, but it would have been broken already before our checks became stricter.
What problem(s) does this PR solve?
Recently a new check was introduced when validating uniform sets in the rendering engine. This caused problems when stereo rendering because we were often checking against the wrong variant of the shader. Vulkan doesn't mind, the uniform set is created correctly and used in the correct situations, but our checks were run against the wrong setup.
This PR fixes the immediate places where this is causing issues on a bare bones project. There may be additional places that needs similar fixes when certain functionality is enabled, but as there isn't a pattern to search on it's like finding a needle in a haystack.
Additional information
This issue only effects the mobile and forward+ renderer.
The problem/fix can be tested without needing XR hardware by using the mobile VR interface demo project and switching the renderer to the appropriate one.