Project specification

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]. A context that has the latter
requirements are video games, since they are required to be interactive [2]. There exists multiple methods for simulating fluids
in video games, with different advantages and disadvantages [1, 2].

Water occurring in video games is not uncommon. Water occurs in games like the original Half-Life game [3] as well as the
modern game Sea of Thieves [4]. While the water in these games look different and act different from each other, what these
games have in common is that the water is not interacted with in any further extent than player characters swimming through it.
Developing games in which players interact with water in more complex ways can be something desirable and somewhat novel.
There is a computer graphics concept called metaballs [5]. Metaballs are used to model surfaces (among other things) within
computer software that can easily take on a distinctly organic look when rendered [5]. Particle systems where the particles are
metaballs have been used to create water simulations, specifically realistic real time simulations of streams of water across
terrain [6]. In that simulation, there is support for splashing water, and the metaballs are rendered using a billboard rendering
technique. Other rendering methods are also suggested, making the simulation adaptable to the needs of the context.
When creating games, it is very common to make use of a so called game engine. The game engine is a development
environment for creating video games, aiding the development by including essentials like a rendering engine, sound engine,
physics engine, among other things [7]. A world leading game engine is one called Unity, which is free to use assuming you
make very limited revenue from using it [8]. The use of Unity is widespread, with a large and active community of game makers
of varying levels of experience [8].

2 Problem

An idea for a video game is to have a river flow down some terrain and let forests, societies and other phenomena grow
organically around the river. Players should be able to interact with the terrain, changing elevation and other properties to
alter the course of the river, and in that way affect the life around the river. One problem to solve in order to realize the game
idea is how the river should be constructed so that it looks plausible and is interactive in real time gameplay.
This project proposes to construct the river using a particle system of metaballs similar to [6], but with less photo-realism, no
splashing support and using 3D metaballs with mesh rendering. The goal is to implement the simulation and render it in a
rudimentary way inside Unity. This tests the utility of the proposed method of real time interactive water simulation in a real
and popular video game development environment. This also evaluates whether the proposed method can be use to realize
the aforementioned game idea.

3 Implementation

There are multiple different milestones that can be identified in this project. As stated in the section above, the least
acceptable goal is to make the simulation in Unity, or to prove that it is not possible to simulate in this way in real time (at
least in Unity). At the point where the least goal has been reached, the possibility of using the technique for constructing the
river in the development of the game idea in Unity will have been determined. This is where the milestones diverge along
two different routes. The frist route is laid out with the assumption that it is possible to create the real time simulation, and
the second route is the one taken if it proves impossible to accomplish a basic simulation.
Along the first route, the most important milestone will be to add interactive terrain editing, so that players can alter the
course of the river. This is what makes the simulation interactive, a very important aspect if it is to be used in video game
development. Further goals are to render the simulation in a pretty style, using fast shading methods e.g. using the Phong
reflection model [9] in tandem with Phong shading [10], alternatively implementing a shader in a material in Unity that
accomplishes similar results. See the next section for more specifics of the implementation.
The second route, where simulation using 3D metaballs and mesh rendering appears to be impossible, other techniques
for water simulation will be tried. Different techniques proposed in [6] will be attempted in Unity, until either the resulting
simulation is satisfactory or all the proposed techniques have been tried, at which point it will be concluded that the
desired water simulation is impossible. See details in the next section.

3.1 Features

Least goal:
  • Terrain rendered from heightmap texture in Unity.
  • Metaball particle system:
    • Particle system with settings for e.g. particle lifetime as ordinary particle systems usually have.
    • 3D metaball physical simulation with gravity, cohesive forces between metaballs, collision between terrain and metaballs and damping of metaball velocity.
  • Camera movable using keyboard and/or mouse.
  • Metaball rendering:
    • Generating isosurface from metaball positions.
    • Converting isosurface into triangle mesh.
    • Rendering triangle mesh (likely able to use the Unity rendering).
Route 1:
  • Support for painting the heightmap (add and subtract) using the mouse buttons.
  • Either implement Phong reflection model and Phong shading of the water isosurface, or create material in Unity.
Route 2:
  • Implementation using 2D metaballs.
  • Billboard rendering of metaballs.
  • Point sprite rendering of metaballs.

4 Final system sketch

The final system, including the features of route 1 above, could look something like the concept pictures in
figures 1 and 2.
Figure 1 shows a concept image created in the 3D software Blender, where a river runs down a plane. The final system will
have the terrain be defined by a heightmap, rather than a triangle mesh as in figure 1, which will give less of the
low-polygon-count look and more of a smooth terrain look. The colors and 3D look in figure 1 are accurate to the final
system.

Figure 2 shows a concept image drawn in 2D. The image is meant to showcase the fact that the river should be able to
fork and form lakes naturally given the correct terrain conditions. The colors and lighting of figure 2 might be inaccurate to
the final system.
Looking at figures 1 and 2 should give a sufficient impression of what the final system will look like mid-simulation. The goal
is to have the particle system start emitting particles at the top of the terrain, meaning the water will flow downwards during
the course of the simulation. The lifetime of the particles will have to be adjusted during the simulation either automatically
by the system or manually by the user so that the particles are destroyed once they reach the end of the terrain. After the
particles have reached the end, the simulation should continue, producing results similar to those seen in figures 1 and 2.
When the user edits the terrain during the simulation, the water should react accordingly, forming new resulting rivers.

5 Risks and challenges

Below is a table describing potential risks and challenges specific to this project.
Description
Contingency plan
Unity has poor support
for heightmaps
Some other method could be
used to represent the terrain,
e.g. a triangle mesh.
Plausibility of the simulation
turns out worse than expected 
Shifting the implementation to
one more similar to the one
proposed by [6].
Model will turn out less
sophisticated than desired
grade dictates
Extending the project by making
the model more complex, using
models described in [2] and its previous parts.

6 Perceptual study

Important to video games is so-called suspension of disbelief, which is where a person faced by something surreal
intentionally avoids thinking critically about what is being viewed [11, 12]. The importance of suspension of disbelief
in video games lies in players accepting the game world despite in-game behaviors and phenomena are not
realistic to the real world [12]. Simulating water in the way suggested in this project specification is not physically
accurate, meaning its behavior in a video game would not be identical to real world water. Examining if players will
suspend their disbelief when faced by the present water simulation is an important step of evaluating the utility and
video game applicability of the water simulation method. A perceptual study related to this project could therefore be
to evaluate to what degree players will suspend their disbelief when faced by the water simulation.

7 Project blog

The project progress will be updated continuously in a project blog, found at the following URL: https://metawater.blogspot.com/. Blog readers can disregard this section, since they are already reading the specification here!

8 References

Kommentarer

Skicka en kommentar

Populära inlägg i den här bloggen

Marching cubes algorithm

Bild
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!
Läs mer

Gilbert Johnson Keerthi Stelly Muratori... or not

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...
Läs mer