Institutionen för datavetenskapDepartment of Computer science

Examensarbete

Real time wind simulation in a 3D game

by

Vanessa Rojas

LIU-IDA/LITH-EX-G--21/047--SE

2021-06-18

Linköpings universitet

SE-581 83 Linköping, Sweden

Linköpings universitet

581 83 Linköping

Linköpings universitetSE-581 83 Linköping, Sweden

Linköpings universitet581 83 Linköping

Linköpings universitetInstitutionen för datavetenskap

Examensarbete

Real time wind simulation in a 3Dgame

by

Vanessa Rojas

LIU-IDA/LITH-EX-G--21/047--SE

2021-06-18

Handledare: Anders FröbergExaminator: Erik Berglund

På svenska

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat förickekommersiell forskning och för undervisning. Överföring av upphovsrättenvid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press seförlagets hemsida http://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possiblereplacement - for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for your own use and touse it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to bementioned when his/her work is accessed as described above and to be protectedagainst infringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity,please refer to its WWW home page: http://www.ep.liu.se/

© Vanessa Rojas

Real-time wind simulation in a 3D game

Vanessa RojasLinköping UniversityLinköping, Sweden

vanessa.rojas@protonmail.com

ABSTRACTWhile many games incorporate physics to simulate differentaspects of gameplay, this is uncommon when it comes to fluidflows like wind, due to the complexity of the associated equa-tions. The challenge increases in 3-dimensional worlds withlarge world maps and a real-time simulation. It is howeverpossible to simplify a simulation by prioritizing visual andgameplay effects rather than physical accuracy, while still us-ing a physically-sound system as a base. What this meansfor each game will differ depending on the architecture ofthe game, the desired outcome and acceptable performancecosts. This paper addresses the implementation of a real-time,grid-based wind simulation in Rust for the game Veloren. Apreliminary implementation with a simple graphical outputwas used before the simulation was integrated with the game.In Veloren, the resulting implementation is primarily server-based with a windsim system that runs the simulation itself,while the client side receives updates for the player’s posi-tion, allowing the player to fly with a handglider using thewind currents created by the simulation. The performance costof the implementation was measured for both the server andthe client, using frames per second according to the grid size(space resolution) and how often the simulation is run (timeresolution). When compared to the baseline before the imple-mentation, it showed a performance cost for the server thatincreased with the time and space resolution. For the clientside, no detectable performance cost was observed, but a lowersimulation frequency resulted in sharp changes in wind direc-tion from the player’s perspective. Given that many optionsfor optimization exist which were not systematically explored,the results show promise for the feasibility of this type of sim-ulation in Veloren by expanding the current implementation.

INTRODUCTIONWind is a complex natural phenomenon with a behaviour thatis not yet fully understood. However this hasn’t stopped thedevelopment of applications that model wind in science, engi-neering and even game development using fluid dynamics [13].

A fluid can refer to both liquids and gases. Wind is a fluidflow as is for example running water or blood flow [2]. Fluidscan be simulated to different levels of precision depending onneed and available computational capabilities. Typically, theNavier-Stokes equations are used for this, but the equationsare notoriously complex and difficult to approach [6], to thepoint where they are the subject of one of the 6 remainingMillennium Prize Problems in mathematics along with thefamous P versus NP problem1.

The fact that there’s an incomplete understanding of the the-ory behind the behaviour of wind means that any simulationswill necessarily be limited in some manner [13]. Over theyears, computational methods have been gaining ground as away to create useful approximate models of wind with variousapplications in aerodynamic research, biomedical engineeringand other areas [2]. These techniques usually involve highdemands of computing power and are therefore not commonlyapplied to game development. The depiction of wind in gameshas thus historically used methods aimed at faking the dynam-ics rather than simulating them [13, 16].

Within the last 40 years, methods that favour a simulation thatis convincing to the viewer in terms of looks and interactionhave been developed, as opposed to the more strict physicalaccuracy required for engineering applications[13]. This hascaused a growing interest in the field to incorporate realisticfluid simulations to enhance the player’s experience withoutbeing detrimental to performance [11, 3]. These methods fo-cus on keeping the computations light in order to have fastreal-time interactions while at the same time achieving con-vincing effects, and the ways to do this can be as varied as theapplications themselves [3, 7, 15].

PurposeThis thesis is aimed towards developing and implementinga physics-based wind simulation on an open-source, three-dimensional(3D) role-playing game (RPG) called Veloren2,while exploring what kind of existing method or variationthereof is best suited for this particular case, and evaluatingthe costs involved in terms of performance.

As a proof of concept, this study can allow an estimation offeasibility for the use of a wind simulation in Veloren, andthe future development of features, optimizations and moredetailed performance analyses.

1Can every problem that is easy to verify also be easily solved? [1]2https://book.veloren.net/introduction/what-is-veloren.html

1

Research questionWhat is the performance cost for a real-time wind simulationon the game Veloren in terms of frame rate?

LimitationsThis thesis does not attempt to find the most cost-effectivesimulation for Veloren. The choice of method is based on the-oretical exploration, availability and accessibility of existingtechniques. As a result, it focuses on CPU-based methodswith special-purpose solvers based on Navier-Stokes, primar-ily guided by the work of Jos Stam[14].

This thesis does not perform user studies, and the effect onthe player is only measured by FPS on the client side andsubjective observations. Due to the large number of possibleparameters that can be tuned for different effects, it is outsidethe scope of the study to evaluate how realistic or pleasant theeffects of the simulation can be for players. Although memoryand network aspects are a part of the design, only a local setup is measured in single player mode, not including networkcosts from multiplayer mode.

THEORYThis section describes the context for the study based onVeloren and relevant concepts, a review of previous workon fluid simulations which leads to a description of the chosenalgorithm used for the implementation.

