Open RadiantUwU opened 1 week ago
Oh this was what you were working on :0 I do think in general it would be cool to give people / GDextension devs more flexibility in what they can do due to the nature of open source and all that! I'm not too strongly opinionated other than that though and am interested in seeing what others think about it
Supersedes #4287
Thank you Radiant for the proposal! I think we still need a bit more input from other people of what feature they'd like integrated but can't be integrated without exposing hooks or overriding parts of the engine (DLSS is a good example)
Note that we should also question wether it's worth it, or not, to expose this via extensions. For example DLSS, there's 2 problems 1, I am making a game and i want DLSS upscaling technique
Whether this should be extensionable or not, depends a lot on how we expect people to use it. Is this something somewhat specific that can be done in a fork and impacts only a few games? Then we can probably try and reduce the maintainance cost of a fork for this (for example, make it possible to pull in a DLSS module that can be compiled with the engine, so that no files in the engine itself need to be touched for this fork) Is this something that every user in Godot that makes a 3d game may need? Then maybe it'd be cool to have a hook so that an extention developer can develop the extension, and give it back to the community, so that it can function similarly to Jolt,.
We need to answer this kind of questions before we can find a solution. I agree that it's worth to keep all of those together in a single proposal because they may share similarities, but at the same time there's a world where each of those problems requires a different, specific, solution.
Of note texture streaming is something that Godot should eventually have. Not sure why someone would implement their own LOD system, over instead trying to have improvements in the built-in one.
I think focusing on specific hooks for upscaling and frame generation makes more sense, as it's much less work than trying to make the entire renderer replaceable with a GDExtension. This goes not only for us engine maintainers, but also for people implementing extensions.
There are a few reasons for this:
There remains the question of DLSS Ray Reconstruction which would likely need much deeper integration into the engine, while still only being available in binary form. I don't have a good answer for this, but its SDK is not publicly available yet.
Is this something that every user in Godot that makes a 3d game may need? Then maybe it'd be cool to have a hook so that an extension developer can develop the extension, and give it back to the community, so that it can function similarly to Jolt.
This depends on the extension developers, we won't have anything without allowing them to create it. This proposal is meant to allow implementing said hooks (aka also replacing the whole rendering engine).
We might change in a future meeting the idea of how RendererSceneRenderExtension
works, allowing it to modify how rendering works by allowing GDExtension to create inject its hooks at specific times (similar to Roblox), and unlike Roblox, baking it after to make it a static allocated array of function pointers, called in order to perform the steps.
[!Note] The difference between Compositors and this new system is that it can replace existing hooks, add specifically between stages of rendering, replace opaque rendering etc.
Related: #7916
Describe the project you are working on
Godot
Describe the problem or limitation you are having in your project
Allowing programmers to implement their own volumetric fog (if they want to add motion to it), DLSS, replace the rendering scene loop (
RendererSceneRender
), modifying GI system for their own, potentially adding their own LOD system, texture streaming, extend and override behavior inside RenderingServer without requiring to override it entirely.Describe the feature / enhancement and how it helps to overcome the problem or limitation
RendererLightStorage
,RendererMaterialStorage
,RendererMeshStorage
,RendererTextureStorage
,RendererGI
,RendererFog
,RendererCanvasRender
,RendererSceneRender
,RendererSceneCull
,RendererSceneOcclusionCull
and allow overridding of them.RendererSceneRender
should havesdfgi
renamed tohddagi
internally when exposed (planned by pull/86267)RenderingServerManager
DisplayServer
to insideRenderingServerManager
and haveRenderingServerManager
initialized fromsetup()
.Rendering Implementation
tab to allow the developer to choose which components to use and override.Separating them by individual components allows developers to modify specific parts of rendering, and not replace the entirety of the rendering pipeline by doing this.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
A
RendererCompositor
, except the elements are overridden just afterDisplayServer
initializes.RenderingServerManager
will override according to the tab "Rendering Implementation" inside project settings.RenderingServerManager
is created insideMain::setup()
and initialized just afterDisplayServer
insideMain::setup2()
The overriding system will work as follows:
RenderingServerManager
will have an enum of overridable components, alongside functions to register components during server initialization.DisplayServer
initialization,RenderingServerManager
will look at overridden components.default
, it continues to the next.memdelete
), and then the new one takes place by initializing from ClassDB.If this enhancement will not be used often, can it be worked around with a few lines of script?
No.
Is there a reason why this should be core and not an add-on in the asset library?
Requires modification of the source code.