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

Instancing relatively large Viewport Textures consistently causes frame drops. #4084

Open
KnightNine opened this issue Jul 10, 2020 · 9 comments
Labels
area:class reference Issues and PRs about the class reference, which should be addressed on the Godot engine repository area:manual Issues and PRs related to the Manual/Tutorials section of the documentation enhancement

Comments

@KnightNine
Copy link

Godot version:
v3.2.1

OS/device including version:
win10, gtx 1080, GLES3

Issue description:
Consistent freeze when instancing a scene with a ViewportTexture with a high resolution, despite the scene being preloaded.
I also noticed that during these frame drops, the Profiler registers it as being below the average frame rate during them, as if the profiler itself is also freezing.
This happens for every instance and not just the first instance.
image

Steps to reproduce:
create a scene with a 3d viewport, same as this demo project, set the Viewport size to something like 3500x3500 or higher.

Then create another scene where your previous scene is preloaded into it, and add a control or something to instance the scene into this scene at runtime in order to see the effect it has on framerate.

Minimal reproduction project:
I don't want to spend time on one right now in case this is not an issue but just a known limitation in Godot. So let me know and I will.

@Zireael07
Copy link

Most likely shaders compiling?

@KnightNine
Copy link
Author

@Zireael07 do they have to compile for every instance? There's no way to preload them?

@Zireael07
Copy link

Nope, GLES 2 and 3 don't allow preloading shaders. There are some tricks, @BastiaanOlij I think showcased some, but IIRC they don't work for viewport textures...

@KnightNine
Copy link
Author

Darn, guess this isn't a bug report as much as it is a performance issue, i could try and instance this 3d viewport scene from a thread and just have a delay before the instance appears rather than a stutter if that's possible.

@Calinou
Copy link
Member

Calinou commented Jul 10, 2020

This is a known issue. It makes dynamic resolution unfortunately not viable right now. It might be solvable in Vulkan though: godotengine/godot-proposals#917

@NathanLovato NathanLovato transferred this issue from godotengine/godot Sep 27, 2020
@NathanLovato
Copy link
Contributor

We could consider adding this to about/troubleshooting.

@KnightNine
Copy link
Author

KnightNine commented Sep 27, 2020

It would save me from having to create a 3D sprite based damage popup, like in rpgs, to achieve something as simple as that without stuttering; I would have to create a script that aligns every 3D sprite for each character due to this limitation.

@Calinou
Copy link
Member

Calinou commented Sep 27, 2020

@KnightNine See godotengine/godot-demo-projects#512 for a different approach to 3D text using Control-based nodes and Camera.unproject_position(). You do not need to use Viewports to display text in a 3D world 🙂

@skyace65 skyace65 added area:class reference Issues and PRs about the class reference, which should be addressed on the Godot engine repository area:manual Issues and PRs related to the Manual/Tutorials section of the documentation labels Dec 31, 2022
@Mickeon
Copy link
Contributor

Mickeon commented Sep 18, 2023

Is this still a relevant issue in Godot 4? Would documenting it close this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:class reference Issues and PRs about the class reference, which should be addressed on the Godot engine repository area:manual Issues and PRs related to the Manual/Tutorials section of the documentation enhancement
Projects
None yet
Development

No branches or pull requests

6 participants