-
-
Notifications
You must be signed in to change notification settings - Fork 21.5k
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
Conversation
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. |
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. |
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
|
@Calinou I disagree, it's extremely relevant, not an implementation detail.
|
@clayjohn The Android changes looks good. |
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. _ |
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? |
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. |
Notes from September 9th meeting: |
38b5fc5
to
3f08a3c
Compare
Updated to:
Should now be ready for review by @reduz |
@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. |
@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? |
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. |
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. |
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.
Looks good to me, I'm happy with the rename :)
5d8d45f
to
d253a42
Compare
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: |
To avoid confusion, maybe we can keep the old names temporarily for compatibility, and add some code to actually remove them from |
Looks fine overall, should be good to merge once the remaining comments are solved. |
d253a42
to
e19837c
Compare
Thanks for checking! Pushed a fix with your suggested changes |
…ng_driver. To differentiate between a driver (e.g. Vulkan or D3D12) and a renderer (e.g. clustered or mobile renderer).
e19837c
to
4a1c7de
Compare
@akien-mga @aaronfranke Thank you both for reviewing! All of your comments should be addressed now |
Thanks! |
rendering_method
and rendering/*/driver
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:
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:
when using gl_compatibility
when using rendering device based renderers