Metaball water simulation

And so, the implementation has been finalized. I think I am less pleased with the results now compared to before. Earlier there have been no attempts to make the water look like a river, and now that it was attempted, it turns out that the metaballs are not very suitable for simulating a river. For simulating small amounts of water in general, the system seems to work quite well. At least it is my opinion that the metaballs resemble water quite well. Unfortunately, the goal was to explore metaballs' ability to simulate a river, which they do not do very well. See the image below for the result of the simulation. The image above is a best case result of the simulation and not very representative of the general behavior. A playable version is available here:  https://geodropstudios.github.io/misc/metawaterDemos/full/index.html The image below is more representative of the general behavior. The main reason of the low framerate of the simulation, as well as its lacking rese...

The implementation is nearing completion, now. With this progress milestone, forces between the metaballs have been added. Each metaball now acts as a particle at the end of a spring attached to every other metaball in the scene. This means that all the balls will smoothly attract and repel each other so that they lie within some minimum distance from each other. The implementation of this was as simple as applying the well-known Hooke's Law, and assuming a mass of 1 kg for each ball to get acceleration from the calculated force using Newton's Second Law. In order for metaballs far away to not be attracted to the other balls, a threshold maximum distance was also added, beyond which no spring force is applied. The minimum and maximum distances were tuned to achieve a good behavior. The image below shows a still image of the current state of the project. A playable demo is also available through the following URL:  https://geodropstudios.github.io/misc/metawaterDemos/seco...

Here comes the first milestone where the metaballs are actually animated! Adding gravity to the metaballs was easy as pie, simply looping through them and updating their velocity by the gravity acceleration 9.82 m/s^2 every frame is not expensive, nor is it difficult. The hard part of this milestone has been the collision detection. The collision detection is fuelled by ray-triangle intersections. Each frame, each metaball's previous position is recorded, then the metaball is moved according to its velocity (after the velocity has been update in accordance with acceleration). The new position and the old position form a line between them. This line can be thought of as a ray originating in the previous position and having the direction face toward the current position. The terrain is a triangle mesh, and so it is made up of a collection of triangles. Each frame, going through each triangle for each ball and testing whether there was an intersection between the ray and the triangl...

This is just a quick progress update so that the blogging is continuous. Some progress has been made on the implementation of physics and collision detection. The main progress so far has been to instantiate the metaballs over the terrain in a robust manner, in order to be able to test the physics. The image below shows this progress, along with some simple Unity-native materials assigned to the water and the terrain. Github commit for this progress: 89539b4662e43c5b77c2b914105284a4bc56b073

The title of this post is an absurd amalgamation of names, but with good reason. Gilbert, Johnson and Keerthi described the GJK algorithm. Later, Jay Stelly of Valve and Casey Muratori realized that a lot of the papers describing the algorithm were describing methods that did a lot of unnecessary tests and computations. So, Muratori wrote a formulation and described it in a video, which turned out to be a lot simpler than what most papers described. Muratori has written a blog post about it here, where the video is also included:  https://caseymuratori.com/blog_0003 Despite being inspired by this and by the lecture on collision detection today, I realize that this algorithm probably is not very fitting for my simulation. I will instead implement a simple ray-triangle intersection test. The metaballs (i.e. the center point of each ball) move, and define rays in the direction they move, originating in their position. If their new position is on the opposite end of a triangle in t...

The metaball rendering now works as expected, after a lot of head-scratching and second-guessing. The images below displays a randomized example scene of the metaball surface being rendered within a bounding volume. The second picture is the same scene as the one above, with the metaball positions slightly altered. The development went through multiple phases. First, there was a research phase, where as much material and inspiration for the implementation was collected. Then, the experimentation phase began, where different parts of the implementation were being tested separately to make sure that they worked one by one. After this phase, the implementation began with a naive approach, where all scalar field values were being calculated multiple times per frame, and no pair of triangles in the mesh shared even a single vertex. Computing the scalar field values for each frame separately from the actual marching cubes algorithm is assumed to have given a certain speedup. At fir...

The marching cubes algorithm is an algorithm that renders an isosurface defined by a scalar field. The metaballs define just such a surface, so the algorithm is perfect for this situation! There is a video that showcases and partially explains the algorithm, embedded below. Additionally, there is a web page that thoroughly explains the algorithm and supplies source code for a c implementation of the algorithm. This is the URL:  http://paulbourke.net/geometry/polygonise/ . My plan is now to adapt that implementation to my project, which will mean writing it in C# as well as using the Unity API. Naturally. the original author Paul Bourke deserves a lot of credit, and will be credited in the code as well as in the project report (and on this blog, obviously). The source code going together with the great explanation is exactly what I needed to be able to easily use this algorithm in the project. Thanks Paul!

Strides are being taken! As of right now, the system is able to construct metaballs and traverse the surface they form, rendering points in some places along the surface. In the demonstrative image below, the center of each ball is marked by a sphere, and each point that is rendered lies on the metaball surface. This is the first step in constructing a mesh from the metaballs, and truly a great leap forward. The volume within which the metaball isosurface is defined is bounded by and axis-aligned bounding box native to Unity. The resolution of the uniform grid inside the bounding box where points are being checked is variable, so machines with high performance can use a higher resolution and that way get a more precise metaball mesh in the end. The second image shows what it looks like when all points inside the metaball volume are rendered. In both examples above, the location of the center of each metaball was randomized within the bounding box. Github commit for this pr...

Progress is starting to be made! First of all, here is the link to the KTH Github page where the source code and other project files are available:  https://gits-15.sys.kth.se/astee/metawater . Second of all, the first thing that was implemented in the project was a movable camera that rotates using mouse movements and translates using keyboard input. It felt necessary to get the camera completed early for debugging purposes. Third of all, a true milestone has already been reached. The milestone is to be able to use a heightmap represented as an image file, such as the one in the picture below, to generate a terrain mesh inside Unity. The image is imported into Unity as a texture and set to be readable and writable, then loaded into a script called TerrainConstructor.cs as a Texture2D. The script extracts the color data from the texture and creates a vertex for each pixel in the heightmap corresponding to the pixel coordinates and the intensity of the pixel color. The ve...

And so, the project begins. As any good project, the first thing it consists of is a good specification, so here is the preliminary project specification, which was approved by Christopher Peters, the course examiner. Note that the style of the specification is different from the style of the blog, and might look downright strange in some places since it was copied and pasted from a separate document, and Blogger is a pretty bad service. Metaball water simulation in Unity Project specification, DH2323 Computer Graphics and Interaction 2020-04-02 Anders Steen ( astee@kth.se ) Grade ambition: A 1 Background Fluid simulation is a computationally difficult task, and there are multiple different approaches to creating such simulations [1]. Different contexts call for different requirements that are put on the results of the fluid simulation, some contexts require high physical accuracy, while others require plausibility as well as real time performance [1]....

Hello there, dear reader! This is a project blog for the course DH2323 Computer Graphics and Interaction at the Swedish Royal Institute of Technology (KTH). My name is Anders Steen, and I am the sole member of this project. The posts will be progress updates during the course of the project, containing summaries as well as screenshots of the project's current status. The next post will be the preliminary project specification, so stay tuned for that!