For my dissertation and personal research I decided to look into simulating clot physics. I loved my physics module in second year and wanted to take it further.
My problem question stemmed from me playing games myself. I was playing a horror game and turned around and a curtain was swaying with no wind. I assumed the monster was that direction ran away and ran straight into them. So, I googled why the curtain was moving (in a rage) and found that most games optimise a cloth simulation when the player does not look at the cloth. This causes inaccuracies like I saw with it moving by itself. So I wanted to see if there was a way to simulate cloth in the background of a game without needing to be optimised for framerate performance
I researched into the main methods of implementing cloth physics and how they are optimised and used in the industry. I found that a mass spring damper is the most common method in industry with both Unreal and unity being based off of it. All the simulation I saw used some sort of optimisation when the player isn't looking at it like baking the physics with assumptions and heuristics. I decided to try and implement a compute shader that will run on a separate thread so it can run in the background with no affect on the main program. I will measure the FPS of the simulation to make sure it won't affect the rest of the game.
I implemented a grid of particles with springs connecting all the particles together. These forces then resolve each frame to simulate the cloth. There are options to limit the FPS to 60 and 120 to see how it would run on certain consoles. There are also options to increase the number of particles and swap to wire frame to see the springs themselves. There are three different types of spring each acting a different role, some structural, some allow it to bend and some allow it to fold. There was also a very important variable which I called iterations which is how many times the spring sneed ot be solved inorder to converge on the correct position. Too little a value would cause the cloth to overstretch and too high would mean irrelevant calculations are being made or the cloth would look very tough and firm.
The dark blue represents GPU FPS and light blue is CPU FPS
The GPU implementation required a dispatch at the start of the update function to map the spring and particle data over to the GPU. It then performed all the calculations required. A second dispatch then happens which applies all the movements calculated, this is the Jacobi method. After this it dispatches the data back to the CPU to draw the new cloth. The GPU is set with variables that make it much firmer and behave more like denim or kevlar
This way outperformed the CPU and matched data trends I saw in my research. The extra human interaction on the cloth with the mouse is solved on the CPU while the GPU updates which demonstrates it works on a background thread at all time.
The graph data was calculated at 50 iterations meaning some were overworked and some looked innacurate but made a fair test to compare. The speed of the cloth consistently performed above 60 FPS on average and, as most clothes in games don't exceed 25,000 verticies, is an appropriate solution to keep all cloths in games accurate throughout the whole simulation.
I have learnt so much during this module about research and implementing something I had no prior knowledge on. It felt like an actual job where I have no prior understanding of the topic and I have gone out and learnt what it is and then how to implement it. It has developed me a lot as a programmer and I feel much more confident for someone to give me a task and I just go and do it. And I achieved 93% overall, with 100% in both presentations.
I then showcased this project to industry guests at GradEx 2026 where I received a lot of feedback on how I approached this project and potential places to extend this research in the future with heat maps and bit maps to improve performance based on instance from the cloth or specific topologies.
GitHub Link: