Navier Stokes - Water Simulation

We finally finished the project, or at least out plan b. The additions mentioned in previous blog post about adding more water-like materials, implementing a moving water tap and simulating foam were all added to the final version. The water material was created by using a transparent render mode and choosing a light blue color. The material would also reflect the sky box making it look more like soap bubbles. The moving water tap was easily implemented by adding a script. The most challenging part was to implement the foam effect. By calling a function on each sphere from the parent class whenever a sphere had peaked, we could change the color of the material to white and the gradually fade back to its original color. Due to time constraints, there were a lot of improvement that we didn't have time to implement. One of those improvements was to have a timer that faded the color of the sphere instead of it being faded with the height. This would make the foam last longer and pr...

Further researching the iWave algorithm has shown us that this seems like a realistic approach. Due to the provided code in the paper mentioned in the last post, we have been able to make large strides in implementing the algorithm. To make our project a bit different and not only try to implement the algorithm described in the paper, we also decided to go back to our original idea of having a tap pouring water and interacting with the mesh to create waves. For details about the algorithm we recommend you read the original paper by Tessendorf  mentioned in the last blog post, however we will explain some nice-to-know parts of the algorithm that we deemed important. The algorithm is primarily focused on being interactive (hence we chose to add the tap again) and fast. By combining functions that calculate the height of water surfaces calculating a waves motion and functions that conserve the water masses, it is possible to create realtively realistic looking waves/ripples in the w...

After further research and experimenting, we have decided that implementing a water simulation using the Langarian method is too advanced to manage during the short time we have left to finish the project. Further research has instead helped us find a new method that we belive could be feasible for us to implement. The so called iWave method. It is mainly based on manipulating 2D convolution, making it simple and possibly realistic for a project of our scale. By reading the report Interactive Water Surfaces (2004) by Jerry Tessendorf,  we have gotten a relatively good insight in the iWave algorithm, the math it is based on as well as how to implement it. Similarly to Kelager's report, Tessendorf explaines all math and how to implement it to code. However unlike Kelager, this report is more consise, giving us hope that it is a simpler-to-implement algorithm. Our goal for the coming 2 days is to read more about this algorithm and try experimenting with the instructions given by T...

As no progress was made using Unity's Rigidbody system, we decided to implement Kelager's algorithm fully. Most of the algorithm was already in place, as we used it to calculate forces when using the rigidbodies. What we needed to implement was the LeagFrog algorithm to calculate the next position and next velocity of each water particle and correct these using collision detection and management. In the video below the a first iteration of the algorithm can be seen. In the beginning the spheres fall in a promising manner, however they are quickly misplaced. In the following pictures, as a video could not be recorded, the results of a second interation of the algorithm can be seen. Notice how the water does move and stay inside the boundaries, however the forces do not seem to be acting on the particles correctly. The velocities seem to be too high, which could either be a result from miscalculating the velocities themselves or from incorrect internal forces. Observe that ...

As stated in the previous post, the velocity of the spheres were not conserved using Unity's Rigidbody system. According to Micky Kelager's paper Lagrangian Fluid Dynamics Using Smoothed Particle Hydrodynamics (2006), the kinetic energy and hence the velocity had to be redirected after colliding with different objects. Hence we introduced Kelager's proposed collision system in the Unity's OnCollisionEnter and OnCollisionExit functions. In the video below (obs! video updated for clearer view) it can clearly be seen how the spheres start moving in a more wave-like pattern. This video, compared to the one in the last blog post, shows a greater and more water-like movement in the spheres. Even though the pattern seems wave-like, compared to the last blog post, it is nowhere near a adequate water simulation. Due to the limitations using Unity's Rigidbody - the impossibility do directly calculate acceleration and velocity and use those values when managing the colli...

As it was time to implement the mathematics controlling the behaviour of the spheres, we quickly noticed that the pouring technique was not going to cut it. Taking a lot of inspiration for our math from Micky Kelager's paper Lagrangian Fluid Dynamics Using Smoothed Particle Hydrodynamics (2006), we realized that the number of available particles had to be a fixed number from the beginning of the simulation. Hence the obstacles and the pouring was removed and instead 200  - 400 spheres were placed at the scene in Unity. The scene in its current state can be seen in the figure below. Observe that we decided to not render the meshes of the cube to more easily see how the spheres behave, however they are still there. Following Micky Kelager's paper we implemented external forces in the form of gravity and surface tension and internal forces in the form of the viscosity force and pressure force, as well as all the surrounding math these forces required to work. We decided that ...