Improving rendering times of Autodesk Maya Fluids using ...271956/FULLTEXT01.pdf · for people...

Department of Science and Technology Institutionen för teknik och naturvetenskap Linköping University Linköpings Universitet SE-601 74 Norrköping, Sweden 601 74 Norrköping

LiU-ITN-TEK-A--08/121--SE

Improving rendering times ofAutodesk Maya Fluids using the

GPUJonas AnderssonDavid Karlsson

2008-12-08

LiU-ITN-TEK-A--08/121--SE

Improving rendering times ofAutodesk Maya Fluids using the

GPUExamensarbete utfört i medieteknik

vid Tekniska Högskolan vidLinköpings universitet

Jonas AnderssonDavid Karlsson

Handledare Fredrik AverpilExaminator Mark Eric Dieckmann

Norrköping 2008-12-08

Upphovsrätt

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/

Copyright

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/

© Jonas Andersson, David Karlsson

Abstract

Fluid simulation is today a hot topic in computer graphics. New highly opti-mized algorithms have allowed complex systems to be simulated in high speed.This master thesis describes how the graphics processing unit, found in mostcomputer workstations, can be used to optimize the rendering of volumetricfluids.

The main aim of the work has been to develop a software that is capableof rendering fluids in high quality and with high performance using OpenGL.The software was developed at Filmgate, a digital effects company in Goteborg,and much time was spend making the interface and the workflow easy to usefor people familiar with Autodesk Maya.

The project resulted in a standalone rendering application, together with aset of plugins to exchange data between Maya and our renderer.

Most of the goals have been reached when it comes to rendering features.The performance bottleneck turned out to be reading data from disc and thisis an area suitable for future development of the software.

Keywords: Volumetric rendering, Fluid simulation, Maya, GPU, OpenGL,GLSL.

Andersson, Karlsson, 2008. i

Acknowledgements

We would like to thank our supervisor Fredrik Averpil and our examiner Mark EDieckmann. We would also like to thank Hakan Blomdahl and Mikael Hakanssonat Filmgate for helping us out whenever we got stuck.

Andersson, Karlsson, 2008. iii

iv Chapter 0. Acknowledgements

Contents

Acknowledgements iii

1 Introduction 11.1 Purpose and motivation . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem description . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 32.1 Maya . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Scene Graph . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Fluid simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Volume rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.1 Ray casting . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.2 Marching cubes . . . . . . . . . . . . . . . . . . . . . . . . 52.3.3 Shear warp . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Rendering polygonal objects . . . . . . . . . . . . . . . . . . . . . 62.5 OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5.1 GLSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.6 OpenEXR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Implementation 93.1 Maya plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Fluid data . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.2 Scene data . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.3 Mel interface . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Ray casting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.1 Multiple fluids . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Shadows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.1 Fluid shadowing . . . . . . . . . . . . . . . . . . . . . . . 143.3.2 Sampling density from fluids . . . . . . . . . . . . . . . . 143.3.3 Sampling density from meshes . . . . . . . . . . . . . . . 143.3.4 Mesh shadowing . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 Hold out objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.5 Motion blur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.6 Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.7 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.7.1 Custom controls . . . . . . . . . . . . . . . . . . . . . . . 193.7.2 Main layout . . . . . . . . . . . . . . . . . . . . . . . . . . 203.7.3 File-menu options . . . . . . . . . . . . . . . . . . . . . . 21

Andersson, Karlsson, 2008. v

vi Contents

3.7.4 The viewport . . . . . . . . . . . . . . . . . . . . . . . . . 213.7.5 The timeline . . . . . . . . . . . . . . . . . . . . . . . . . 233.7.6 Object selection . . . . . . . . . . . . . . . . . . . . . . . 233.7.7 Fluid attribute editor . . . . . . . . . . . . . . . . . . . . 243.7.8 Mesh attribute editor . . . . . . . . . . . . . . . . . . . . 253.7.9 Render settings . . . . . . . . . . . . . . . . . . . . . . . . 263.7.10 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.7.11 The console . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Results 314.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.1 Differences from Maya . . . . . . . . . . . . . . . . . . . . 324.2.2 Technical issues . . . . . . . . . . . . . . . . . . . . . . . . 324.2.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Discussion 355.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A The test system 39A.1 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 1

Introduction

This report covers a thesis done at Linkoping’s University in 2008.The thesis project began with us contacting Filmgate[1], a visual effects

studio located in Goteborg. Filmgate consists of a group of talented artists,who work mainly with compositing and matte paintings, but also quite a few3D effects. Filmgate has been working on films including Arn - The KnightTemplar, Arn - The Kingdom at Road’s End and The Descent.

At the time when we contacted Filmgate, they had several incoming filmprojects which would require 3-dimensional fluid effects to be rendered. Theydid not have a complete work flow for this type of effects, because they didnot like the way of rendering fluids offered by Autodesk Maya - their only 3Dapplication at the time. It was therefore decided that we should develop arenderer that could make use of the complexity of Maya’s fluid engine but withbetter rendering times.

The rest of this chapter will define the purpose, motivations and goals forthe project.

1.1 Purpose and motivation

Fluid simulation is a hot topic in computer graphics today. New highly opti-mized algorithms have allowed complex systems to be simulated and renderedin real-time, which was not possible a couple of years ago[2]. Large modelingand animation packages now usually have their own, very general, fluid simula-tion implementation - allowing for a large amount of customization. There hasalso been a lot of progress in the field of GPU programming and moving taskstraditionally done by the CPU to the graphics processor[10].

The purpose of this thesis project has been to develop a standalone programthat combines the strength of the Maya Fluid solver with the rendering powerof the GPU. The simulation is performed inside of Maya, but is shaded andrendered separately. This allows the user to tweak the look of the fluid in a nearreal-time environment without the need to re-render to see the result. Thistogether with reducing the time needed to render the final animation will havea positive affect on the creative process.

Andersson, Karlsson, 2008. 1

2 Chapter 1. Introduction

1.2 Problem description

The program should be able to render fluids with results, equal to, or betterthan Maya. Rendering features such as motion blur, shadows from geometryand self shadowing have a big impact on the result and should be supported.

The workflow should be optimized such that the complexity added by using astandalone program will be kept at a minimum. In places where user interactionis needed, the interface should look and behave similar to Maya, to make it aseasy as possible to use both of the programs in parallel.

Chapter 2

Background

In this chapter we give a brief background to some programs and concepts thatwill make it easier to understand the rest of the report.

2.1 Maya

Maya is a high-end 3D computer graphics and 3D modeling package (Figure2.1) developed by Autodesk. Maya is used in the film and TV industry, as wellas for video games, architectural visualization and design. It was awarded anAcademy Award in 2003 for ”scientific and technical achievement”.

Figure 2.1: Screenshot of Maya 2008 running on Windows Vista.

The open architecture that Maya is built upon is one strong reason for itssuccess. A scripting language called Maya Embedded Language (MEL) is pro-vided, and a lot of the built in functionality and tools are written in this scriptinglanguage. It’s possible to save projects, including models and animation, as asequence of MEL commands (Maya ASCII) that can be opened and edited inany text editor. Besides MEL, Maya supports compiled plugins through anAPI and large parts, like the renderer or the user interface can be customizedor completely replaced to suit the workflow of the user.


4 Chapter 2. Background

2.1.1 Scene Graph

Every object and all modifications that are done to the scene, is described by anode in Maya’s scene graph (Figure 2.2). All nodes are by some path attachedto the scene’s root node and all nodes that have to be passed to get from anobject to the root node affects that object.

Figure 2.2: The scene graph keeps track of the relationship between all objectsand modifiers in the scene.

The scene graph and information about all nodes is fully accessible usingthe Maya API.

2.2 Fluid simulation

Fluid simulation is a tool used in the field of computer graphics to generaterealistic water, smoke, explosions and related effects. Most fluid simulations aredone using the Navier-Stokes[4] equations to describe the motion of the fluidover time. The equation is usually heavily simplified to allow for a quick andstable numerical solution[3]. This can significantly increase the speed of thesimulation in computer graphic applications, where a good looking result is agood result (Figure 2.3). Compared to other areas such as physics, engineering,or mathematics where a physically correct simulation is needed.

Figure 2.3: Fluid simulation demo from NVIDIA[5] running in real-time on theGPU.

2.3. Volume rendering 5

A fluid is often represented by a rectangular grid in either two or three dimen-sions. The time needed for simulation is then directly linked to the resolutionof the grid. It’s especially important to use as low resolution as possible whendealing with three dimensional fields. For example, a cube with side length Nwould result in N3 voxels.

The basic version of a fluid simulator contains a velocity field and a densityfield:

x, y, z ∈ N0 <= x, y, z < field resolutionvelocity(x, y, z) = V, V ∈ R3

density(x, y, z) = k, k ∈ R

The simulation is then often extended to contain other elements such astemperature or color. Maya Fluids supports four different attributes that affectsthe simulation - density, velocity, fuel and temperature.

2.3 Volume rendering

Volume rendering is a technique used to visualize two-dimensional projectionsof three-dimensional data sets. It’s mainly used to display images of X-Ray datafrom CT or MRI scanners, but the technique also has other applications, suchas terrain visualization and fluid rendering.

Below are several different methods used for volume rendering.

2.3.1 Ray casting

In volume ray casting, a ray is cast for each pixel in the output image. These raysoriginate from the eye point of the camera and are shot through their respectivepixel, in an imaginary image plane, and on through the volume of data. Whileinside the volume, the ray samples data at regular or adaptive intervals. At eachof these samples, a ray is cast towards each light source in order to calculatethe shading at that particular point of the volume. The ray ends when ithas passed through the volumetric object or once its accumulated density hasreached a value where nothing beyond that point will be seen. Ray castingprovides results of high quality, but can be quite slow in software. Though,since each ray is independent the algorithm is well suited for parallel structuressuch as the GPU, where real time rendering speeds have been achieved.

2.3.2 Marching cubes

The marching cubes algorithm[6] is used to render isosurfaces from volumedata. The algorithm proceeds through the volume by taking the eight diagonalneighbors of each voxel, forming an imaginary cube. The value of each of theseneighbors is then checked against the isosurface threshold and assigned a 1 if it’sinside the surface and a 0 otherwise. The resulting cube is then checked againsta precalculated array containing 256 possible polygon surface configurations(Figure 2.4).


Figure 2.4: The marching cube algorithm uses 15 unique cubes. All 256 possiblevariations can then be obtained by rotation and mirroring.

2.3.3 Shear warp

The shear warp algorithm[7] is a relatively new approach, which tries to simplifythe projection step by dividing it into a shear and a projection step (Figure 2.5).The algorithm starts by transforming the view transformation, such that thecamera gets an axis-aligned view of the nearest side of the volume bounding box.The slices of the volume are then sheared to allow the camera to still see all thevoxels it would have seen from its original position. The volume is then sampledinto a so-called intermediate image. This intermediate image is distorted andmust be warped to achieve the correct final image. The reason for moving thecamera is because the volume is stored in a run length encoded version fromeach axis aligned viewing direction. This results in a faster rendering step, butwith heavy memory consumption.

Figure 2.5: The shear step of the shear warp algorithm. The slices of the volumeare sheared according to the camera transformation.

2.4 Rendering polygonal objects

One common way of representing a 3d object is by using polygons. Any surfacecan be approximated by dividing it into a number of planar polygons (Figure2.6).

Many renderers, such as the hardware accelerated API’s OpenGL and Di-rect3D, are limited to rendering triangular polygons. This makes the renderingprocess much simpler and very fast.

Allthough some volume rendering techniques, like marching cubes, use poly-gons to render its data, it’s not suitable for rendering gaseous fluids, such assmoke and fire.

2.5. OpenGL 7

Figure 2.6: 3-dimensional object represented by planar polygons.

2.5 OpenGL

OpenGL is an environment for developing interactive 2D and 3D graphics ap-plications. It was released in 1992 and is today the industry’s most widely usedapplication programming interface (API) for real-time graphics. It can be usedon most desktop and workstation platforms and provides high visual qualityand performance.

OpenGL consists of over 250 different function calls and provides function-ality to create, transform and render polygonal objects. The rendering can becustomized and objects can be assigned texture maps, lighting properties, colorsetc.

The API is supported and accelerated by all of today’s GPUs from NVIDIAand ATI which leads to high performance on almost every desktop computer.

2.5.1 GLSL

Traditionally OpenGL has always used a fixed pipeline for rendering. A largenumber of functions allowed customization to a certain degree and worked wellfor most cases. Missing features could be added by supplying an extension tothe OpenGL Architecture Review Board[9] for validation and it would perhapseventually appear in the API.

The inspiration to GLSL came from shading languages such as the verypopular Renderman shading language[8], used extensively in the visual effectsindustry. A shading language gives low-level control of how the rendering isperformed. Instead of using built in functions to specify lighting, textures etc.,a shading language uses a shader to describe the rendering process. A shaderis basically a small program, a piece of text that calculates the color of therendered pixel.

Example - shader that uses a directional light source to calculate the color of the pixel:

void main(){

vec3 normal, lightDir;vec4 diffuse;float NdotL;

normal = normalize(gl_NormalMatrix * gl_Normal);lightDir = normalize(vec3(gl_LightSource[0].position));

NdotL = max(dot(normal, lightDir), 0.0);


diffuse = gl_FrontMaterial.diffuse * gl_LightSource[0].diffuse;

gl_FragColor = NdotL * diffuse;}

Shaders allow OpenGL to be used in ways it was not originally designed for.Using OpenGL for General-Purpose computation on GPU (GPGPU[10]) is anarea that has grown rapidly in the latest years and provides a lot of out of thebox-thinking about what GPU acceleration can be used for.

2.6 OpenEXR

OpenEXR is a high dynamic range image file format developed by the visualeffects company Industrial Light and Magic[11]. It has been used in many moviesincluding Harry Potter and Men in Black 2 and is currently the main image fileformat in all of ILM’s motion picture productions. ILM released OpenEXR tothe public in 2003 and it is now supported by most of the standard applicationsused in the business.

OpenEXR supports 32-bit floating point, 32-bit integer and a 16-bit floating-point format called ”half”. The format also includes three types of losslessimage compression algorithms; run-length encoding, ZIP compression and PIZcompression. A great feature of OpenEXR is its support for arbitrary numbersof channels. It can store specular, alpha, RGB, normals etc. in the same file,which makes it very useful for compositing.

The OpenEXR C++ API is free to use and includes functionality to readand write OpenEXR images, which makes it simple to support it in your ownsoftware.

Chapter 3

Implementation

3.1 Maya plugins

Maya is built around an open system where programmers can change existingfeatures or add new features using plugins.

There are several tools available to develop Maya plugins:

• Maya embedded language (MEL) - A powerful scripting language thatallows access to the most common operations.

• Python - A scripting language that provides an interface to MEL com-mands.

• API - A C++ interface that provides better performance than MEL, to-gether with low level access to Maya’s scene graph.

• Maya Python API - A scripting language that is based around the func-tionality of the API.

We needed a way to export the fluid simulation together with informationabout the scene that contains the fluid container. Using the API turned out tobe the best option because we needed the performance to be able to access alot of data. C++ was also a familiar environment for both of us.

3.1.1 Fluid data

A command plug-in for Maya was developed called exportFluid that exportedthe selected fluid container for each frame in the simulation. Each file containedinformation about the current transformation, size, resolution and content ofthe fluid container. The command was executed from Maya’s command line,together with arguments specifying the range of frames, which attributes thatshould be exported, a file path and a name.

Example:

exportFluid -atr density -atr temperature -startFrame 1 -endFrame 100 -path "e:/fluids" fluid01;

Output:

e:/fluids/fluid01_frame00001.bin


10 Chapter 3. Implementation

e:/fluids/fluid01_frame00002.bin...e:/fluids/fluid01_frame00100.bin

The size of the exported files can easily get very large. Exporting the density(8 bytes / grid point) for 100 frames of a 128x128x128 grid would consume 1.6GB of disc space and would result in very long loading times. This made usthink about ways to lower the size of the files, and led to the following decisions:

• Option to specify which attributes to export. A fluid simulation can con-tain density, velocity, temperature and fuel but might only need the den-sity and temperature when rendering.

• A kind of run length encoding (RLE) was used when exporting density,temperature or fuel. It encoded a sequence of zeros as the length of thesequence preceded by a minus sign.

Example:

Raw encoding: 1, 0, 0, 0, 1, 3, 5, 5, 1, 0, 0, 0, 0With RLE: 1, -3, 1, 3, 5, 5, 1, -4

This had a significant effect on the file size since large sections, especiallyin the beginning of the simulation, usually don’t contain any fluid. Athreshold was used to determine when a value should be considered to bezero, since it’s rare that a value is exactly zero.

• Exporting the attributes as an array of 32-bit floats. Maya uses 64-bitdoubles internally for representation but this precision wasn’t consideredto be needed in our application.

3.1.2 Scene data

A similar plugin named sceneDataExport was developed to export the scene.The command doesn’t have any options about what to export, instead it justtakes a range of frames, a path and a scene name as arguments and exportseverything in the scene.

Example:

sceneDataExport -startFrame 1 -endFrame 100 -path "e:/scenes" scene01;

Output:

e:/scenes/scene01_frame00001.scee:/scenes/scene01_frame00002.sce...e:/scenes/scene01_frame00100.sce

The plugin is limited to export polygonal objects, cameras and point lights.This provides a basic functionality but at the same time prevents the handlingof the scene from getting too complicated.

3.2. Ray casting 11

3.1.3 Mel interface

Besides the command line plugins created with the API Maya also provides aneasy way to create a corresponding user interface through the MEL scriptinglanguage (Figure 3.1, Figure 3.2). A script is then bound to the export-buttonthat generates and executes a command string based on the settings in theinterface.

Figure 3.1: The dialog for exporting scene data.

Figure 3.2: The dialog for exporting fluid data.

3.2 Ray casting

Volume ray casting is an algorithm where data is sampled along rays through avolume of data. Since the density outside the volume of data is always zero andtherefore does not contribute to the final output, it would be optimal to onlysample inside the volume. To achieve this, both points where the ray intersectsthe surface of the volume’s bounding box must be found, i.e. the entry and exitpoint.

Both the entry and exit points can be found by constructing a vertex-coloredbounding box around the volume of data. Each vertex in this bounding box willbe colored based on its position in the volume’s local space, i.e. the minimumvertex vmin = (xmin, ymin, zmin) will be colored black rgb(0,0,0) and the vertexvmax = (xmax, ymax, zmax) will be colored white rgb(1,1,1) and so on. Thisbounding box will then be rendered twice, in the same resolution as the final


output. The first time with back face culling activated, which will result in animage showing the sides of the box facing the camera. Since this image has thesame resolution as the final output and since one ray will be cast for every pixelin the final image, each pixel in this rendering of the bounding box representsthe starting point for a ray. The second time the bounding is rendered withfront face culling activated, resulting in an image representing the exit point foreach ray (Figure 3.3).

Figure 3.3: The bounding box used in the ray casting process rendered twice -once with back face culling (left) and once with front face culling (right). Eachpixel’s color represents a ray’s entry point into the volume (left) or exit point(right).

Once the entry and exit points for a ray are known, the length, directionand number of sampling steps of that ray can be calculated and the actual raycasting can begin. During this process the volume data will be sampled at evenintervals along the ray in a front-to-back order. At each step the opacity andthe lighting is sampled and accumulated to the pixel’s final color:

