summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorOliver Schinagl <oliver@schinagl.nl>2008-01-11 00:14:25 (GMT)
committerOliver Schinagl <oliver@schinagl.nl>2008-01-11 00:14:25 (GMT)
commit388f374391426c342c0bc271ea812ef1d088436a (patch)
tree54738d8b1d56ceae4bebf4307f5b76b32d318812
parent28d83930cdf2844b69ac9f51c05e68b41d121307 (diff)
download2iv35-388f374391426c342c0bc271ea812ef1d088436a.zip
2iv35-388f374391426c342c0bc271ea812ef1d088436a.tar.gz
2iv35-388f374391426c342c0bc271ea812ef1d088436a.tar.bz2
oliver's input
-rw-r--r--Smoke/report/chapter1.tex11
-rw-r--r--Smoke/report/chapter2.tex18
-rw-r--r--Smoke/report/chapter3.tex31
3 files changed, 19 insertions, 41 deletions
diff --git a/Smoke/report/chapter1.tex b/Smoke/report/chapter1.tex
index 88d7918..4bf07d2 100644
--- a/Smoke/report/chapter1.tex
+++ b/Smoke/report/chapter1.tex
@@ -1,18 +1,15 @@
\chapter{Introduction}
-The visualization course focuses on techniques and algorithms used to visualize large data sets. The code of a 2D fluid simulator was distributed to implement such
-techniques on top of the existing code. \\
+The visualization course focuses on techniques and algorithms used to visualize large data sets. The code of a 2D fluid simulator was supplied to implement such techniques on. \\
\begin {center}
\includegraphics[width=120mm]{practical.png} \\
- Figure 1: Practical assignment \\
+ Figure 1: Practical Assignment \\
\end {center}
-The above figure illustrates the different assignments. After doing step 3 there were two different ways to continue the practical assignment. We chose
-to take the left branch of the figure which, amongst others, involved implementing isosurfaces and height plots. \\
+The above figure illustrates the different assignments. After step 3 there were two different paths to continue the practical assignment. As one had to be chosen we chose to take the left branch of the figure which, amongst others, involved implementing isosurfaces and height plots. \\
-Every chapter in this report discusses a particular objective from the practical assignment. The next chapter will briefly talk about the skeleton program and how
-we adapted the code to be able to add functionality. Chapter 3 will discuss the color mapping, chapter 4 is about glyphs and so on. \\
+Every chapter in this report discusses a particular objective from the practical assignment. The next chapter will briefly talk about the skeleton program supplied and how we adapted the code to be able to add functionality. Chapter 3 will discuss the color mapping, chapter 4 is about glyphs and so on. \\
We will discuss a few subjects for each practical assignment. Each chapter gives a short description of each technique with a couple of screenshots, it talks about
how we implemented the technique and what problems we encountered if any. \\
diff --git a/Smoke/report/chapter2.tex b/Smoke/report/chapter2.tex
index b4afc0a..7e3a1a8 100644
--- a/Smoke/report/chapter2.tex
+++ b/Smoke/report/chapter2.tex
@@ -1,17 +1,13 @@
\chapter{The skeleton code}
-The provided code for the course contains an implementation of a real-time fluid flow simulation. The fluid flows under the influence of a user-controlled force
-field. The simulation follows the Navier-Stokes equations for fluid flow. These equations describe how the velocity, pressure, temperature and density of a moving
-fluid are related. \\
+The provided code for the course contains an implementation of a real-time fluid flow simulation. The fluid flows under the influence of a user-controlled force field. The simulation follows the Navier-Stokes equations for fluid flow. These equations describe how the velocity, pressure, temperature and density of a moving fluid are related. \\
\section{Grid-based smoke}
The visualization is done using a two dimensional grid as opposed to particle-based smoke visualization techniques. At every vertex a number of fluid attributes are
-stored. The skeleton program keeps track of the density, velocity and force. These attributes can be visualized with different techniques. Each and every
-attribute has its own 'preferred' visualization technique. \\
+stored. The skeleton program keeps track of the density, velocity and force. These attributes can be visualized with different techniques. Each and every attribute has its own 'preferred' visualization technique. \\
-Using these values at the cell's vertices, all sorts of techniques, additional values and other useful info can be used. The values are used in colormap techniques,
-calculation of the divergence and the rendering of the height plots. \\
+Using these values at the cell's vertices, all sorts of techniques, additional values and other useful info can be used. The values are used in colormap techniques, calculation of the divergence and the rendering of the height plots. \\
\begin {center}
\includegraphics[width=70mm]{flow_vis.png} \\
@@ -22,10 +18,6 @@ The above screenshot shows us the fluid movement using a grey colormap. This sim
\section{Internal structure}
-The first assignment was to simply compile the code. That was fairly easy. However, the code was a bit unstructured. Everything was put into one big file. To be
-able to add additional functionality without losing sight of what we were doing, we created a file for every new technique we implemented. The second thing we
-did is we split up the calculations, the rendering functions and user interactions from each other. \\
+The first assignment was to simply compile the code. This was fairly easy. However, the code was a bit unstructured. Everything was put into one big file. To be able to add additional functionality without losing sight of what we were doing, we created a file for every new technique we implemented. Furthermore the calculations, rendering functions and user interaction code was split from eachother. \\
-With this new structure we were able to manage the code and add additional functionality. We chose C as our programming language and used the GTK+ library to create
-the graphical user interface. We also used SVN to manage our project. This was very useful since we both had different development environments and also did a lot
-of work at home. \\
+With this new structure we were able to manage the code and add additional functionality. The programming language of our choice was C and for the graphical user interface we took the GTK+ library with the OpenGL extension. For project managment SVN was used. This was very useful since we both had different development environments and also did a lot of work at home. \\
diff --git a/Smoke/report/chapter3.tex b/Smoke/report/chapter3.tex
index 5be90ac..7cf56a2 100644
--- a/Smoke/report/chapter3.tex
+++ b/Smoke/report/chapter3.tex
@@ -4,26 +4,21 @@ In chapter 2 we saw a figure (figure 2) which showed a fluid in motion. The flui
\section{Description}
-The technique that maps a value to a specific color is called color mapping. We already explained that the simulation is divided into cells with each 4 vertices
-that can contain different values (a uniform quad grid). A colormap calculates the color, given a certain colormap function, for every value at a vertex. Example:
-\\
+The technique that maps a value to a specific color is called color mapping. We already explained that the simulation is divided into cells with each 4 vertices that can contain different values, a uniform quad grid. A colormap calculates the color, given a certain colormap function, for every value at a vertex. \\
+Example:
In figure 2 we saw the smoke using a grey scaled colormap. If we know that the values at the vertices ranges from 0 to 1, we can use the value to determine each
color aspect, red, green and blue. This means, for each vertex:
$$ red = green = blue = value $$
-To be able to reason about the colored images, we added a legend at the top of the screen. The leftmost colors indicate low values and the rightmost colors indicate
-high values. With such a colormap legend, it's easier to understand the produced images and say something about the value of the fluid. \\
+To be able to reason about the colored images, we added a legend at the top of the screen. The leftmost colors indicate low values and the rightmost colors indicate high values. With such a colormap legend, it's easier to understand the produced images and say something about the value of the fluid. \\
-You are also able to set the number of used colors. At default this value is set to 256 colors, but you can easily set that amount to 16 using a slider. You will
-see big bands of colors appear. This way, the line between certain values becomes more visible. \\
+Using a slider it is possible to change the number of colors. By default this value is set to 256 colors, but this is easily changed to anything below that. At lower number of colors big bands of colors will start to appear maing variations more visiable. \\
\section{Implementation}
-We've implemented two actual colormaps and three which only contain one RGB color, red, green or blue (useful for isolines for instance). The "Wilrik" colormap
-implements a fire elemental color scheme. The other one is called "Oliver" and is a repeated band of colors which can show quite well where the fluid's in motion.
-\\
+Next to the 3 supplied colormaps 5 additional colormaps where added. Three of these where only contain one color, red, green or blue. These are not only useful for isolines but also when wanting to see height plots, but not get distracted by the flow of density. The remaining two colormaps are the "Wilrik" colormap, it implements a fire elemental color scheme and the "Oliver" colormap which may seem like a tripy odd map, not like a colormap at all. It does serve a purpose however, it allows to easly see rapid changing values. \\
\begin {center}
\includegraphics[width=100mm]{wilrik.png} \\
@@ -34,22 +29,16 @@ The fire color is determined as follows:
$$ red = value; green = value / 3; blue = 0; $$
-So, if the value is high, a lot of red, one third of green and no blue is taken. Low values only get a bit of red and almost no green. This gives a black to dark
-red to orange, almost yellow colormap. \\
+If the value is high, a lot of red, one third of green and no blue is taken. Low values only get a bit of red and almost no green. This gives a black to dark red to orange to almost yellow colormap giving the illusion of fire. \\
To create a repeating band of colors, we used to following definition:
-$$ value = (int)(value * 100) \texttt{ mod } 10 $$
+$$ value = (((int)(value * 100)) \texttt{ mod } 10)/10 $$
-So we first multiply the value with 100, cast it to an integer and take that value modulo 10. We then take some colors from a look-up-table to pick the color for
-the band. \\
+By first mutliplying our value by 100 and converting it to an integer the value get's reduced in significance. If this would be devided by 100 again the result would be 100 different bands of color. By taking the module of 10 first however, a repeating sequence of bands is achieved. To compensate for the earlier multiplication of 100 it's required to devide by 10 once more, as color values are set to be between 0 and 1. \\
\section{Difficulties}
-The last mechanisms to implement for this assignment were scaling and clamping. With clamping you let the user set a minimum and maximum for the values. This is
-done by first enabling clamping and then click somewhere in the bottom of the color legend and drag the minimum and maximum clamping indictors. Actual data lower
-then the minimum or higher than the maximum are set to the maximum or minimum respectively. \\
+The last mechanisms to implement for this assignment were scaling and clamping. With clamping the user is able to set a minimum and maximum for the values. This is done by first enabling clamping and then clicking on in the bottom half of the color legend and drag the minimum and maximum clamping indictors, which are white. Actual data lower then the minimum or higher than the maximum calculated value are then clamped to the this minimum and maximum respectively. \\
-The (auto)scaling mechanism was a bit more subtle. When enabled, you can set the scaling in the same way as the clamping. For the auto-scaling, the minimum and
-maximum values are stored and the entire dataset at the current time moment is mapped to the visible colormap. This is not so hard to do, but we had not foreseen
-that values could also be negative. It wasn't until we implemented the divergence that we found this problem. \\
+The (auto)scaling mechanism was a bit more subtle. When enabled, the scaling is set in the same way as the clamping but for the top half of the legend bar, marked in red. For the auto-scaling bit, the minimum and maximum values are stored and the entire frame and is mapped to the visible colormap. This is was quite trivial, was it not that the values could also be negative. Something that went unnoticed until divergence was implemented. \\