BackgroundVelorenVeloren3 is an open-source, voxel-based open-world RPG withsingle and multiplayer support. The player can use a hand-glider to move through the air (Fig 1). There are also airships,flying animals, and other flying objects that interact with theplayer. However, no wind as such exists in the game. Liftis provided by the shape of the entities interacting with theair, which has a predetermined density, while flying is doneby direct player input. A wind simulation should be able todynamically affect the character and other objects in the world,allowing the player to glide through the air currents, evenwithout direct input. Such a simulation can also allow foreffects like clouds and smoke moving along the air currents.

World sizeVeloren models the world with voxels or blocks4. Each blockis defined to have a side length of 1 meter in-game, so 1000blocks is equivalent to 1 km. The default map size is 215x215

blocks with unlimited vertical height.

The map size can be changed during world generation, but thedefault size is used in this thesis in order to meet the defaultneeds of the game.

ArchitectureVeloren is written in Rust, and uses an Entity ComponentSystem (ECS) architecture5 in which data (Components) are3https://book.veloren.net/introduction/what-is-veloren.html4The 3-dimensional unit used for everything in the default 3D-frontend, just as pixels are 2-dimensional units used in 2-dimensionalgraphics.5https://book.veloren.net/contributors/developers/ecs.html

Figure 1. A screenshot of Veloren showing a handgliding player.

separated from behaviours (Systems). An Entity logicallygroups different components. A system can then affect entitiesbased on which components the entities are made of.

The game is modularised with different Rust Crates. A Cratein Rust is a unit of compilation, which consists of differentmodules. The frontend and backend are independent fromeach other. A server-client model is used even on single-playermode, where the server module runs on the local machine6.This thesis uses the default crates for version 0.9.0, whichmeans voxygen and server-cli for the frontends, server, clientand world for the backend, with the common and networkcrates containing utilities.

Game loop and tickMost games use game loops as a way to offer interactivity. Atick corresponds to one game loop being executed, taking ininput from the player, updating the game and returning theupdate to the player [12]. Tick rate is how often the mainloop of a game is executed. In Veloren this is defined for thedefault server as a fixed 30 ticks per second7. Custom setupscan modify this, however this thesis works with the defaulttick rate.

Tick time is how much time is spent on one tick. For theserver loop, at a fixed tick rate of 30, this is 1/30 seconds orapproximately 33 ms. Each call in the main loop is going touse some of this time, which makes it a valuable measure ofhow much time is spent on a specific system. In this case, thetime spent on the wind simulation.

Frame rateVeloren has elements of high-speed gameplay, with attackswhich must be directed using a pointer device, and time-sensitive movement input to control the character’s placementstrategically or to avoid attacks and obstacles which may incurpenalties to the character’s movement and health. Any addedsystem will affect the time it takes to compute and processeach loop. If a full simulation is computed each tick, it may in-crease the work it takes to produce one frame for the game[12],potentially blocking new information from reaching the player6https://book.veloren.net/contributors/developers/codebase-structure.html7https://gitlab.com/veloren/veloren/-/blob/master/server/src/rtsim/tick.rs

2

and incurring a delay in feedback to the player’s actions. Thishas been shown to impact player enjoyment and performance[8]. The cost of the simulation can thus be estimated by mea-suring the change in frame rate as the simulation is being runcompared to when it isn’t.

Evaluation toolsThe open-source tool Tracy v 0.7.68 was used for the evalua-tion of both the server and the client. This tool was alreadyintegrated in Veloren and did not involve additional code9. Themetric of interest was mean and median FPS during a giventime, as well as percentage of the total time for the server.

Previous workFluid simulationsThe understanding of how fluids behave can be tracked backto the 1800s with the development of the Navier-Stokes Equa-tions which are considered the mathematical framework forfluid dynamics [13]. While these equations don’t have fullanalytical solutions, numerical methods have been developedover time, and with the advent of more efficient computing,the equations can be solved numerically for most practical ap-plications. The field of Computational Fluid Dynamics (CFD)is dedicated to the study of these methods and widely usedin science and engineering applications, for example for op-timising wing shape in aircraft [4], or simulating the bloodflow through the heart [5]. For most of these applications thesystem to model can involve very complex flow types withfor example turbulence and combustion which will bring highcomputational demands to any simulation, taking long times torun and having risk of instability in the behaviour of the simu-lated fluid[13]. Because of this, historically the full simulationis run off-line and the results then used in real-time[11].

Fluid simulations in games and interactive mediaIn order to use a fluid simulation in interactive media, it needsto be available in real-time and not be detrimental to per-formance. Because of the complexity involved with CFDtechniques, fluids have been represented in the past by sim-pler alternatives devised in order to "fake" the effects, such asfixed flow functions used as primitives which give good visualeffects but cannot be interacted with[13]. Another non-CFDtechnique is the cellular automata, which is a popular tech-nique to simulate fluids in voxel-based games like Minecraftwhich has however simple and unrealistic results [16]. Thenon-CFD techniques are thus very limited, which brings theinterest back to more accurate simulations.

While a full Navier-Stokes model may still be difficult to adoptfor real-time interactive applications like games, it may notbe necessary to use the full model[13]. Even though all fluidscan be described with the same set of Navier-Stokes equations,the choice of computational method highly depends on theproperties of the fluid in question such as density, viscosityand surface tension. This determines what can be simplified toallow for a more tractable model that is still realistic-enoughfor the purpose of each application[2]. On the other hand,8https://github.com/wolfpld/tracy9https://book.veloren.net/contributors/developers/performance-analysis.html

because the simplifications are less general, a method suitedto modelling water or smoke might not be the best to modelwind and vice-versa [2]. It is thus important to find a modelthat can be optimized for wind.