N = number of samplescolorfinal =

∑Ni=0 densityi · factori · colori

factor0 = 1factori = factori−1 · (1− densityi)

A feature of sampling front to back is that you can terminate the ray oncethe factor gets below a certain threshold, since the rest of the data will notsignificantly affect the final output. The ray will also be terminated if it passesthe depth sampled from the hold out depth map or once it reaches the exitpoint.

The rendering of the exit points and the actual ray casting process are com-bined in one GLSL fragment shader, while the entry points are rendered in aseparate shader and stored in a texture, as can be seen in Figure 3.4. The exitpoints could have been rendered separately as well, but then an extra texturewould have had to be stored and sent to the GPU.

3.3. Shadows 13

Figure 3.4: The ray casting is done by two GLSL shaders. The first one calcu-lates the entry point for each ray and stores it in a 2D texture. This textureis then sent, together with additional data, to the second GLSL shader whichcalculates the exit point for each ray and performs the actual ray casting.

3.2.1 Multiple fluids

If the scene contains more than one fluid, a new bounding box will be created,large enough to contain all volume bounding boxes in the scene. This new largerbox will be the one rendered in the first two steps of the ray casting algorithm.

3.3 Shadows

Shadows are essential in volume rendering to give an impression of depth in theimage (Figure 3.5). We implemented support for fluids shadowed by themselves,other fluids and polygon objects. We also added support for shadows casted byfluids onto polygon object for use in post-processing.

Figure 3.5: The resulting rendering of a fluid lit by two light sources.

This chapter gives an introduction to how shadows are calculated from vol-umes using ray casting. We also present our algorithm for converting polygon


objects to a sampled volume representation.

3.3.1 Fluid shadowing

In ray casting, shadows are calculated by tracing a ray from the point we arecurrently sampling to every light source in the scene (Figure 3.6). The amountof light is then used as an illumination factor for that point.

Figure 3.6: The amount of incoming light is sampled for every point along a rayto calculate the final color.

This can be a very time consuming process if the step size used for theray casting is small. We are rendering objects with a fixed resolution that arelimited in space, and we decided because of this to precompute the amount oflight for each point and store it in a shadow texture. This texture has the sameresolution as the fluid and is calculated by tracing a ray from every grid pointto the scene’s light sources.

The amount of light is calculated by sampling the density along a ray to findout how much light is blocked.

3.3.2 Sampling density from fluids

Sampling the density of a fluid is straight forward since we already have it storedin a 3D texture. So the actual sampling just consist of transforming from worldspace to texture space and reading value from the density texture.

3.3.3 Sampling density from meshes

Knowing when we are sampling inside of a polygonal object is problematic sincewe only have a representation of the shell around the object. We would thenhave to test for intersection with every polygon to see if we have penetratedthe object. This is not easily done in OpenGL since there is no ”scene”, justknowledge about the current primitive being rendered.

To solve this problem, we would like to sample the mesh and represent itusing a 3D texture. This way we could use the same approach that we used forfluids. A number of algorithms exists for doing this, but we decided to developour own algorithm that uses the GPU to increase the performance. The outlineof the algorithm is presented below.

3.3. Shadows 15

Mesh voxelization

The algorithm starts with a mesh and a 3D texture of a user defined size.The mesh is then rendered once for every slice, every step in z, of the texture.Each pass renders the object using orthographic projection[12] with the farclipping plane located at infinity and the near clipping plane located at a depthcorresponding to the current texture slice (Figure 3.7).

Figure 3.7: The camera set up for the mesh voxelization algorithm.

In the first version of the algorithm, the shading of the object was set torender front facing polygons black and back facing polygons white on a blackbackground. This way, everything of the mesh that is cut open by the nearclipping plane would end up as white in the 3D texture. Rendering the middlez-slice of a 128x128x128 voxelization of a torus would generate something similarto Figure 3.8 (colors changed for illustration purpose)

Figure 3.8: Torus intersected by the near clipping plane gives a cross-section ofthe object.

This worked well until we tried it with objects that were self-intersecting.In this case, a front facing polygon rendered inside of the object would renderblack and close the volume. This wasn’t a limitation that we wanted to enforceon the artists because of the time consuming task of fixing the models. To solvethis problem, we used the stencil buffer to get more information at each pixelthan we could get from our first binary white / black-approach. We configuredthe stencil buffer to increase when rendering back facing polygons and decreasewhen rendering front facing polygons. This allows the algorithm to check if thestencil value is greater than 0 and in that case draw the pixel as white.


3.3.4 Mesh shadowing

Shadows received by meshes are calculated by tracing a ray from the point beingrendered to all light sources in the scene. The process is divided into two steps.The first step renders all geometry using a shader that sets the color of thepixel to the position of the point being rendered (Figure 3.9). The result fromthe first step is then used to determine the shadowing of each pixel using raycasting.

Figure 3.9: The mesh shadowing shader is given a texture where the positionof each pixel in space is mapped from (x, y, z) to RGB.

3.4 Hold out objects

Hold out objects are objects that block the camera’s view of the fluid or partsof the fluid (Figure 3.10). If the hold out object is positioned in front of thefluid, the part of the fluid that gets blocked from view could easily be maskedout in compositing. But if the object, or parts of the object, is inside the fluidthat would not be possible. Therefore the hold out objects had to be includedin the rendering process.

Figure 3.10: A hold out object is used to block out parts of the volume.

We first attempted to implement hold out objects by voxelizing the polygonalobjects and then include them in the ray casting algorithm (see Shadows/MeshObjects for a description of the voxelisation algorithm). Although this worked,it did not yield an appealing quality unless unreasonably high voxel resolutionswere used.

Instead we decided to implement this by rendering a depth texture from thecamera and sending this texture to the ray casting shader. The ray casting

3.5. Motion blur 17

algorithm then samples the depth value and exits the ray once a pixel’s depthvalue is reached.

Since OpenGL’s built-in depth map isn’t linear, it could not be used as thedepth texture. To solve this, a simple GLSL shader was implemented that trans-forms the objects into eye coordinates and renders the depth value, normalizedbetween the near and far clipping plane.

3.5 Motion blur

Motion blur is the streaky, blurry effect that is often seen in photos of fast-moving objects (Figure 3.11). The effect occurs because a photo does not rep-resent an instantaneous time, but rather a period of time depending on thecamera’s exposure settings. Motion blur is a very important part of computeranimation because without it movements tend to look staggered. This is espe-cially true when dealing with compositions of animation and real video footage.

Figure 3.11: Motion blur appearing in a photo.

