-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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
Optionally render 3D content at scaled resolution #51870
Conversation
3205bfd
to
5335b63
Compare
Owh and just in case someone asks, yes this is on a 165hz monitor with vsync enabled :) |
Looks good to me, some comments about the feature itself that could be addressed in future PRs:
All this is not essential for a MVP, but I'd like to take a look at it eventually. |
Having different scaling options shouldn't be too hard to add, when scaling on different axis the biggest issue is going to be keeping track of the aspect ratio. Instead of a boolean we could make this a dropdown with common options. If I recall correctly we've already created the camera projection matrix prior to hitting this code so it's likely that it would just work. There may be a few places in the source code, especially within shaders, where we're using the resolution of the buffer but that's about it. Personally one of the ideas I've been playing around with is to create the buffer at its full resolution, but restrict rendering to a portion of the buffer. Not 100% sure what the Vulkan equivelant is but in OpenGL using glViewport to only render to a portion of the buffer. This way you could dynamically alter the target size as a response to FPS. This would be a much larger project to implement and get right then I have time to invest right now. I've not looked into any filtering options, I think there is definitely merit in building upon this and improving this with different filtering strategies. Right now I'm just using the existing settings for the tonemap stage and I'm not even sure that does any filtering so it looks blocky. Probably won't be noticeable on a tiny phone screen. Should just be a matter of setting the right filtering settings on the render buffer. Retrofitting this to GLES2 in Godot 3 will be challenging simply because we're rendering everything into one buffer there and we'd almost be rewriting it to the same approach as in the GLES3 renderer. |
I suggest this is made an enum, so we can support common use cases like: SCALE_3D_DISABLE Some phones are too bad that you will really need to scale your 3D to quarter size in some games if you still intend to play them. Having this as an enum should help a lot with having dynamic quality settings. |
@Calinou Scaling non uniform is kind of undesired because post processing will not work properly. |
5335b63
to
4c5320d
Compare
All done, let me know what you think :) |
Is it possible to add a 33% scale option? This would be a good fit for mid-range mobile devices, which would render at 360p or 480p depending on whether they're 1080p or 1440p. |
Sure, should only be a few lines of code extra |
4c5320d
to
c1b67e3
Compare
Ok, added the 33% option. @reduz if you're happy with this it can be merged imho |
c1b67e3
to
82ad3f5
Compare
servers/rendering/rasterizer_dummy.h
Outdated
@@ -186,7 +186,7 @@ class RasterizerSceneDummy : public RendererSceneRender { | |||
void set_debug_draw_mode(RS::ViewportDebugDraw p_debug_draw) override {} | |||
|
|||
RID render_buffers_create() override { return RID(); } | |||
void render_buffers_configure(RID p_render_buffers, RID p_render_target, int p_width, int p_height, RS::ViewportMSAA p_msaa, RS::ViewportScreenSpaceAA p_screen_space_aa, bool p_use_debanding, uint32_t p_view_count) override {} | |||
void render_buffers_configure(RID p_render_buffers, RID p_render_target, int p_width, int p_height, bool p_is_scaled, RS::ViewportMSAA p_msaa, RS::ViewportScreenSpaceAA p_screen_space_aa, bool p_use_debanding, uint32_t p_view_count) override {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of passing p_is_scaled here, just check where relevant if the render target size is different than the render buffer size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That doesn't work because I don't have access to the original size in places like here:
https://github.com/BastiaanOlij/godot/blob/half_resolution_3d/servers/rendering/renderer_rd/forward_mobile/render_forward_mobile.cpp#L513
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or do you mean setting is_scaled
inside of render_buffers_configure
by querying the size of p_render_target
?
82ad3f5
to
2e7e235
Compare
2e7e235
to
64626cc
Compare
@reduz have a look at how I changed this to no longer pass the is_scaled around. I had to add a method to render device to obtain the size of a texture. |
For future reference, it's now possible to set floating-point number as a resolution scale between 25% and 200% thanks to #52215. Values above 100% can be used to perform supersampling. |
This PR adds a tickbox to viewports that instructs Godot to render 3D content of a viewport in a scaled resolution:
There is also a project setting that defines the default behavior (and thus lets you set the main viewport):
Or alternatively you can obviously do this in code:
Note that the settings are ignored in the editor, the editor always renders at normal resolution.