Add a way to blit a texture using fragment shaders

ghsoares commented 2 years ago

Describe the project you are working on

A fluid simulation, based on this WebGL simulation

Describe the problem or limitation you are having in your project

I'm writting a fluid simulation using Navier-Stokes Equations in 2D, it works as expected but it is slow. One way to speedup the simulation is to parallelize it using the GPU, using compute shaders (provided in 4.x).

The problem is that compute shaders can be incompatible for older devices, including my development machine, so another solution would be to manually render a source texture into a output texture using regular fragment shaders, simillar to Unity's Graphics.Blit.

It would have less features than compute shaders, but for parallelized operations (those that a program runs per pixel and manipulates the same pixel, without modifying other running work groups) it would work just fine.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

It could be a VisualServer's feature, as a method that receives a source texture, a shader (or material) and the output texture, something like: VisualServer.blit_shader(RID source_texture, RID shader, RID output_texture) It would help any kind of projects that needs a simple way to parallelize a expensive operation using GPUs and support it for low-end devices.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I don't have much experience with GLES3/Vulkan rendering back-end code, so I don't have much idea on how it would work, but I assume it would perform some draw commands to the server, setup a temporary scene with viewport, setup mesh vertices, assign the material with the shader and render it, all in sync with the current thread.

If I had some idea on how Godot handles rendering process, I could create some code for the proposal and create a PR for it.

If this enhancement will not be used often, can it be worked around with a few lines of script?

A workaround would be to use Viewports, but currently there is no way to manually render a specific viewport whenever the user wants, at least not on 3.x that I know.

Is there a reason why this should be core and not an add-on in the asset library?

For performance reasons, it could perform better if provided as core feature, instead of being a add-on with the workaround cited above.

Calinou commented 2 years ago

A workaround would be to use Viewports, but currently there is no way to manually render a specific viewport whenever the user wants, at least not on 3.x that I know.

See https://github.com/godotengine/godot-proposals/issues/1010.

Zylann commented 1 year ago

I was using HDR 2D viewports in Godot 3 in combination with no-blend mode to make my brush system work with higher-depth pixel formats in my heightmap plugin. This was especially useful heightmaps since they inherently need more than 8-bit per component. But HDR in 2D is now gone in Godot 4, and there doesn't seem to be plans to add it back.

So similarly, my options are to use compute shaders, but that would cut out users who don't have Vulkan.

I guess being able to have a simple system like this one might work for me, if it supports 16-bit and 32-bit depth, supports no-blend and is able to directly use textures that are present in the regular rendering (in my case, heightmap, splatmap, normalmap, density maps...).

godotengine / godot-proposals