In computer animation, motion blur can be approximated by applying itas a 2D post-effect[13] since this is faster to calculate. We decided to use true3D motion blur instead, since this was mainly used in Maya by the artists atFilmgate.

Our implementation of motion blur is controlled by three parameters; shutterangle, offset and number of samples (Figure 3.12). The shutter angle rangesbetween 0 and 360 degrees and it determines the length of the exposure timewhich affects the amount of blur. The offset parameter ranges from 0.0 to 1.0frames and offsets the exposure period. This is used to control whether themotion blur should be calculated using the next or previous frame, or parts ofboth. The number of samples says in how many interpolation steps the exposuretime is divided. An example of a motion blurred hold out objects can be seenin (Figure 3.13).

The motion blur algorithm will, for each frame in the render sequence, stepthrough the exposure period with a step size equal to the exposure time dividedby the number of samples. For each step the scene is interpolated and rendered.The output is then weighted by the number of samples and added to the finalimage.


Figure 3.12: The offset and the shutter angle controls how adjacent frames areused to create the blur.

Motion blur pseudo code:

for each frame{

finalOutput = 0;

for each sample{

interpolateScene();tempOutput = render();finalOutput += tempOutput / numberOfSamples;

}

writeToImageFile(finalOutput);}

Figure 3.13: Hold out object without motion blur compared to the same objectrendered using 20 motion blur samples (shutter angle 270, offset 0.5).

3.6 Rendering

Once the user has configured all the rendering settings and clicked render, therendering loop starts. It will iterate through the time range specified in the ren-dering settings dialog. While rendering, three frames of data - the current, nextand previous, will be kept in memory in order to make motion blur calculationspossible. For each frame in the sequence, the fluids will be lit and renderedto an off-screen OpenGL framebuffer. The data in the framebuffer will then bewritten to an OpenEXR file. The next step calculates all shadows cast by fluids,in a similar manner, and stored it in an additional layer of the file. If motionblur is enabled each frame will be interpolated and rendered several times andthen blended together before being written to file.

3.7. User interface 19

3.7 User interface

The user interface of our application was designed to be fairly easy to use, butalso to have a somewhat modern and appealing look. Its layout and individualcomponents are similar to Maya. This will help users familiar with Maya to usethe program.

The development of the user interface has been done using Windows Forms[14],which is an API included as a part of Microsoft’s .NET framework. It works asa wrapper around the existing Windows API and provides access to most na-tive Windows interface elements. The Microsoft Visual Studio Express editions,comes with a designer interface for Windows Forms.

3.7.1 Custom controls

Throughout the project quite a few custom GUI controls had to be built, most ofthem since we chose not to use the standard Windows look. We developed newstyles for existing controls such as group boxes, text fields, menus, etc. Thoughwe also developed some new components since we needed to add functionalityto the GUI. These components were a 1D graph, a RGB ramp, a color picker,a timeline and a flow layout panel.

All custom controls were developed in C# using Microsoft Visual Studio C#2008 Express.

1D ramp

The 1D graph control maps floating point values along a graph, which can becontrolled by the user (Figure 3.14). With mouse clicks the user can add orremove control points and drag them around. The graph is then interpolatedlinearly between these control points.

The control was designed to be similar to Autodesk Maya’s correspondinggraph control.

Figure 3.14: Ramp used for one dimensional input.

RGB ramp

The RGB ramp control maps floating point values to a color (Figure 3.15). Theuser can add, remove or drag color control points along the ramp. The color ofthe control points can be changed using the color picker (see next session). Thecolor is interpolated linearly between the control points.

As for the 1D graph, this control was designed to resemble the correspondingramp in Autodesk Maya.


Figure 3.15: Ramp used for color input.

Color picker

The color picker is displayed when clicking a control point in the RGB ramp(Figure 3.16). A color can be chosen by either typing in RGB or HSL values orby using the hue/saturation circle together with the lightness ramp. In the circlethe saturation goes from 0.0 at the center to 1.0 at the rim. When changingthe lightness the colors in the circle get brighter or darker, except for at therim, where the colors always stay at medium lightness to better show the userwhat hue corresponds to what angle within the circle. It’s also possible to onlyaffect the saturation by holding down the right mouse button and dragging themarker. To only affect the hue, drag the arrow just outside the rim of the circle.

Figure 3.16: The color picker and the different input methods: 1. RGB andHSL values, 2. Hue / Saturation circle, 3. Lightness ramp.

3.7.2 Main layout

Figure 3.17 shows the main layout of the application. The layout consists of:

• Viewport - this is where all scene data, fluids, previews, shadows etc. areshown.

• Timeline - an interactive control that shows all imported fluids and theirrespective time range.

• Menu - contains options like save / open projects, open attribute editorsand viewport settings.

• Controls - controls the range of the timeline and the playback of the scene.


• Console - displays messages, warnings and errors.

Any additional content, like the attribute editors, are displayed in pop-upwindows.

Figure 3.17: The main layout of the application .

3.7.3 File-menu options

This menu contains all the commands needed to import files to the project aswell as options to save and load an existing project.

Import fluids

Fluids are added using the command File / Import fluid. This brings up a dialogwhere a Fluid data-file can be a imported. Any file of a simulation sequence canbe chosen and all files will be imported that are part of the same simulation.

Use scene

The command File / Use Scene brings up the scene selection dialog. The scenesequence is selected in the same way as fluids, any file that is part of the sequencecan be chosen and it will import the entire scene. Only one set of scene datacan be active at one time. Loading a second scene will replace the first.

Save / open project

The current state of the program, including scene files, fluid data, shaders andworkspace settings can be saved as a project file. The file contains references tothe imported scene and fluids, instead of storing the actual data. The formatfollows the XML standard and is possible to edit in a text editor.

3.7.4 The viewport

The viewport offers a perspective view of the currently imported data in thescene. It can be set to view the scene from an interactive user camera or fromany camera imported from Maya. While in user camera mode, the view can be


rotated, zoomed and panned.

Usage:

• Rotate: ALT + left mouse button

• Pan: ALT + middle mouse button

• Zoom: mouse wheel

The active camera can be set from the main menu, under Viewport / Camera.

Change view

The viewport can be set to three different view modes; orientation view, previewand shadow view (Figure 3.18). These options are available from the main menu,under Viewport / View mode.

The orientation view displays all imported objects. Polygonal objects arerendered, while only the bounding boxes of the fluids are shown. In this modeall objects can be selected by clicking them in the viewport.

