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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a true "Once" ReflectionProbe update mode, rename current "Once" to "When Moved" #2934

Open
Tracked by #66628
Calinou opened this issue Jun 28, 2021 · 3 comments

Comments

@Calinou
Copy link
Member

Calinou commented Jun 28, 2021

See also #2784.

Describe the project you are working on

The Godot editor 馃檪

Describe the problem or limitation you are having in your project

ReflectionProbes can currently be told to update only when they move using the default Once update mode, but there is no way to tell them to never update once they've been generated.

On low-end platforms, the mere act of updating a reflection probe is expensive, so it may be desired to never update a reflection probe even if its parent moves.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Having a way to make reflection probes truly update only once would help improve performance on low-end platforms, while still keeping acceptable visuals.

In my experience, having an old/inaccurate probe is often better than no reflection probe at all. It provides better specular occlusion in reflections since the sky won't shine through reflections.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

  • Rename the current Once update move to When Moved to better reflect is behavior. It will remain the default mode.
  • Add a new Once update move that only updates when one of the ReflectionProbe's parameters is changed (such as extents). The probe will not update when its transform changes (e.g. by moving the node itself or its parent).

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, as this is handled by the renderer itself.

Is there a reason why this should be core and not an add-on in the asset library?

See above.

@clayjohn
Copy link
Member

When would you want to move a ReflectionProbe but not have it update?

And alternatively, why would you want to update when extents are changed but not when the probe is moved? To me it seems inconsistent to update when the extents are changed, but not the position.

@Calinou
Copy link
Member Author

Calinou commented Jun 29, 2021

When would you want to move a ReflectionProbe but not have it update?

This is for low-end configurations, so that we can avoid spending any frame budget in updating reflection probes. While probes placed in a level generally have no reason to move, probes that are parented to a dynamic object will definitely be moving at some point.

And alternatively, why would you want to update when extents are changed but not when the probe is moved? To me it seems inconsistent to update when the extents are changed, but not the position.

Changing a probe's extents is a conscious decision. It doesn't happen just because you moved one of the ReflectionProbe's parents. In contrast, changing a probe's position will happen whenever one of its parents moves. When you have a dynamic object such as a car with a reflection probe, it will move constantly, which means its reflection probe child will constantly queue for updates. This means it will take away valuable GPU time from the main viewport's frame budget. This is fine on decent dedicated GPUs, but not really on integrated graphics.

@VantaGhost
Copy link

Reflection probes really need a way to manually update them, I have a project where large parts of the level are constantly moving, but the contents of the probes don't change enough to warrant re-render. This just causes the "once" mode to update constantly. I know there's an argument against having baked probes for Godot 4, but I'm quite surprised there isn't at least a manual update mode.

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

No branches or pull requests

3 participants