Most of the previous studies of fluid simulations in interactivemedia don’t focus explicitly on wind. Muller et al[11] usesSmoothed Particle Hydrodynamics (SPH) to model fluid flowslike smoke, water and fire. However, an SPH model may notwork as well with wind due to instability around the boundariesof the simulation - where the fluid meets other objects [9]. SPHis therefore more suitable for non-interactive simulations anddetailed visual animations and is widely used especially inGPU-based simulations [7, 15].

In 1999 Jos Stam [14] developed an algorithm to solve theNavier-Stokes equations with a grid-based (as opposed toparticle-based) method. The method is meant to be stableand fast enough for real-time with a focus on visual resultsinstead of physical accuracy. The algorithm is also meant tobe accessible and is thus still widely used in games, and canbe generalized for 2D and 3D along with other extensionsto fit specific needs. There is however a limitation to smallgrids for real-time computations, which could mean smallvolumes or a coarse resolution. The game God of War [3]for example, computes small sections of a wind simulationaround the character in order to achieve performance at a highresolution while using this method 10. This thesis focusesinstead on a coarse resolution for a large world map.

Gustafsson and Björklund [3] are one of the few publishedworks that focus explicitly on wind in games. They basetheir work on Stam[14] but still favour pre-computing thewhole simulation offline instead of running it in real-time. Theauthors deem it too expensive to use a real-time simulationon a multiplayer game which justifies the precomputation,however there are no details on what this cost really entails,and the authors suggest that a real-time implementation canstill be explored. This is a cost that may not be relevant toimplementing Wind in Veloren, especially in the single-playermode.

The algorithmBecause this thesis is based on the the method by Stam [14]with a few modifications, a short description of the algorithm isprovided below. With this algorithm, the Navier-Stokes Equa-tions (Fig 2) become a stable, iterative process. The readerdoesn’t need to develop an understanding of the mathematicalaspect of the equations; these are only shown to indicate howeach term in the equations translates to an iterative step in thealgorithm.

The velocity equation (Fig 2 a) represents the change of windvelocities over time in the presence of a source, like a fan or airdraft. The density equation (Fig 2 b) represents how a density(for example a cloud of particles) behaves over time. Discreteobjects like a leaf or a glider can be directly affected by thevelocities, while complex multi-particle objects like smokeor clouds are usually represented as densities as it can be

10https://www.gdcvault.com/play/1026404/Wind-Simulation-in-God-of

3

Figure 2. Compact version of the Navier Stokes equations showing a)Velocity equation b) Density equation. Figure modified from Stam [14]to highlight the steps.

Figure 3. A 3D vector field (for example a grid with wind velocities)where every point in space (grid cell) has am associated 3D vector (bluearrows).

computationally expensive to model individual particles. Bothequations depend on the sources added, how the velocitiesor densities diffuse around the space, and how the velocitiesadvect or "push" the air around.

Instead of a continuous space, a discrete grid is used whereineach cell represents a section of the space that has valuesfor velocity and density. This can be illustrated for windvelocities in Fig 3. With every simulation loop, the values inthis grid are updated for each cell. In this algorithm however,one-dimensional arrays are used for efficiency: one for eachcomponent of the velocity and one for the density. In 3Dthis means 4 one-dimensional arrays. This is due to howthe process updates the grid, which benefits from having forexample the x component of all of the cells continuous inmemory[3].

In the real world, the wind would change as a continuous effect,meanwhile in the algorithm, a sequence of steps is performediteratively, corresponding to each of the terms of the equationsin Fig 2: Adding sources, diffusing and advecting, with theaddition of a projection step for velocity fields in order to

ensure mass-conservation. The algorithm in its basic form isshow in Fig 4, and the steps described below.

Add SourcesAdding sources refers to injecting either a force (as a changein velocity), or injecting mass (as a change of density). Thisis done directly into the relevant cell in the grid. For examplea fan can be defined for a grid cell, which injects a certainamount of wind velocity with each update.

DiffuseAfter adding sources, the velocities and densities spread tothe adjacent cells at a certain diffusion rate. Each fluid canhave a certain viscosity which determines how easily the fluidspreads, giving the effect of a thinner or thicker fluid. Thechosen algorithm uses a Gauss-Seidel relaxation to solve theequation system that forms in this step, but other solvers canbe used. The Gauss-Seidel solver has a variable iteration countwhere higher counts result in more accurate results[10]. Forthe purpose of the game, where accuracy is less important thanthe visual effect and speed, this number can be kept low.

AdvectAfter diffusing, the velocities and densities will be pushedalong the velocity field. To illustrate the difference with theprevious step, the reader may think about how particles canstill spread uniformly (diffuse) in the air even in the absence ofwind, but can also be pushed by the wind in a certain direction(advection). For this, a linear backtrace is used to calculatehow each grid center has moved from a previous location.

Add sources

Diffuse

Advect

Project

Project

Figure 4. Steps in the simulation algorithm showing the steps from theNavier Stokes equations plus a Project step.

ProjectBecause each component of the velocities (x, y and z) are cal-culated separately, the resulting field is not mass-conserving.This section makes use of a mathematical technique calledHodge decomposition as well as a Gauss-Seidel relaxation.

More details about this algorithm can be found in the source[14].

METHODAfter the theoretical review, design considerations were madefor a simulation based on the chosen algorithm, which couldresult on a minimally functional simulation that could allowevaluation. A preliminary stand-alone implementation was

4

made first, which allowed the selection of relevant indepen-dent variables, while observing the general behaviour of thesimulation. Following this, the implementation was integratedinto Veloren and the evaluation phase was executed on theintegrated simulation.