In preview mode, fluids are rendered as in the final rendering, with shading,hold out objects etc. Although the sampling rate of the ray casting algorithmmight be set lower than in the final rendering process. Also, motion blur is notshown in the preview. While in preview mode, all frames visited will be cachedto allow for faster playback.

The shadow view mode displays a preview of all shadows, cast by fluids onpolygonal objects. This is what will be rendered to the shadow layer of the finaloutput.

Figure 3.18: The same scene viewed in orientation, preview and shadow mode.

Set background

A feature within the viewport is to set its background in preview mode. Thiscan be done from the main menu, under Viewport / Prev. background. Thereare three available options (Figure 3.19):

• Checker - sets the background to a checker board pattern in two shadesof gray.

• Set background color - displays a color picker from where the backgroundcolor can be chosen.


• Set background image - lets the user choose a Targa image sequence asbackground. A feature implemented to make it possible to preview thefluid together with the rest of the animation before rendering.

Figure 3.19: Example of the three available background styles.

3.7.5 The timeline

An important part of the application is the timeline (Figure 3.20). It’s a controlthat allows the user to set the current time frame by dragging the handle. Thetimeline also displays all currently imported fluids as individual layers. Theselayers show, for which time interval the imported fluids exists. Each layer canbe selected from the timeline control, which will result in its corresponding fluidbeing selected in the viewport. When a layer is selected in the timeline the usercan offset it in time by dragging it with the mouse. While dragging a layer itscurrent starting frame will be shown next to the mouse cursor to help the userposition it precisely.

Another functionality, within the timeline control, is the possibility to lockthe currently selected fluid at a certain frame. When a fluid is locked it will notchange from frame to frame but rather stay as it was at the frame it was locked.

Figure 3.20: The timeline shows currently imported fluid and their location intime.

3.7.6 Object selection

In order to control the attributes of an object it must first be selected. This canbe done in different ways:

• Selection Component - the selection component can be accessed from themenu. It contains a list of all selectable objects currently in the scene(Figure 3.21).

• Picking - objects can be selected by clicking on them in the viewport. Thiscan only be done when the viewport is in orientation mode


The picking algorithm works by transforming the objects’ 3D world coor-dinates into 2D screen space. For polygonal meshes the cursors position isthen checked against each 2D triangle. If the cursor resides inside any ofthe triangles the object gets selected. For fluids each line of their respec-tive bounding box is checked against the mouse position. If the cursor isclose enough to any of the lines the fluid gets selected. If the cursor ispointing at more than one object, the one closest to the camera is selected.

• The timeline - a simple way to select fluids is by clicking on their respectivelayers in the timeline.

Figure 3.21: The selection component.

3.7.7 Fluid attribute editor

The fluid attribute editor contains settings for how the fluid’s density, tempera-ture, fuel and velocity affects the rendering. It was designed to look and behavesimilar to Maya’s shading settings (Figure 3.22) and is divided into four areas:

• Opacity - controls the thickness of the fluid.

• Color - controls how an attribute will affect the color of the fluid.

• Incandescence - allows for assigning a color that is invariant to the amountof light that illuminates the fluid. This is used to give the impression thatthe fluid emits light (fire, glow etc).

• Shadow density - a factor that describes how good the fluid is at absorbinglight. A high value will result in a sharper looking fluid with lots ofshadows.

The opacity, color and incandescence all have the same set of options, thattogether with the ramp, controls the value used for rendering the fluid. Theexample below uses the opacity ramp, but the approach is the the same forcolor and incandescence as well (Figure 3.23).

The value that goes into the ramp is chosen from the input menu, and canbe either density, temperature, fuel or velocity. The value is first multiplied


Figure 3.22: The fluid attribute dialog next to Maya’s fluid shading settings.

Figure 3.23: A ramp is additionally controlled by specifying scale, input biasand output scale.

by the input scale and then subtracted by the input bias. This yields a valuebetween 0.0 and 1.0 that is mapped to the x-axis of the ramp. The correspondingramp-value is then multiplied by the output scale to get the resulting value.

Exporting settings

A fluid’s render settings can be quite complex and time consuming to reproduceif the same settings is to be used for several fluids. We therefore implementedthe option to save all settings as a shader XML-file using File / Save shader.The shader can then be loaded from any other fluid’s attribute editor using File/ Open shader.

3.7.8 Mesh attribute editor

The mesh attribute editor is used to control the polygonal mesh objects in thescene (Figure 3.24). It can be opened from the main menu under Edit / Attributeeditor.

From the mesh attribute editor the following settings are available:

• Cast shadows - controls if the currently selected object should cast shad-ows.

• X-res, y-res, z-res - the resolution of the voxelized object.


• Density - the density of the voxelized object. Determines how much lightthe object will let through.

• Hold-out - controls if the currently selected object should be used as ahold out object.

Figure 3.24: The mesh attribute editor.

3.7.9 Render settings

The render settings dialog can be accessed from the main menu under Render /Render settings (Figure 3.25). The following settings are available:

• Range:

Start frame - the first frame to be rendered.

End frame - the last frame to be rendered.

• Quality:

Raycasting step size - the length of each step in the ray casting algo-rithm. Shorter steps equals better quality.

Shadow step size - the length of each step in the lighting process. Shortersteps equals better quality.

• Output:

Width - the width of the output image.

Height - the height of the output image.

Format - output image format.

File prefix - the name of the rendered files. (Files will be named: pre-fix.frameNumber.format).

Directory - the directory to where the rendered files will be written.


• Motion blur:

Motion blur - enables motion blur.

Shutter angle - affects the amount of blur in the rendered images. Largervalues equals more blur. The valid range is ]0, 360].

Offset - determines how much of the previous frame and next frame willaffect the blur. A value of 0.0 will result in an interpolation betweenthe previous and the current frame, while a value of 1.0 will use the cur-rent and the next frame. Any value between 0.0 and 1.0 will result in aweighted interpolation between all three frames.

Samples - the number of interpolation steps for each frame. More stepsequals better quality.

Figure 3.25: The render settings dialog.

3.7.10 Caching

The process of viewing a simulation can be slow if the size of the scene or thesize of the fluid data is large. The time it takes to render one frame can easilymake the update frequency lower than the animation is supposed to run at, forexample 25 frames per second. This makes it hard to get an impression of howthe simulation actually is going to look when rendered.

To speed up the playback we implemented a caching system of the displayin the viewport. The caching works by saving an image-file each frame with aspecial MD5[15] hashed filename. MD5 is an algorithm that takes a string asinput and generates a 128-bit hash value, typically represented as a sequence of


32 hexadecimal digits. Even small changes in the string will, with a very highprobability, result in a totally new hash value.

Example:

