Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup and improve sky render #70253

Merged
merged 1 commit into from Dec 23, 2022

Conversation

BastiaanOlij
Copy link
Contributor

@BastiaanOlij BastiaanOlij commented Dec 18, 2022

This PR fixes a number of issues with the sky rendering and moves to some of the newer abilities we added:

  • Renames a few ambiguous method names to make it easier to debug code.
  • Unifies the two implementations of draw (now draw_sky) so we only have one implementation to manage.
  • Moves updating half and quarter buffers to before we start our opaque render (this was already done in the mobile renderer, now clustered renderer does the same).
  • Now uses our new render buffers implementation to manage the half and quarter buffers.
  • Using half and quarter buffers now also works in stereoscopic rendering
  • Uses full unprojection and eye offset adjustment when rendering in multiview, due to us embedding the eye offset (both rotational and positional) into the projection matrix the short hand unprojection method fails and resulted in minor discomfort on Index headsets, and a highly noticeable wobbling effect of the sky when looking around on an Meta Quest.
  • Reflection probe now uses RenderSceneBuffersRD to handle helper buffers. This can be further improved by moving the logic for creating all buffers used here. This would further clean up code currently duplicated between our reflection probe logic and SkyRD::update_radiance_buffers

Still todo:

  • Look into using the Z buffer for fog in stereoscopic view, we may need to add our eye_offset to this

Bugsquad edit:

ERR_FAIL_COND(p_render_buffers.is_null());

// make sure we support our view count
ERR_FAIL_COND(p_view_count == 0);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should actually return a true/false from setup_sky, then we can do our checks in one place and prevent the rest from running on failure. Right now it is possibly we run other stages of sky rendering if setup fails.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats a good idea, we could likely set draw_sky to false if setup_sky fails which would avoid the other operations. Thats something for another PR though as we would need to think about what kind of fallback information we would need to provide in that case (clear color etc.).

@BastiaanOlij
Copy link
Contributor Author

  • Fix sky orientation not being applied when rendering radiance buffers

This turns out not to be needed, updating radiance buffers for Sky is the exception where we do not pre-apply the sky orientation, instead the sky-orientation is applied when the radiance is read in the scene shader. This prevents the need for costly updating of the radiance map just because the sky orientation changes.

@BastiaanOlij
Copy link
Contributor Author

The big change in this new commit is using render buffers for reflection probes. This way there is no need for duplicating logic in Sky to handle buffers differently between scene rendering and reflection probe rendering.

There is a good argument for embedding the full reflection probe atlas logic into render buffers as a lot of code is duplicated for this in Sky to make update_radiance_buffers work and it would allow us to further cleanup our render logic as it can now check at the start whether render buffers are supplied and just roll with it. That however is for a future PR I think.

I'm putting this ready for review, I still need to check if the Z-buffer in stereoscopic is working as expected but that is not critical to what this PR is about and if it is broken, it was already broken.

@BastiaanOlij BastiaanOlij marked this pull request as ready for review December 21, 2022 01:54
@BastiaanOlij BastiaanOlij requested a review from a team as a code owner December 21, 2022 01:54
Copy link
Member

@clayjohn clayjohn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some initial comments

servers/rendering/renderer_rd/environment/sky.cpp Outdated Show resolved Hide resolved
}
}
uniforms.push_back(u);
}

texture_uniform_sets[p_version] = RD::get_singleton()->uniform_set_create(uniforms, p_default_shader_rd, SKY_SET_TEXTURES);
return texture_uniform_sets[p_version];
return RD::get_singleton()->uniform_set_create(uniforms, p_default_shader_rd, SKY_SET_TEXTURES);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we no longer caching the uniform sets? Since we aren't using the uniform set cache here we will end up producing a new uniform set each time this is called

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How did I end up with that, it's supposed to be calling the framebuffer cache, I'll fix it up

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok should be correct now.

@BastiaanOlij
Copy link
Contributor Author

No, the atlas should manage freeing the textures and framebuffers. It allocates them all at program start and then frees them all at the end. This is just for other resources taking ownership of a single layer of the texture array.

Hmm, that makes sense though I don't think they are freed at the end, I could be missing the code somewhere but it looks like they are only freed if the atlas size changes?

@clayjohn
Copy link
Member

No, the atlas should manage freeing the textures and framebuffers. It allocates them all at program start and then frees them all at the end. This is just for other resources taking ownership of a single layer of the texture array.

Hmm, that makes sense though I don't think they are freed at the end, I could be missing the code somewhere but it looks like they are only freed if the atlas size changes?

At the end the atlas size is set to 0 to free it

@BastiaanOlij
Copy link
Contributor Author

At the end the atlas size is set to 0 to free it

Mixed up sky and reflection probe, shows even more than it makes sense to move this into our buffers object.
Anyway found it in LightStorage::reflection_atlas_free, indeed calls reflection_atlas_set_size to set it to 0 first.

Copy link
Member

@clayjohn clayjohn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I think your remaining ideas would be good to do in future PRs. This already is getting quite large

@akien-mga akien-mga merged commit f064898 into godotengine:master Dec 23, 2022
@akien-mga
Copy link
Member

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

VR XR PanoramaSkyMaterial rendering problem
3 participants