Simulation designIn order to adapt the algorithm to Veloren, the following vari-ables were considered:

Grid sizeThe grid size determines the spatial resolution of the simula-tion, or how much in-world volume corresponds to each gridcell. A high resolution means that each grid cell represents asmaller volume of the world.

Since a finite grid size is needed, I limited the vertical heightcovered by the simulation to the size of the tallest mountainsin-game, or around 2 km (211 blocks). A coarse grid no largerthan 256 x 256 x 4 (218) cells was chosen as an acceptablegoal. This resolution means that each grid cell covers a rect-angular cuboid 128 meters per side and 0.5 km high. Smallerand bigger sizes can be used to evaluate the impact of thisparameter on the performance. Spatial interpolation may beused to improve the visual effects.

This coarse resolution also allows for the storage of the wholegrid in 1 MB: (256 x 256 x 4) elements per array x 4 arrays,with each element in the array being a f32 decimal (32 bits). 2grids are needed at all times, to represent the previous state ofthe simulation, as defined by the original algorithm.

Simulation frequencyThis is how often the simulation is updated for the wholemap. Running the simulation once per tick would requireupdating up to 218 cells per tick. However, the simulation doesnot need to fully update every tick, and a lower frequency ofonce per second was chosen. This means that each simulationupdate also needs to be able to reflect that a full second haspassed, and may require temporal interpolation to smooth outthe behaviour of the wind between updates. If the course ofeach update can be divided among several frames, at a rate of30 ticks per second, it means that every tick, 1/30th of the 218

cells in the map can be updated. This means approximatelyonly 8000 cells would need to be updated per tick.

World boundariesThe boundaries represent what happens at the edges of thegrid and pertain to both the edges of the whole simulation andthe places where the simulation interacts with other objects.The base boundaries were defined for the edges of the grid,where air flow cannot escape.

In addition, a static boundary layer can be created using theheight map of the world, to prevent air flow from going forexample inside a house or straight through a mountain. Adynamic boundary layer can also be used for increased inter-activity where wind could be blocked for example by a largemoving creature.

Initialize WindGridAdd sources to WindGridstep_fluid()Render modified WindGrid

step_fluid()fluid.rs

windgrid.rs

WindGrid

main.rs

swapdiffuseswap

advect

swapdiffuseprojectswapprojectadvect

step_dens() step_vel()

Figure 5. Structure of the stand-alone simulation

Other parametersThe viscosity parameter given to the diffuse step would havethe effect of a thicker or thinner fluid. Although real-life valuesfor the viscosity of air could have been used, the algorithmdoes not specify units, so this was instead tested during thefirst stage of implementation. The number of iterations for theGauss Seidel solver was also tested during implementation.

Stand-alone implementationThe first implementation step involved building a custom fluidsolver to act as the core of the simulation. This implementationhowever was not built from scratch. Jos Stam[14] provideda suggested 2D implementation of his solver on C, whichhas been translated to other languages, including Rust. Oneof these translations11 was used as a starting point due to itfollowing the original algorithm while facilitating the introduc-tion of certain Rust idiosyncrasies with memory managementlike ownership12. Another advantage of the procured stand-alone solver was a simple renderer based on Glium13, givingimmediate visual feedback and short compilation times.

I forked and modified the aforementioned solver14, adaptingit to 3D and making it compatible with Veloren, while re-maining stand-alone. An overview for the structure of thisimplementation and the roles of each submodule is shown onFig 5. Some functions were simplified; for example with thecreation of linear_solver() which abstracts the Gauss-seidelrelaxation step to be used by both the diffuse() and project()steps. The function trace_backwards() abstracts the linearbacktrace algorithm used by advect().

I created the WindGrid type to represent the 3D grid used forthe simulation. It also provides an access point for use out-side the module. For example, the WindGrid::get_velocity()

11https://github.com/tomc1998/rust-fluid_gdc0312https://doc.rust-lang.org/beta/rust-by-example/scope/move.html13https://github.com/glium/glium14https://github.com/Anavra/rust-fluid_gdc03

5

Common Crate

Server Crate

windsim system

windsim module

WindSiminterface

step_fluid()

WindGrid

mod.rsfluid.rs

wind_grid.rs

Client Crate

WindRequestWindUpdate

Figure 6. Architecture of the veloren integration

method allows an external module to sample the currently up-dated velocity at a given point. Each WindGrid has individualarrays for each of the four values: Three velocity componentsand one density. A macro is used to translate from the abstract3D representation to a 1D one (shown below in pseudocode):

get_index(x, y, z) {x + width *(y + length*z)

}

Where x, y and z indicate the position in the abstract 3D gridwhich is translated into an index for a 1D array so that eachgrid cell has a unique index in the array.

No systematic measurements were made at this point, the focusbeing an initial exploration of the properties of the simulationas described in the previous section, the resulting visuals, anda simple frame rate output.

Veloren integrationFor the second implementation step, the game code of Velorenat version 0.8.0 was forked from the main repository15 andcompiled with cargo16 1.50.0-nightly. This fork was kept upto date with the original during the integration process upuntil version 0.9.0, in order to facilitate collaboration with thedevelopment community.

I used the stand-alone simulation implemented in the previousstep, and created additional structures and modules in order tointegrate the simulation into the game.17 I added the simula-tion itself to the server crate, while the client was put in chargeof receiving updates from the simulation through messengersdefined in the common crate and applying them on the maincharacter. The different parts of this integration are shown inFig 6 and described below.

15https://gitlab.com/veloren/veloren16Cargo is the default build system for Rust17The integrated simulation as a fork of Veloren is available here:https://gitlab.com/oresavna/veloren/-/tree/wind-sim