MD5("The quick brown fox jumps over the lazy dog") = 9e107d9d372bb6826bd81d3542a419d6

MD5("The quick brown fox jumps over the lazy dog.") = e4d909c290d0fb1ca068ffaddf22cbd0

The string that is used to generate the hash for the state of the program isa concatenation of several factors:

• All numerical and boolean settings found in the fluid and mesh attributeeditors.

• The current frame number.

• A cache version number.

The renderer checks, before rendering anything, if there exists a file with thesame name as an MD5-string generated from the current state, and if so, showsthis image instead of rendering anything. The reason we are also adding thefluid and mesh attributes to the string is because it allows us to have severalversion of the simulation cached at the same time. A fluid simulation can, forexample, be cached for both a shadow density of 0.5 and 0.2 and then changedbetween those values without the need to redo the caching. The cache version isa number that is increased every time the cache should be completely truncated.For example, when changing the view in the viewport or updating a ramp inthe attribute editor.

The actual image-files are saved in a simple binary format that contains thecontent of the viewport compressed using RLE-encoding. The files are storedin the program location/cache-directory and kept there until the program isrestarted or the disc cache limit is reached (2 GB by default). A list of cachefiles and their corresponding size is kept within the program and is used todelete old files if new ones can’t be created without violating the limit.

3.7.11 The console

A console was added to the program to allow a convenient way to send infor-mation from the program to the user. The console can be viewed when desiredand can otherwise be left in the background. Different kinds of information isshown in the console (Figure 3.26):

Figure 3.26: Screenshot showing different console messages.


• Warnings and errors - example: trying to render a frame that doesn’t havea corresponding scene.

• General information - example: resolution and attributes of an importedfluid.

• Progress info - example: how many frames of a sequence that have beenrendered.

The console is a stand-alone application that is executed automatically onstartup. The application is very simple and the only thing it does is to listenfor either an incoming text or shutdown message. The user interface is designedusing the same custom controls as the main interface to keep a consistent look.

Chapter 4

Results

4.1 Performance

It’s hard to say something about the performance in general. The time it takesto read data from disc can easily dominate any performance test. The playbackspeed for a large scene, without caching, is usually below one frame per second.The test below only tests the time needed for the actual rendering. All data wasloaded, both in Maya and in our program, before the actual measuring started.See the discussion chapter for a more thorough discussion of the performanceproblem related to reading the data from disc.

Performance test

In order to test the performance of our application in comparison to Maya, abasic test scene was constructed. The scene contains a fluid container withresolution 120x120x120, a point light source and a camera.

The scene was rendered, from the same view, using Maya and the Men-tal Ray[16] renderer and with our application. The rendering resolution was800x600 and the system specifications can be found in appendix A. The timeneeded to render the frame was 2 m 31 s with Maya and around 0.5 s with ourprogram. The resulting images can be seen in Figure 4.1.

Figure 4.1: Fluid rendered with our program (left) and with Maya (right).


32 Chapter 4. Results

4.2 Limitations

We knew when we started the project, that we weren’t going to be able to com-plete all project components, which we initially intended to during the assignedtime period. Our approach was therefore to get a wide set of features workingand not focus too much on every detail. In this section we will point out someof the limitations that we noticed developing the software.

4.2.1 Differences from Maya

One of our primary goals was to be able to render fluids in the same way asMaya. There were some aspects in this area that we missed out on:

• Higher-order filtering - the highest degree of texture filtering supportedby OpenGL is linear filtering. Higher-order filtering has to be performedmanually in the shader and would be significantly slower. Renderings donein Maya shows a noticeably smoother result, especially for low resolutiongrids, than we were able to produce.

• Texturing - our application does not support mapping of textures to anattribute, such as opacity or color. This can be used to give the impressionof a higher resolution fluid without the need to use a more detailed grid.This was partly left out by purpose since it’s, in most cases, hard for theuser to make it look good for non-static fluids, much slower to render, andimplementing a complete texturing system would be very time consuming.Having said that, there are still times when a correctly tweaked 3d texturewould provide more detailed and appealing results.

• Better interpolation between frames - since we export the scene at a fixedframe rate, we had to use interpolation to get the subframes used for themotion blur. This interpolation is always performed linearly and doesn’ttake into account the kind of interpolation used in Maya. This could havebeen avoided if we used the FBX format. We originally intended to usethis format but the FBX API turned out to be incompatible with managedC++ code, used by Windows Forms that we used to design the GUI.

• Anti-aliasing - there will often be hard edges in the rendered image whenusing hold-out objects since we are only sampling one time per pixel -without using any anti-aliasing technique. Our method of using a depth-map for the hold-out objects turned out to be hard to use together withanti-aliasing. This will result in hard edges around mesh objects.

4.2.2 Technical issues

Most of the technical issues came from our approach of using the GPU to ac-celerate the rendering. Some are limitations of today’s hardware and some areproblems with the way the GPU and GLSL works:

• Texture units - all current video cards have a limit of how many textures(texture units) that can be used at the same time. Our program typicallyuses (2 + 3*number of fluids) texture units. The Geforce 8800 that weused for testing is able to use up to 64 textures, this limits the number

4.2. Limitations 33

of fluids used simultaneously in a scene to around 20. This will probablynot be a problem on future generations of video cards.

• Color space - OpenGL supports floating points frame buffers but unfortu-nately only for values in the range [0, 1]. This makes it harder to renderimages with a high dynamic range since all values will be clamped to 1.0.We tried to prevent this by dividing the values stored in the frame bufferwith the sum of the intensity of all lights in the scene and then, beforewriting an OpenEXR image, multiply with the same value. This worksto some extent but very bright areas together with incandescence can stillcause values exceeding 1. This could maybe have been solved by dividingall values by some large constant instead of the sum of the intensities butthis was not investigated further.

• GLSL - The GLSL shading language has improved a lot recently, butis according to our experience still pretty immature and contains severalbugs. There are commands that do not follow the specifications and forcedus to design our own work-arounds. This unfortunately made the programcrash on some machines when the instruction count of a shader got to high,but doesn’t seem to be a problem with newer hardware like the Geforce8800.

4.2.3 Design

The program was intended to fit nicely into a rendering workflow without addingtoo much complexity compared to doing the rendering in Maya. The way wedesigned the program turned out to cause some problems in this area that weweren’t able to foresee when we first started.

• Many fluids - we designed the program and the Maya plugins to exportevery fluids container separately. This worked fine for smaller scenes, butsoon became problematic for scenes with many fluid containers and wouldforce the user to go back to the File / Import fluid command many times.

