starting from the closest metaball, multiply the attenuation ratios
onto the buffer. This slowly blots out the frame, blocking out the
light as more and more metaballs are added. Each time a metaball's
-attenuation ratio is multiplied onto the buffer, the centre pixel of
+attenuation ratio is rendered into the buffer, the centre pixel of
that metaball is read, multiplied by the colour of the sun, and then
-stored to be used later in the rendering step.
+stored for later use in the rendering step. Although we do not take
+advantage of it in this paper, as a byproduct of calculating this, we
+get a shadow map of the clouds for free!
The attenuation ratios are stored as textures like the ones shown in
Figure~\ref{fig:textures}. These are different for each density, but
fragment blending that occurs with \texttt{GL\_BLEND}.
\section{Implementation}
-\subsection{Ceullar automata}
+\subsection{Cellular automata}
The implementation of the cellular automata simulation
was the most straightforward part of the process. I did not attempt to
implement it with bitwise operations --- the cost of simulation with
\subsection{Metaballs}
Once the binary cells are converted to a grid of continuous densities,
-these needed to specify a set of metaballs. There was a bit of
-ambiguity here as the paper just states ``the continuous density
-distribution is expressed by a set of metaballs'', so from the
-implementation in~\cite{dobashi1998animation} I interpreted this as a
-fixed grid of metaballs at each point, assigning a density to each one.
-
-One of the biggest challenges I faced when interpreting the paper, was
-figuring out how the billboard textures are precalculated. The paper
+they need to be mapped to metaballs that can be rendered. There was a
+bit of ambiguity here as the paper just states ``the continuous
+density distribution is expressed by a set of metaballs'', so given
+the implementation in~\cite{dobashi1998animation}, I interpreted this
+as a fixed grid of fixed-sized metaballs at each point, with a density
+assigned to each one.
+
+One of the biggest challenges I faced when interpreting the paper was
+figuring out how the billboard textures were precalculated. The paper
provides a vague diagram stating that both the attenuation ratio and
cumulative density are stored, but doesn't explain how to calculate
the former. I can only assume that it must be possible to calculate
this in a physically accurate way. Again, artistic liberties were
taken here in Listing~\ref{lst:textures} to guess a method for
-generating the result in Figure~\ref{fig:textures}.
+generating the result in Figure~\ref{fig:textures}. Only the
+``attenuation ratio'' is stored.
\begin{figure}
\centering
\subsubsection{Buffers}
The rendering process is similar to shading, in that we draw each
metaball onto a buffer. Originally the shading process happened in an
-off-screen framebuffer so that the default framebuffer was
-undisturbed, but since the rendering clears the buffer anyway and
-draws on top of it, there was no need and it was eventually removed so
-that everything happens in the one buffer. However caution was needed
-to make sure that the orthographic projection in the shading process
-was large enough, so that all the metaballs would fit in the same
-dimensions as the frame it was being drawn to.
+off-screen framebuffer so that the default framebuffer wouldn't be
+disturbed. But since the buffer is cleared before rendering anyway,
+there was no need and it was eventually removed so that everything
+happens in the one buffer. Caution was needed however to ensure that
+the orthographic projection in the shading process was large enough to
+fit all the metaballs in the frame.
\subsubsection{Blending}
The blending for rendering uses the equation:
Despite this course being \textit{Real-time Rendering}, the rendering
process here was very much \textbf{not} real time. The authors of the
paper say that it took around 10 secondsto render a single frame for
-a grid of $256\times128\times20$. On my machine in 2020, this took around 12
+a grid of $256\times128\times20$ --- in 2005. On my machine in 2020, this took around 12
seconds. Something was definitely wrong, so I profiled the program and
found that the vast majority of time was being spent inside
\texttt{shadeClouds}: namely waiting on the \texttt{glReadPixels}
data ready for us.
Because the time it takes to (issue the commands to) draw a metaball
-is so short, a large buffer of 512 PBOs were set up to minimize the
-time spent waiting on downloads to finish. Reading the pixels is
-still the bottleneck, but it now only takes 2.8 seconds instead of 16.
+is so short, a large buffer of 512 PBOs was set up to minimize the
+time spent waiting on downloads to finish. Reading the pixels is still
+the bottleneck, but thanks to PBOs it now only takes 2.8 seconds instead
+of 16.
\section{Improvements}
Despite the nice speed up by using PBOs, the constant thrashing back
projects / clouds.git / commitdiff