ServerI created the system windsim on the server crate(server/sys/windsim.rs)18. This system is in charge of set-ting up and running the simulation, and is scheduled to runonce per server tick as most of the other existing systems.When the system is initialized along with the server, a Wind-Sim datastructure is constructed. The WindSim struct iscustom-made for this thesis and contains a WindGrid, andvariables to control the simulation size (blocks_per_cell) andfrequency(ms_between_ticks). The WindSim implementationis an interface that adds abstraction for the internal WindGridallowing for example the conversion from world coordinates togrid coordinates, and the access from outside the module withfunctions such as get_velocity() and add_velocity_source().The WindGrid datastructure is in essence the same as theone implemented on the stand-alone simulation, containing4 boxed arrays: one for densities and the rest for velocities.The arrays are boxed to allow them to be placed in the heapand manipulated. The size of the grid is determined with theconstants X_SIZE, Y_SIZE and Z_SIZE in wind_grid.rs.

When the system windsim runs each server tick, velocitysources are added to the grid and the tick() function is called,which in turn runs the function step_fluid() to perform onesimulation update. If the function tick() is called directly, thesimulation will run at the same frequency as the system, oronce each server tick. To lower the frequency, I used the con-stant MS_BETWEEN_TICKS in windsim.rs set to 1000 for asimulation frequency of once per second. The delta time (dt)parameter is also adjusted at this point, to allow the simulationto advance in phase with the frequency.

ClientThe new role of the client is primarily to send in its ownposition and receive and apply the wind velocity to itself. Noextended system was implemented on the client side. Forthe client-server communication, the following sequence isperformed:

1. The client sends its position with a WindRequest message.

2. The server receives the message, retrieves the wind velocityfrom the simulation for the given position, and sends backa WindUpdate with the updated velocity.

3. The client updates the main character’s velocity as long asthe player is in contact with the air (For example, not whenswimming).

The wind simulation system as currently implemented is ableto notify all entities of the wind velocity at their current posi-tion. The main physics system (in the common crate) decideshow this information is used.

EvaluationThe integrated simulation was evaluated on Veloren 0.9.0. Nofurther updates were added from the main game during theevaluation phase. Tracy traces were recorded, for both theserver and client sides. A higher focus was given to the server

18https://gitlab.com/oresavna/veloren/-/blob/wind-server/server/src/sys/windsim.rs

6

Machine 1 (M1)

CPU AMD Ryzen 5 1600 @ 3.2GHzRAM 16 GB DDR4GPU AMD Radeon RX570OS Linux 5.10-MANJARO x64Machine 2 (M2)

CPU AMD Ryzen 5 2600 @ 3.4GHzRAM 16 GB DDR4GPU GeForce GTX 1070OS Linux 5.11-NIXOS(Okapi) x64

Table 1. Specifications for the machines using during evaluation.

crate due to it running the main simulation. Mean FPS wasused as the main dependent variable for this study accordingto the research question, while grid size and simulation fre-quency were used as the independent variables after observa-tions made on the stand-alone implementation. Details aboutthe evaluation setup and the evaluation tools are describedbelow.

SetupA server and a client for Veloren were set up locally on two dif-ferent machines, each its own server and client. The machinesused had the specifications listed in table 1. Two separate gitbranches with the same version of Veloren were used, oneincluding the integrated simulation (wind-sim branch), andone unmodified (master branch).

The command-line version of the server (veloren-server-cli)was used to facilitate evaluating the server and the client sepa-rately. The compilation commands that allow the Tracy mea-surements, and the settings for the client are shown on ap-pendix A. Each Tracy measurement was saved as a file.

Baseline tracesThe baseline evaluation was done on the unmodified masterbranch (no simulation implemented). For the server evaluation,the client was not running. For the client evaluation, twoversions were recorded, one where the player was idle duringthe whole measurement, and one where the player was activelyflying/gliding.

Evaluation tracesEvaluation traces were recorded on both the client and theserver on the wind-sim branch containing the simulation. Theduration of each server trace was approximately 10 minutes,while each client trace was recorded for between 20 and 30minutes, which was considered long enough for the FPS tostabilize.

The server traces were recorded at 8 different grid sizes, fora simulation running once per tick and then for a simulationrunning once per second. The grid sizes were modified bychanging three constants, one for each dimension. For thisstudy however, the vertical (z) size was not changed, and the xand y sizes were kept equal, and are represented by the letterN in this report. This way, a grid size of 256 m x 256 m x4 m corresponds to N=256. The simulation frequency wasalso controlled by changing a constant, but only frequencies of

once per tick (tick) and once per second (sec) were recordedfor all grid sizes. Most traces were repeated both in the samemachine and on the 2 different machines.

The client traces were recorded for the simulation with anidle player and then with a gliding player. For the idle playerthe game was left to run in the background. For the glidingplayer, active player input was needed to keep the glider inthe air while wind sources were added by the system fromthe western edge of the map and randomly changing windangles. The client traces were all recorded with the grid size256x256x4 (N=256), but with both frequencies once per tickand once per second.

RESULTSThis section describes the results from the stand-alone windsimulation and the performance evaluation for the integratedsystem.

The stand-alone implementationThis preliminary implementation19 showed that increasing thegrid size lowered the FPS, while decreasing the simulationfrequency was associated to an increase of FPS for a givengrid size. An example of the visual effects for a simulation ofN=256 is shown in Appendix B. The viscosity parameter hada visible effect on the perceived thickness of the fluid, but noeffect on performance. A value of 0.1 was preliminary chosenfor the integrated simulation. Adding sources in differentdistributions did not appear to affect the performance. Thenumber of iterations in the Gauss-Seidel solver did not seemto have a clear impact on the visuals, and the minimum value(1) was chosen. These results allowed for the selection ofindependent variables to be reduced to grid size and simulationfrequency for the evaluation stage of the study.