• Fluid data and transformation together - the plugin used to export fluidsexports a fluid’s simulation, together with information about the currenttranslation, rotation, scaling etc. This takes up a lot of disc space and isnot very flexible in cases where only the transformation of the fluids con-tainer changes or the same simulation is to be used in several containers.A better design would be to export information about the transformationof all fluid containers together with the scene and keep the simulation dataseparate.

Merge fluid

A standalone tool was developed called FluidMerge (Figure 4.2) that was usedto circumvent the data/transformation issue. It took the simulation data fromone fluid, the transformation data from another and created a new combinedfluid. This tool was not intended to be a part of the workflow, but rather as alast minute solution to be able to test the program with scenes with many fluidcontainers.

34 Chapter 4. Results

Figure 4.2: The FluidMege interface.

4.2.4 Performance

The performance is overall very good for the actual rendering, but reading thedata from disc can sometimes drastically increase the time needed for preparinga frame for rendering. This turned out to be a much bigger bottleneck thanwe expected, and is in almost all cases linked to our way of handling the scene.The entire scene is read from disc and processed every frame (multiple scenefiles is loaded and interpolated if using motion blur) regardless of if an objecthas changed from the previous frame or not.

Chapter 5

Discussion

This section will present our thoughts of how the project turned out, if wereached our goals and finally some suggestion for future development.

5.1 Conclusion

In this project we have implemented a ray caster for volumetric fluid data, ex-ported from Autodesk Maya. The ray caster is using the GPU’s parallel struc-ture to quickly produce high quality renderings of the volumes. When it comesto the ray casting algorithm, we have met most of our goals. Our algorithm canrender volumes in high resolutions with self shadowing and shadows from otherobjects, which is discussed in chapter 3.3 Shadows. The algorithm also supportshold out objects as we discussed in chapter 3.4, as well as motion blur (chapter3.5) and the result can easily be saved as an HDR-image, ready to be composedinto an existing animation. As discussed in chapter 3.1 Maya plugins, a wholescene, including cameras and their respective focal length, aspect ratio etc, canbe imported from Maya, which makes it easy to align an animation rendered inour program with one rendered in Maya.

We have developed a complete graphical user interface to control how thefluids are rendered. The user interface and its features are described in chapter3.7 User interface. We also developed two small user interfaces for exportingdata from Maya. These are discussed in chapter 3.1 Maya plugins.

5.2 Future work

The area were we haven’t quite reached our goal is when it comes to perfor-mance. The program still offers an appealing real-time environment for tweakingshading parameters and viewing a fluid from different angles, but is not as fastas we wanted it to be when it comes to rendering an entire sequence. This ismuch because of the time it takes to read the data from the disc.

The program consisted of more than 12 000 lines of source code when weleft the project and would serve as a good foundation for future development.

During the final development and test stages of our project we came up withseveral ideas on how to improve performance and work-flow in our application.For example, the way the scene data is handled is far from perfect. When using


36 Chapter 5. Discussion

large scenes the time to read each frame of scene data from disc takes muchlonger than the actual rendering. By using the FBX format it would be possibleto keep the scene data in memory at all times and therefore drastically increasereading times. But as mentioned earlier the FBX API is not compatible withthe Windows Forms API that we have used to develop the GUI. There mightbe a solution to this though, by creating a DLL based interface to access theFBX API, instead of including it directly into the project. Unfortunately wedid not have enough time to test this.

Another idea is to redesign the way fluids are exported and keep the trans-formation and simulation data separate. It would then be possible to createsome kind of library of effects that could be imported and placed into any fluidcontainer in the scene.

Another obvious way to improve the performance is to optimize and continuethe development of the ray casting algorithm, by implementing higher-orderfiltering etc. There are also some features left unimplemented from the wishlist that we received from Filmgate. For example support for depth of field,reflective objects and a command line rendering interface.

One could also implement support for other programs than Maya. Anyprogram that uses a grid to simulate fluids and offers a low-level API can besupported by writing plugins to export its data.

Bibliography

[1] Filmgatehttp://www.filmgate.se/, acc. 2008-11-12

[2] Keenan Crane, GPU 3D Fluid Solverhttp://www.cs.caltech.edu/~keenan/project_fluid.html, acc. 2008-11-12

[3] Jos Stam, Stable Fluidshttp://www.dgp.toronto.edu/people/stam/reality/Research/pdf/ns.pdf, acc. 2009-01-03

[4] Eric W. Weisstein, Navier-Stokes Equationshttp://scienceworld.wolfram.com/physics/Navier-StokesEquations.html, acc. 2008-11-12

[5] NVIDIA, World Leader in Visual Computing Technologieshttp://www.nvidia.com/page/home.html, acc. 2008-11-12

[6] Paul Bourke, Polygonising a scalar fieldhttp://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/,acc. 2008-11-14

[7] Sebastian Zambal, Shear Warp Implementationhttp://www.cg.tuwien.ac.at/courses/projekte/vis/finished/SZambal/basic.html, acc. 2008-11-14

[8] Pixar, RenderManhttps://renderman.pixar.com/, acc. 2008-11-12

[9] SGI, About the OpenGL Architecture Review Board Working Grouphttp://www.opengl.org/about/arb/, acc. 2008-11-12

[10] GPGPU, Historyhttp://www.gpgpu.org/data/history.shtml, acc. 2008-11-12

[11] Lucasfilm Ltd. Companies, Industrial Light & Magichttp://www.ilm.com/, acc. 2008-11-12

[12] Wikipedia, Orthographic projectionhttp://en.wikipedia.org/wiki/Orthographic_projection, acc. 2008-11-12


38 Bibliography

[13] Illuminate Labs, 2D Motion Blurhttp://www.illuminatelabs.com/support/tutorial-folder/tutorials-turtle-3/2d-motion-blur/, acc. 2008-11-12

[14] Microsoft Corporation, The Official Microsoft WPF and Windows FormsSitehttp://windowsclient.net/, acc. 2008-11-12

[15] FAQS.ORG, The MD5 Message-Digest Algorithmhttp://www.faqs.org/rfcs/rfc1321, acc. 2008-11-12

[16] Autodesk, Mental rayhttp://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=6837573, acc. 2008-11-14

Appendix A

The test system

A.1 Specifications

Intel C2D E6850 3.00 GHz

2 GB 800 MHz DDR2 RAM

Geforce 8800 GTS 320 MB

7200 RPM HDD

Windows XP Pro SP2


Improving rendering times of Autodesk Maya Fluids using ...271956/FULLTEXT01.pdf · for people...

Documents

Transcript of Improving rendering times of Autodesk Maya Fluids using ...271956/FULLTEXT01.pdf · for people...