--- a/doc/kishna.tex Tue Dec 09 03:04:31 2008 +0000
+++ b/doc/kishna.tex Tue Dec 09 03:06:48 2008 +0000
@@ -208,19 +208,24 @@
iteration it checks if theres a collision (i.e. the type of the
current point is ROCK or DIRT).
-In order to implement bouncing from the terrain we have to have a way
-of calculating a normal for the slope of the terrain in the collision
-point. We came up with the following algorithm for calculating the
-approximation for the normal. Take the collision point and the point
-before the collision and consider a 3x3 array of pixels which has the
-collision point in the middle of it. Then, do sort of an bredth-first
-search from the previous point to get all the empty pixels. Take the
-vectors from the collision point to the empty points and sum these
-vectors. The resulting vector will point approximately along the
-normal. Picture \ref{algo} explains this a lot. In the middle of the pictured we have zoomed to the point in which the collision has happened. The red arrow is the sum of the black arrows and thus it is our approximation for the normal.
+In order to implement the bouncing from the terrain we have to be able
+to calculate a normal for the slope of the terrain in the collision
+point. We came up with the following algorithm which gives us an
+approximation of the normal
+
+\begin{enumerate}
+ \item Take the collision point ($p_1$) and the point
+before the collision ($p_2$) and consider a 3x3 array of pixels which has the
+collision point in the middle of it.
+ \item Find the empty points that are connected to $p_2$ with bredth-first search algorithm
+or something similar.
+ \item Calculate the vectors pointing from the collision point to the empty points. Sum of these vectors gives us the approximation of the normal.
+\end{enumerate}
+
+Picture \ref{algo} explains the algorithm a lot. In the middle of the pictured we have zoomed to the collision point. The red arrow is the sum of the black arrows and thus it is our approximation for the normal.
\begin{figure}[!ht]
- \centering \includegraphics[width=\textwidth]{normaali_algo.png}
+ \centering \includegraphics[width=0.7\textwidth]{normaali_algo.png}
\caption{Visualizing the algorithm for approximating the normal. \label{algo}}
\end{figure}
@@ -252,6 +257,19 @@
the product of the interval $(h)$ and an estimated slope that is
defined as $\frac{1}{6}h\left(k_1+2k_2+2k_3+k_4\right)$.
+\subsection{Texture generation}
+
+In texture generation we use random fractal terrain generation algorithm \cite{fractal}.
+In one dimension algorithm starts with one straight line. Then it affects to that
+line's midpoint with some random multiplied with H-value. After those first steps
+it simply calls itself to both parts of line changing H-value smaller.
+
+We use the two dimensional version of the algorithm. It needs step for point's between
+last density and step diagonal to last density's points -- otherwise it is quite similar
+to the one dimensional version. We decide to implement the algorithm as iterative instead of recursion.
+
+% TODO: something network related?
+
\subsection{Input}
All input is represented as a bitmask, composed of bits from \textsl{enum PlayerInputBits}. Additionally, the Graphics
@@ -330,8 +348,8 @@
attached when the player spawns.
\item If rope is thrown without releasing it first, rope will pull worm
while in mid-air
-\item Collisions with the terrain are only tested for the edgepoints
- of the polygon.
+\item Collisions with the terrain are only tested for the vertices
+ of the polygon. It is thus possible for the player to move through some pixels.
\item Existing Player ropes and Projectiles are not sent to the client when it connects, which can cause apparent
glitches in what the terrain looks like and how players move.
\end{enumerate}