Evaluation of the integrated implementationA total of 50 traces were recorded for the server and 16 forthe client using the two machines. All measurements for thesame combination of grid size and frequency were repeatedfor the server, but only presented once for each category as theaverage value. The mean and median FPS, as well as the totaltime percentage for each trace represent a cumulative resultover the duration of each trace.

Baseline tracesTable 2 shows the baseline measurements for both the serverand the client. Note that for the server, 30 is the fixed maxi-mum frame rate, meanwhile, the client has unlimited framerate.

Crate Mean FPS Median FPS NotesServer 30 30 No client runningClient 166 151 Player idleClient 206 199 Player gliding

Table 2. Baseline traces for server and client where no simulation is run.

19Stand-alone implementation https://github.com/Anavra/rust-fluid_gdc03.

7

Mean FPS Median FPS Total time (%)N tick sec tick sec tick sec

- 30 30 30 30 0 064 29 29 30 30 18 0.9

128 29 29 30 30 65 2.9192 16 28 14 30 91.6 6.3256 13 27 15 30 94.6 9.8320 8 26 8 30 95 12.7384 5 24 5 30 95.6 18.7448 4 23 4 30 96.4 25.9512 3 20 3 30 96.2 33.2

Table 3. Machine 1. Evaluation traces for the server at different gridsizes and frequencies. N represents the grid size, where the full size isN*N*4. Total time is the percentage of time the server spent on the sim-ulation. The first row indicates the baseline.

Mean FPS Median FPS Total time (%)N tick sec tick sec tick sec

- 30 30 30 30 0 064 29 29 30 30 8.2 0.4

128 29 29 30 30 34 1.2192 29 29 30 30 79.3 2.8256 17 28 17 30 94.4 5.4320 9 27 10 30 95.8 9.5384 6 26 6 30 96 15448 4 24 4 30 96.2 21.5512 3 22 3 30 97.9 28.4

Table 4. Machine 2. Evaluation traces for the server at different gridsizes and frequencies. N represents the grid size, where the full size isN*N*4. Total time is the percentage of time the server spent on the sim-ulation. The first row indicates the baseline.

Evaluation traces for the serverThe performance evaluation for the wind simulation imple-mented on the server crate showed that increasing the grid sizeis related to increasingly higher performance cost, while de-creasing the simulation frequency is associated to a decreasedeffect of the size on these performance costs. The performancecost here is represented by how much the FPS drops from itsbaseline value. Fig 7 shows the results for mean FPS for eightdifferent grid sizes between N=64 to N=512, plus the baselineresult. The graph shows a sharp drop for the simulation run atonce per tick (red), the drop beginning at N=128 for machine1(M1) and at N=192 for machine 2(M2). The simulation runat once per second (blue) shows a milder impact on the meanFPS for both machines. Machine 2 had a consistently betterperformance over the different sizes and frequencies. For themeasurements at once per tick, it can be seen in Tables 3 and 4,that although the Mean FPS is affected even at the lowest gridsize, the median FPS is still 30 up until an inflection point be-fore which most frames have been kept at baseline levels. Forthe measurements at once per second, the Median FPS stayedat 30 for all grid sizes. The total time percentage however doesshow a steady increase of how much time is dedicated to thesimulation as the grid size increases, even when the simulationruns at once per second.

64 128 192 256 320 384 448 5120

5

10

15

20

25

30

N

Mean FPS

BaselineOnce per tick - M1Once per tick - M2

Once per second - M1Once per second - M2

Figure 7. Mean FPS for different grid sizes and frequencies. N repre-sents the grid size, where the full size is N*N*4

Evaluation traces for the clientTable 5 shows the average and median FPS for the client onmachine 1 according to grid size and simulation frequencyfor both an idle and a flying player. These measurementsshowed fluctuations not seemingly associated to the presenceor absence of the simulation.

From the player perspective, the presence of wind enablessoaring and introduces an additional challenge of compensat-ing for the relative wind to maintain a desired course. Thewind flow is smoother with the once-per-tick simulation, andwith sharp changes in the once-per-second simulation. Entitiesaround the player’s position can also be seen pushed or carriedaway by the wind.

Frequency Mean FPS Median FPS Notes- 166 151 Idle playerOnce per sec 145 125 Idle playerOnce per tick 172 133 Idle player- 206 199 Flying playerOnce per sec 163 154 Flying playerOnce per tick 214 185 Flying playerTable 5. Client performance according to simulation frequency for asimulation of N=256. Where no frequency is given it means the baseline(no simulation)

DISCUSSION

ResultsFor the server, the increased costs with grid size and decreasedcosts with simulation frequency are attributed primarily to thenature of the problem, which despite the iterative optimiza-tions introduced by the algorithm, still involves a linear system

8

of equations with as many unknowns as grid cells, which re-quires iterating over each cell[13]. This means that for eachiteration over the whole grid, the time complexity grows lin-early with the size of the grid, which is given by the product ofthe size of each dimension, in this case (N*N*4). With the zdimension being 4, much smaller than N, the time complexityof each iteration is close to a 2D implementation, and in theorder of N2. This seems in line with the results at once pertick, except for lower grid sizes where the FPS was closer tothe baseline until a threshold was crossed and the FPS begandropping sharply afterwards. The presence of this threshold isattributed to the frame time not being at full capacity beforethis point, the increased computations able to fit during thealready available time. This is confirmed by the total timepercentage which began its sharp increase even at lower gridsizes, quickly reaching above 90% of the total time. The effectof grid size on performance explains how previous works haveneeded to either run the simulation offline or in smaller sec-tions[3], even when the cost was not measured in these papers.Jos Stam[14] even qualified the efficiency of his method with"reasonable grid sizes" for real-time implementations, but themeaning of reasonable is hard to establish without consideringthe goals and the equipment involved. The difference betweenmachines can indicate that a powerful enough server couldeasily cover the costs for my goal size of 256, while this costwould be much less reasonable for the client. The cost formemory and network were not systematically measured butseemed insignificant, even in the used machines.

