Add compute texture demo

[BastiaanOlij]

This PR adds a demo that shows off using a compute shader to populate a texture.

Note this requires https://github.com/godotengine/godot/pull/79288 and https://github.com/godotengine/godot/pull/79696, both are merged into master.

• Production edit: This closes https://github.com/godotengine/godot-demo-projects/issues/934.

[Lateasusual]

Most times that I run the demo the simulation breaks due to the texture data being full of NaNs, I think the textures should be cleared at the start.

[BastiaanOlij]

Most times that I run the demo the simulation breaks due to the texture data being full of NaNs, I think the textures should be cleared at the start.

Hmm, my graphics card driver must do that automatically. Easy fix though, try it again :)

[GeorgeS2019]

@BastiaanOlij @Calinou

Consider using this as demo for godot 4 Compute Shader

Source

Youtube

Code:

currently 80% works with Godot_v4.0-beta2_win64

[BastiaanOlij]

@GeorgeS2019 That shows a different use case of compute shaders than what we're showcasing here, definately worth having a demo like that here.

That should be a question asked to the author of that demo, whether he'd like to add a PR here to submit (a version of) his project. It would be rude to just add it.

[GeorgeS2019]

Already asked 😉

[henriksod]

Hi! I am the author of that Godot project. I have no problem with this being added to the list of official demo projects 😄

I think it needs some work though, will definitely look into how it can qualify as a demo project here.

I remember that for this project I had struggles with the lack of multi-pass post processing in the engine. I suppose this has not been implemented yet according to https://github.com/godotengine/godot-proposals/issues/496

[dotlogix]

@BastiaanOlij I quickly ported your code 1:1 to C# any interest adding this to the demo as well? TestCustomTextures.zip

Thx a lot btw for implementing this this opens so many doors now for high-performance apps in Godot

Much Love <3

[GeorgeS2019]

@dotlogix

Thanks for your contribution.

We are getting many users from Unity3D, contributing Godot4 c# DEMO is ONE significant way to welcome them.

Thanks again

[BastiaanOlij]

@henriksod cheers, I'll find some time to put a PR up. Watching your video I definately had some ideas for improvements so I might see what I can do, no promises :)

We are looking into adding something for post processing, but there is still a lot of debate on the direction that will take.

[BastiaanOlij]

@dotlogix it'll be good to have C# versions of demos for those who want to use C#, but I'm not sure what our approach here is to include them.

@Calinou maybe you have some pointers here?

[Calinou]

@Calinou maybe you have some pointers here?

The policy for C# demos is to avoid having C# ports of demos unless the scripting part is what they are demonstrating. This is because maintaining separate C# demos is a lot of work, so we try to keep the maintenance effort for them minimal.

[BastiaanOlij]

btw @Calinou I'm happy for us to merge this as is, I'll revisit this when #79696 gets merged, that isn't a showstopping issue.

[Calinou]

I'll revisit this when #79696 gets merged, that isn't a showstopping issue.

That PR was just merged 🙂

Could you look into revisiting this PR accordingly? I can merge this afterwards.

[BastiaanOlij]

@Calinou will do!

[BastiaanOlij]

Ok, I've added the multi-threaded protection code made possible by #79696 , and enabled multi-threading. It works nicely.

I did find one issue with assigning the texture_rd_rid on our Texture2DRD resource, as this assign needs to happen on the main thread, but the RD texture is not created until the rendering thread gets a turn, its not yet available on the first frame.

There is a sync issue left to solve here as we may not do our swap in our rendering thread before we run our process code but in worse case it runs a frame behind. Talking to @reduz about how we should solve this issue.

[BastiaanOlij]

Ok, I've solved the round robin issue, the only issue left now is that in multi-threaded mode, the very first frame our textures haven't been created yet.

We can create the texture objects from the main thread, and then do the rest of the work in the render thread, but it may send the wrong message to people looking at the code. While RenderingDevice is thread safe, there are a lot of commands that will cause problems when called from the main thread.

[Oman395]

I just spent several hours painfully working out how to actual use textures with godot compute shaders... I wish I'd seen this PR! One note-- it might help for there to be two demos, one that's simpler and one that's more complex, to help with the fundamentals without cluttering it with logic that's not 100% related just to using textures with compute-- maybe something as simple as a black screen that brightens, by adding onto the color of the previous frame each frame, using imageStore rather than just making it a fragment shader or sum to help teach how to do random writes, or maybe even just a shader that writes the uv texture onto an input image (this is based on the things I has to figure out manually so I could actually use the shaders in the way I want to...)

[BastiaanOlij]

@Calinou the reason I created the compute folder is that I want to make a number of different examples that all use compute shaders. People will be looking specifically for these types of examples so I wonder if Misc is a good place.

[BastiaanOlij]

@Oman395 definately planning on doing more examples :)

[BastiaanOlij]

Figured out the dumb mistake I made in the normal calculation, logic I was using was the calculation you normally use in a vertex shader. So just adjusted this to work by mimicking a normal map.

[BastiaanOlij]

@AThousandShips I think I got all your changes :) I've left two items unresolved even though I've fixed things up because it is important to capture the feedback.

There might be more here we want to document or capture in some way as it is easy for users to ask the question, "why are these parameters, why aren't we using the member variables directly?". It's a logical question to come forward if we don't prefix parameters and thus increase the risk of variables shadowing members which can lead to confusing code. This lies at the heart of why I always prefix my parameters with p_, it makes it far more easy to read that we're not dealing with a member variable of the same name and that there must be reason to the madness of reusing a name.

Multithreading and what changes from frame to frame and how you can break things if you don't think this through are important especially in examples such as these. Simple mutex protection wouldn't help you in this scenario.

[AThousandShips]

Will take a new look!