Download

What is the correct way to avoid possible race conditions on the render thread?

Hey there guys… so just a little question here.
I’m creating a reactive water volume, i’m creating buoyancy right now… for gerstner waves and other things, i’m thinking of using CPU calculations (like on the material) and adjust them.

But for the reactive part, i’m using the content examples with RenderTargets on where i apply a water simulation material each so or so frames…
So part of the information of buoyancy is in those render targets(granted, it could be way too little to be of any use, like on an ocean… but for pools or things like that it can be noticeable)

Now… i know that i have to, for accessing the render targets, to queue a render thread task that is 1 or 2 frames behind the game thread… for this i have to use async tasks (because i don’t want to lock the game thread while waiting).
I have some questions about understanding how to call those functions… but my biggest fear are possible race conditions that could appear.

Epic recommends using different functions/variables that each thread “owns” totally, so to avoid those possible races…

So, would it be enough to create 2 variables on my game thread object
HeightBuffer
and
HeightBufferProxy

The first being one that the gamethread only reads (for getting info on the height data), the second being the one that gets passed on to the render thread. When the render thread completes the processing (and the fence is complete) the game thread just copies the data from the proxy to the buffer… and then on each iteration it uses the copied data, while the Proxy tries to update on a fixed time span (30, or so fps for saying some number)

Would that help me avoid race conditions? I was thinking of using mutex but i think the Fence kinda works like one , am i right to think this??

Greetings guys!