When the frequency was decreased to once per second, thebehaviour in terms of mean FPS seemed more promising,especially when the median FPS is taken into account, showingthat most of the frames stayed at baseline levels. This meanshowever that once per second, a longer frame occurs, whichis not an ideal situation, and can result in the player beingaffected, although these effects are harder to measure. Evenif the performance were not affected, given a more powerfulserver, the fact that the simulation is being run at a lowerfrequency had direct effects on how smooth the wind felt forthe player. This can however be solved with interpolation,which was not implemented at the time.

MethodThe chosen algorithm[14] is from 2003, and although exten-sively cited, it is popular because of its availability, not becauseit’s optimized for all applications [3]. Other methods werereviewed, although not extensively enough to affect imple-mentation. The chosen algorithm is also self-contained, doesnot rely on external libraries, and can be extended in a variednumber of ways. In this paper the extensions involved a modi-fied translation to Rust and a naive addition of a small thirddimension, and any of these steps could be optimized.

Developing a stand-alone implementation simplified the pro-cess, but having two implementation phases and an extensiveevaluation phase made it necessary to limit optimization andfeatures to a minimum, due to time constraints. The poten-tial optimizations and features could significantly improve theoutcomes.

When it comes to the second implementation phase, the ma-jor challenge consisted in finding an appropriate placementfor the simulation, taking into account the architecture of thegame. Veloren is a game in pre-alpha at the time this thesis iswritten, with quickly changing features and insufficient cen-tralized documentation which added a steep learning curve.While it was possible to implement the simulation directly onthe client crate, I wrote this off as not being representativeof something that could be added to the real game, which isultimately multiplayer and networked. An implementationon the common crate was also attempted, but this causedthe simulation to run twice, once for the server and once forthe client, and was put on hold in favour of a server-basedimplementation. Gustafsson et. al [3] rejected a real-timesimulation for networked games with the implication that eachplayer would need to run a separate simulation, however thisis solved specifically for Veloren by running it on the servercrate, and sending updates to the players. In retrospect, theplacement of the simulation in the server is the best optionin the long run, but it also introduced unplanned challengeswith learning about network-related considerations and a re-structured evaluation: The system is so server-heavy that theclient-side evaluations became somewhat superfluous, or atleast intended for a separate study. A simple client implemen-tation could have facilitated the evaluation phase, which isonly based on FPS cost.

Because this is an open-source game, it is intended that anyother developer may replicate the results of the evaluation,modify the code and compare the results. This report shouldinclude all the versions of every component involved, and thefull code is available for download and published with a GPL-3 license. The trace files are large but available by request ifneeded. The code for the solver itself (fluid.rs) is, just like theoriginal implementations, entirely self-contained and doesn’tadd any dependencies that could render it obsolete or unstable.Using machines with similar profiles with the same evaluationtool is expected to yield similar results.

Only two personal machines were used for the evaluationwhich means that there’s a limitation on how much the resultsrepresent the performance cost of the simulation in other cases.Running the simulation in one of the production servers forthe live game, would have given a clearer picture of the impli-cations of this cost, but due to time constraints this was notdone.

When it comes to validity, the program used to measure thetraces (Tracy) cannot be guaranteed to reflect fully accurateresults. Tracy is also an overhead: the release version ofVeloren has Tracy disabled. These concerns are mitigatedby having a baseline measurement for each case, and by notmaking assumptions about absolute performance but insteadabout relative performance differences between the baselineand evaluation traces on the same machine.

Only a limited number of traces were taken which poses alimitation on the validity of the resulting function which de-scribes the performance cost, as the measurements becomemore vulnerable to external factors. This is mitigated by gath-ering traces over long times and by repeating traces for the

9

same conditions. This is also mitigated by using more than onemachine for evaluation. Despite this, this thesis is not meant tobe a large scale study on performance on a established systembut the preliminary evaluation of a proof of concept.

Besides the benefits on reproducibility, working on Velorenalso deals with sustainability, hopefully encouraging the workwith Open Source projects and showing how this can result ina large number of useful contributions that have already madethe game what it is. A project made in this manner has higherchances of growing even if individual contributors may leavethe project.

CONCLUSIONA working real-time wind simulation was designed, developedand integrated in Veloren. It successfully affects the playerwhen gliding and other objects around the player. Since theaddition of wind in some form has been anticipated, it alreadyaffects the aerodynamic forces applied to each entity basedon relative airflow without further modification. This subse-quently has a direct effect on gameplay mechanics such asgliding, winged flight, aerostat travel, free-falling and, to alesser degree, general ground-based movement.

The current simulation suffers however from a performancecost highly dependent on grid size. The effect of grid sizeon performance is not easy to overcome as it’s based on thenature of the problem. A simulation running at once per tickwith the goal grid size of N=256, has a performance costwhich is not acceptable for the personal machines used in thisstudy. However the simulation was implemented on the server,allowing for the possibility of more powerful machines takingon the cost, while allowing players to reap the benefits. Withthis set-up, the client-side is not affected, regardless of gridsize, due to always receiving the same type of information ina message-exchange system.

