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

Split rendering driver project setting into rendering_method and rendering/*/driver #65541

Merged
merged 1 commit into from
Sep 20, 2022

Conversation

clayjohn
Copy link
Member

@clayjohn clayjohn commented Sep 8, 2022

Closes: godotengine/godot-proposals#4261

This also exposes OpenGL to the project creation menu and re-exposes the renderer switch button in the top right hand corner of the editor.

Things to consider during review:

  1. Organization of the project settings. I organized the project settings as suggested in Change the naming of rendering methods and drivers godot-proposals#4261, but it feels a little awkward.
  2. Using enums instead of strings for renderer name and rendering driver. In 3.x we had a VideoDriver enum which we used throughout the engine instead of exposing strings directly. I think we should consider having a RenderingDriver enum and a RendererName enum which we pass around to avoid doing risky string operations all over the engine.

I blindly made some changes to the iOS and Android platforms, would be nice if someone from each team can confirm that the changes look okay.

Screenshots of new project settings:

Screenshot from 2022-09-12 14-13-11

when using gl_compatibility
Screenshot from 2022-09-12 14-13-05

when using rendering device based renderers
Screenshot from 2022-09-12 14-12-57

@Geometror
Copy link
Member

Great work! However, I wonder if it's worth it to reintroduce the the renderer switch button in the menu bar. This is something which will be changed very rarely during development for that it takes quite some space.

@clayjohn
Copy link
Member Author

clayjohn commented Sep 8, 2022

Great work! However, I wonder if it's worth it to reintroduce the the renderer switch button in the menu bar. This is something which will be changed very rarely during development for that it takes quite some space.

I was thinking the same thing. Especially since the new renderer names are much longer than GLES3/GLES2 (as they were in 3.x). I was thinking I would enable it here and then let the UI/UX people fix/remove it as they see fit.

@aaronfranke
Copy link
Member

aaronfranke commented Sep 8, 2022

Why hide the rendering API from the user? Why is GLES3 just called "Compatibility"? I think it would make sense to let users know that it's GLES3. Same for the Vulkan ones, I don't see a reason to hide that it's Vulkan.

@HeadClot
Copy link

HeadClot commented Sep 8, 2022

Why hide the rendering API from the user? Why is GLES3 just called "Compatibility"? I think it would make sense to let users know that it's GLES3. Same for the Vulkan ones, I don't see a reason to hide that it's Vulkan.

I am with aaronfranke on this. I think that hiding the api name from user will lead to confusion. At least put the API in question in the bullet points below clustered, mobile, and Compatibility. My 2 cents.

@Calinou
Copy link
Member

Calinou commented Sep 9, 2022

Why hide the rendering API from the user? Why is GLES3 just called "Compatibility"? I think it would make sense to let users know that it's GLES3. Same for the Vulkan ones, I don't see a reason to hide that it's Vulkan.

In 4.0, the aim is to put less emphasis on the rendering driver (Vulkan, Direct3D, …) and more emphasis on the rendering backend, which is ultimately what matters more from a feature perspective. Different drivers can be used for a same rendering backend.

The Clustered and Mobile backends will be usable both with Vulkan and Direct3D 12 depending on the target hardware and user preference1. The Compatibility backend will be usable both with OpenGL directly and with ANGLE (for GPUs where OpenGL support is problematic).

At the end of the day, what matters the most is which features are supported by the rendering backend you're using. This is what will potentially limit what you can do in your project, along with various performance and usability caveats. I'd say that in 2022, knowing which graphics API is used behind the scenes is an implementation detail. It will still be printed on startup (and can be shown in the About dialog), but I think this is a sensible move overall.

Footnotes

  1. As I understand it, Vulkan will remain the defaulton Windows, but there will be a project setting to use Direct3D 12 on Windows instead. This would allow you to benefit from windowed gaming optimizations and Auto HDR on Windows 11.

@aaronfranke
Copy link
Member

@Calinou I disagree, it's extremely relevant, not an implementation detail.

  • Graphics APIs are something that every game developer has some knowledge about, and even many gamers know about the existence of Vulkan, OpenGL, and DirectX.

  • The choice of graphics API is directly related to the hardware it can run on. If somebody knows what specific devices they want to support, they can look up which APIs those devices support.

@m4gr3d
Copy link
Contributor

m4gr3d commented Sep 9, 2022

I blindly made some changes to the iOS and Android platforms, would be nice if someone from each team can confirm that the changes look okay.

@clayjohn The Android changes looks good.

@clayjohn
Copy link
Member Author

clayjohn commented Sep 9, 2022

Why hide the rendering API from the user? Why is GLES3 just called "Compatibility"? I think it would make sense to let users know that it's GLES3. Same for the Vulkan ones, I don't see a reason to hide that it's Vulkan.

Its not hidden. OpenGL3 is the driver, not the renderer. The choice of driver is still presented to the user. On top of that, Users have never been able to explicitly set the Rendering API. The GLES3 driver mostly confirmed to OpenGL ES 3.0 like the name implies, but on web it is limited to the set of features in the WebGL specification and on Desktop it is limited by OpenGL 3.3. This PR lets us actually expose the selection of rendering API to the user.

_Edit: and that's without mentioning the fact that the GLES3 renderer in Godot 3.x relied on extensions which were not part of basic OpenGL 3,3 / OpenGL 3.0 / WebGL2. So it couldn't run on many devices that advertised OpenGL ES 3.0 support. Again, this PR makes the situation better in that regard, not worse. _

@BastiaanOlij
Copy link
Contributor

Sorry @clayjohn , bit late to the discussion and about to potentially throw a monkey wrench into it :)

Looking to the (near) future and the wish to make the engine more extendable with more implementations, either full renderers like the GLES3 one (possibly a raytracing backend that was discussed), different drivers such as our DirectX backend that works with the RD renderer as a replacement/alternative to Vulkan, or additional RD renderers such as the planned deferred renderer, having these selections hardcoded the way that we do will become a nightmare.

I wonder if we need some way to register the available options and make the selection on the projection creation window and dropdown selection more generic?

@YuriSizov
Copy link
Contributor

I don't see harm in printing the supported driver/API in the hint text for each option. That's definitely not something that would stand in the way of this PR, just a bit about how we present the information to the user.

Options and how they separate target platforms make sense to me. The names may need to be bikeshed, but it's not too critical.

@clayjohn
Copy link
Member Author

clayjohn commented Sep 9, 2022

Notes from September 9th meeting:
1. Change compatibility to gl_compatibility
2. Have two codepaths one for compatibility and one for rendering_device
3. Rename clustered to forward+

@clayjohn
Copy link
Member Author

Updated to:

  1. remove GL_Compatibility renderer from project selection (will expose in another PR)
  2. remove renderer selection from upper-right hand corner of editor (needs more discussion how this should be exposed)
  3. rename "clustered" renderer to "forward_plus"
  4. rename "compatibility" renderer to "gl_compatibility"

Should now be ready for review by @reduz

@clayjohn
Copy link
Member Author

@aaronfranke @HeadClot I have removed the change to the project manager and I have updated the top post to highlight how this PR allows users to directly choose their graphics API for selected rather than before where it was fixed based on renderer choice.

Please let me know if you find this more suitable. To be perfectly frank, I don't fully understand your opposition to this PR in the first. We can't name the mobile renderer "Vulkan Mobile" because it may be running over Metal, WebGPU, D3D12, or Vulkan. One thing we could do is expose renderer choice and driver choice in the project manager so users can explicitly choose the renderer they want to us and the graphics API that they want to target.

@aaronfranke
Copy link
Member

aaronfranke commented Sep 12, 2022

@clayjohn Good points. With Metal, as far as I know it's using MoltenVK, which is Vulkan on top of Metal, but I guess maybe this isn't the case for D3D12 and WebGPU. Anyway, the menus you presented make a lot of sense to me, so the driver name is still shown, just not in the project manager. How about something like this?

Screen Shot 2022-09-12 at 5 29 45 PM

@clayjohn
Copy link
Member Author

@clayjohn Good points.With Metal, as far as I know it's using MoltenVK, which is Vulkan on top of Metal, but I guess maybe this isn't the case for D3D12 and WebGPU. Anyway, the menus you presented make a lot of sense to me, so the driver name is still shown, just not in the project manager. How about something like this?

Screen Shot 2022-09-12 at 5 29 45 PM

That seems fine to me. Although to be clear, I have reverted the project manager changes in this PR and I won't make further changes in this PR. Those changes will have to be made in another PR. This PR is just about updating project settings now. I understand that reduz wants to make a proposal for the Renderer/Driver selection in the Project Manager.

@reduz
Copy link
Member

reduz commented Sep 14, 2022

Looks good to me, we may need to clean up main at some point, but can be done at another time. Need agreement from @BastiaanOlij about renaming the renderer scene class to rendering method.

Copy link
Contributor

@BastiaanOlij BastiaanOlij 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 to me, I'm happy with the rename :)

@clayjohn
Copy link
Member Author

Rebased, so should be ready to merge! @akien-mga

One thing I shouldv'e highlighted in the original post is that projects made in an earlier 4.0 version will have the project setting warning label appear on older projects in the ProjectManager. The warning can be safely ignored, but we will want to flag it in the next couple of blog posts:
image

@akien-mga
Copy link
Member

One thing I shouldv'e highlighted in the original post is that projects made in an earlier 4.0 version will have the project setting warning label appear on older projects in the ProjectManager. The warning can be safely ignored, but we will want to flag it in the next couple of blog posts:

To avoid confusion, maybe we can keep the old names temporarily for compatibility, and add some code to actually remove them from project.godot when opening in beta 2+?

@akien-mga
Copy link
Member

Looks fine overall, should be good to merge once the remaining comments are solved.

@clayjohn
Copy link
Member Author

Looks fine overall, should be good to merge once the remaining comments are solved.

Thanks for checking! Pushed a fix with your suggested changes

core/config/project_settings.cpp Outdated Show resolved Hide resolved
editor/project_manager.cpp Outdated Show resolved Hide resolved
…ng_driver. To differentiate between a driver (e.g. Vulkan or D3D12) and a renderer (e.g. clustered or mobile renderer).
@clayjohn
Copy link
Member Author

@akien-mga @aaronfranke Thank you both for reviewing! All of your comments should be addressed now

@akien-mga akien-mga merged commit 7da5322 into godotengine:master Sep 20, 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.

Change the naming of rendering methods and drivers
10 participants