Add force_draw method for viewports

[danielryb]

Implements a force_draw method for viewports, which allows to update an individual viewport and it's children manually.

This method works similarly to RenderingServer.force_draw, but instead of drawing all active viewports it affects only a given subset.

• Bugsquad edit: This closes Add the ability to update/re-render a Viewport manually godot-proposals#1010.

[reduz]

I have the feeling that, even if we implement this, this is not the solution to what users are asking for. My understanding is that, instead, you want to have a proper blit support into textures in real-time to make all sort of effects, right?

[reduz]

I opened a proposal for this, which I believe should make it easier to handle these kind of use cases, Feedback welcome:

godotengine/godot-proposals#7379

[danielryb]

No, I'd like to have a method which mimics Unity's Camera.Render in functionality.

Currently, if my understanding of Godot's renderer is correct, my code is missing a part which synchronizes scene data with the GPU. But since it isn't a part of Rendering Server's draw method, I wonder if it shouldn't be implemented as a separate method.

[SlugFiller]

@danielryb Could you describe your specific use case in a bit more detail? Because it sounds somewhat different from what was discussed in the linked proposal so far.

P.S. I'm aware you didn't link the proposal yourself. But it's generally the case that feature PRs are linked with a proposal, so that the need for the feature, and whether the PR actually answers said need to the extent users might expect, is properly understood.

[danielryb]

@SlugFiller I use this to render selected viewports in desired moments. Namely, in my portal implementation, I use this method to render two subviewports, where I apply changes to shader globals between the renders. With scene-GPU synchronization added, this will also come handy in creating an effect where you can see the same portal through itself multiple times.

[reduz]

@danielryb

No, I'd like to have a method which mimics Unity's Camera.Render in functionality.

That will probably never happen because Godot is just not designed to operate that way, at least not in the way this PR intends to do it. What will most likely happen is that you will be able to add usercode in the render thread to better customize the rendering process at some point, but not directly control it.

[reduz]

To clarify further, rendering in Godot is not intended to happen at any time outside the server, as it eventually we want to move it to run all the time in a thread by default for performance reasons. So you will not be able to control when something happens from outside RenderingServer.

The plan is to eventually give you access to modify the whole rendering process (more in a compositor way) where you can hook up callbacks and trigger renders, but this will be all code running in the render thread, not exposed to nodes.

[reduz]

That said we are likely a year away from implementing something like this. Maybe I can open a proposal so you and others can discuss on what implementation you would like better?

[danielryb]

Seems good.

[reduz]

Still, I apologize you took all this work to do this PR and it can't be merged yet. We are only beginning right now to expose the RenderingServer internals so you can put custom code in there. The API will likely still change a bit and there is not much documentation. The ultimate goal is that you can have compositor style access and control the whole rendering process of the frame.

[danielryb]

I don't mind it. I'm glad that a proper solution is in the works. It looks very promising.