To mitigate server costs, a simulation running at once per sec-ond is significantly more feasible than one running at onceper tick, even for less performant machines, but additionaloptimizations may be required to minimize the risk of a singleprolonged frame time, and sharp variations in flight. A pro-longed frame time, even only once per second, is not in linewith the goals of a real-time application, potentially causingunpredictable delays in other systems. To prevent the bulkof the simulation from happening on a single frame, and goaround the grid-size limitation, the update process could besplit between frames, either so that 1) smaller sections arecalculated at the time or 2) calling the simulation tick asyn-chronously. The first option involves a careful handling ofthe boundary conditions to keep different sections connected,while the second involves making sure that no partial updatescan be sent to the client, for example the status of the gridbetween the diffusion and the advection steps.

More powerful servers may not suffer a prolonged frame time,but the effect on the player also needs to be considered. In-terpolation between updates and sampled positions could beused to define gradients for smooth transitions across the lowersimulation frequencies and larger distances.

While the implementation is not ready to be released as a livefeature, it has potential and due to its structure and modular-ity, it should be easy to modify and optimize. Although notdirectly measured, the memory and network costs seem tobe very low for this implementation in its current state. Aninteresting study would be to test this implementation on alive server with a player load.

Given a functional wind simulation, many features wouldbecome possible. Sailing ships, boats and rafts may be intro-duced and would rely on wind to enable water-based travel.By extending the aerodynamics simulation, these terrain-likeentities could possess sails that may be controlled by anglingwith respect to the wind to provide thrust, similarly to theway gliders currently work. Existing particle effects such asfalling leaves and snow could be made dependent on wind todetermine their general direction of movement. By extendingthe sever-client messages to enable polling the wind grid atarbitrary positions and retrieving fluid density, these could beused to affect how volumetric effects such as clouds, mist anddust change over time.

REFERENCES[1] Thomas H Cormen, Charles E Leiserson, Ronald L

Rivest, and Clifford Stein. 2009. Introduction toalgorithms. MIT press.

[2] Joel H Ferziger, Milovan Peric, and Robert L Street.2020. Basic Concepts of Fluid Flow. In ComputationalMethods for Fluid Dynamics. Springer, 1–21.

[3] Christoffer Gustafsson and Filip Björklund. 2020. WindSimulation in Networked Games. (2020).

[4] Antony Jameson. 1995. Optimum aerodynamic designusing CFD and control theory. In 12th computationalfluid dynamics conference. 1729.

[5] SS Khalafvand, EYK Ng, and L Zhong. 2011. CFDsimulation of flow through heart: a perspective review.Computer Methods in Biomechanics and BiomedicalEngineering 14, 01 (2011), 113–132.

[6] Pierre Gilles Lemarié-Rieusset. 2018. The Navier-Stokesproblem in the 21st century. CRC Press.

[7] Youquan Liu, Xuehui Liu, and Enhua Wu. 2004.Real-time 3D fluid simulation on GPU with complexobstacles. In 12th Pacific Conference on ComputerGraphics and Applications, 2004. PG 2004.Proceedings. IEEE, 247–256.

[8] Michael Long and Carl Gutwin. 2018. Characterizingand modeling the effects of local latency on gameperformance and experience. In Proceedings of the 2018Annual Symposium on Computer-Human Interaction inPlay. 285–297.

[9] Miles Macklin and Matthias Müller. 2013. Positionbased fluids. ACM Transactions on Graphics (TOG) 32,4 (2013), 1–12.

[10] Sandip Mazumder. 2016. Numerical methods for partialdifferential equations: finite difference and finite volumemethods. Academic Press.

10

[11] Matthias Müller, David Charypar, and Markus Gross.2003. Particle-based fluid simulation for interactiveapplications. In Proceedings of the 2003 ACMSIGGRAPH/Eurographics symposium on Computeranimation. Citeseer, 154–159.

[12] Robert Nystrom. 2014. Game programming patterns.Genever Benning.

[13] Jos Stam. 1999. Stable fluids. In Proceedings of the 26thannual conference on Computer graphics andinteractive techniques. 121–128.

[14] Jos Stam. 2003. Real-time fluid dynamics for games. InProceedings of the game developer conference, Vol. 18.25.

[15] Kim Tae-yi and Kim Tae-yong. 2006. Real-Time andInteractive Water Simulation using PrecomputedNavier-Stokes Equation. In 2006 InternationalConference on Hybrid Information Technology, Vol. 2.IEEE, 668–672.

[16] Johanne Zadick, Benjamin Kenwright, and KennyMitchell. 2016. Integrating real-time fluid simulationwith a voxel engine. The Computer Games Journal 5, 1(2016), 55–64.

11

APPENDIXA. SERVER AND CLIENT SETTINGSThe following command was used to compile and run theserver with Tracy:

$ cargo -Zunstable-options run --binveloren-server-cli --features tracy,simd--profile no_overflow -- --no-auth -b

To compile and run the client to work with Tracy, the commandbelow was used:

$ cargo -Zunstable-options -Zpackage-features run--no-default-features --features tracy, gl, simd--profile no_overflow

Once the game’s main screen was visible, the client was con-nected to the server by entering localhost:14004 and thenpressing the Multiplayer button, while leaving the other fieldsempty as seen in Fig 8. The default settings were used exceptfor maximum FPS which was changed from 60 to unlimited.These settings are accessed by pressing the ESC key, thenchoosing Settings > Graphics. Figure 9 shows the client set-tings used for Machine 1.

Figure 8. Client login information to connect with a previously addedadmin user to a local Veloren server

Figure 9. Graph settings used on Machine 1 for the client.

12

B. STAND-ALONE SIMULATIONThe following are screenshots of the stand-alone simulationwith varied sources and resolutions. The stand-alone simula-tion shows a 2D slice of the 3D simulation. The colors allowfor the visualization of the wind flow around a space.

Figure 10. N= 256

Figure 11. N= 256

Figure 12. N= 92

Figure 13. N= 92

13