diff --git a/tex_review/chapters/transition.tex b/tex_review/chapters/transition.tex
index ef0bc84..dd360af 100644
--- a/tex_review/chapters/transition.tex
+++ b/tex_review/chapters/transition.tex
@@ -31,46 +31,89 @@
 	\end{figure}
 	
 	Within previous works, we used a graph of equidistant nodes (see \reffig{fig:museumMapGrid}) 
-	to model the buildings floorplan, representing the basis for the transition step \cite{Ebner-15, Ebner-16}.
+	to model the building's floorplan, representing the basis for the transition step \cite{Ebner-15, Ebner-16}.
+	\add{
+		It is created \emph{automatically}, based on the building's floorplan,
+		which, in turn, results from \emph{manually} tracing available blueprint pictures within our editing software.
+	}
 	% in 15 und 16 haben wir stueckweise den graph eingefuhert
 	%
-	The graph equals a grid, where each node constitutes the center of a grid-cell.
-	Cells, usually around \SI{30} x \SI{30}{\centi\meter} in size,
-	are only placed in regions that are actually walkable and not intersected by any walls
-	or other obstacles. After placement, each cell is connected with their, up to 8, potential 
-	neighbors in the plane, creating a walkable graph for each floor. The resulting graphs are
-	hereafter connected via stairs or elevators, to form the final data structure
-	for the whole building.
-	This allowes for (semi-)random walks along the graph, by assigning probabilities to each edge,
-	using prior knowledge provided by sensors, forming the transition probability
-	$p(\mStateVec_{t} \mid \mStateVec_{t-1}, \mObsVec_{t-1})$ \cite{Ebner-16}.
+	The resulting graph equals a grid, where each node constitutes the center of a grid-cell.
+	\add{
+		Each cell uses an empiric choice of \SI{30} x \SI{30}{\centi\meter} in size.
+		The algorithm thus places a new cell every \SI{30}{\centi\meter},
+		but only in regions that are actually walkable,
+		and where the cell's outline does not intersect any wall or other obstacles.
+		As cells are equidistant and axis aligned for performance reasons,
+		the algorithm works reasonably well for rectangular buildings,
+		matching the graph's coordinate system.
+		For skewed floorplans, however, many periphery cells will intersect
+		with walls and are thus omitted, reducing the quality of the representation.
+		While smaller cells thus allow for a more accurate representation of the building,
+		more cells are needed in total, increasing memory requirements for the smartphone.
+	}
+	After placement, each cell is connected with their, up to 8, potential 
+	neighbors in the plane \add{(left,right,top,bottom and diagonals)}.
+	\add{
+		Those connections are only added, if the neighbor is actually available,
+		and the connection itself does not intersect any obstacles.
+	}
+	Doing so creates a walkable graph \add{of nodes and edges} for each floor.
+	The graphs for each floor are hereafter connected via stairs or elevators,
+	to form the final, walkable data structure for the whole building.
+	This allows for (semi-)random walks along the graph, \add{modeling potential pedestrian movements}.
+	\add{
+		By assigning probabilities to each edge, using prior knowledge \eg{} provided by sensors,
+		the random walk along those weighted edges denotes the transition probability
+		$p(\mStateVec_{t} \mid \mStateVec_{t-1}, \mObsVec_{t-1})$ \cite{Ebner-16}.
+	}
 	
-	Due to the equidistant spacing, the resulting graph was rather rigid and
-	only well-suited for rectangular buildings. For more contorted buildings, like many
-	historic ones, the node-spacing needs to be small, to reliably reach every door, stair
-	and corner of the building. Within \reffig{fig:museumMapGrid} we used a
-	\SI{90}{\centi\meter} spacing, that is barely able to reach all places within
-	the lower floors of the building, and failing to connect the upper floors reliably. 
+	Due to the equidistant spacing \add{every \SI{30}{\centi\meter}},
+	the resulting graph is rather rigid and only well-suited for rectangular buildings.
+	For more contorted buildings, like many historic ones,
+	the node-spacing needs to be small, to reliably reach every door, stair
+	and corner of the building.
+	\add{For demonstration, we used a \SI{90}{\centi\meter} spacing} within \reffig{fig:museumMapGrid}.
+	\add{As can be seen, the automatically generated grid} is barely able to reach all places within
+	the lower floors of the building, and fails to connect the upper floors reliably. 
 	While using smaller spacings remedies the problem, it requires huge amounts of memory:
-	up to several hundred megabytes and millions of nodes and edges to model a single building.
+	\add{Up to hundred megabytes and millions of nodes and edges are realistic for larger buildings.}
 	% musuem aus figure: 90cm grid : ca 2000 nodes, ca 6500 edges
 	% museum aus figure: 30cm grid : ca 32k nodes und 120k edges
 	% museum ganz, 20cm grid : ca 75k nodes, 280k edges
 	
 	Because of both, required memory amounts and inaccuracies of the graph-based
-	model, we developed a new basis for the transition step, that is still able to answer
-	$p(\mStateVec_{t} \mid \mStateVec_{t-1}, \mObsVec_{t-1})$.
-	The new foundation is provided by well-known navigation meshes \cite{navMesh1}
-	where the walkable area is spanned by convex polygons, sharing
-	their outline edges. Each polygon knows its adjacent
-	neighbors, creating a walkable mesh.
-	Using variable shaped/sized elements instead of rigid grid-cells
+	model \add{depending on the spacing},
+	we developed a new basis for the transition step, that is still able to answer
+	$p(\mStateVec_{t} \mid \mStateVec_{t-1}, \mObsVec_{t-1})$,
+	\add{but has a much smaller memory footprint while representing the real floorplan
+	more accurately.}
+	%
+	The new foundation is provided by well-known navigation meshes \cite{navMesh1},
+	where the walkable area is spanned by convex polygons.
+	\add{
+		As the polygons are neither axis-aligned nor fixed in shape and size, 
+		they can accurately represent skewed architectures, where
+		the grid-based approach suffers from aforementioned flaws.
+	}
+	\add{
+		Another main idea behind navigation meshes
+		is presented by shared outline edges between adjacent polygons.
+		It thus is always possible to walk from one polygon into another,
+		if they are adjacent.
+		Similar to the graph-based approach, adjacent polygons thus
+		denote some sort of walkable surface.
+		Just as before, the navigation mesh can be \emph{automatically}
+		generated from the building's floorplan, based on
+		various algorithms \cite{navMeshAlg1}.
+	}
+	Using variably shaped/sized elements instead of rigid grid-cells
 	provides both, higher accuracy for reaching every corner, and a reduced
 	memory footprint as a single polygon is able to cover arbitrarily
 	large regions. However, polygons impose several drawbacks on
 	common operations used within the transition step, like checking whether 
 	a point is contained within some region. This is much more costly for polygons
-	compared to grid-cells, which are axis-aligned rectangles.
+	\add{ compared to axis-aligned, rectangular grid-cells. }
 	% museum aus figure: 305 3-ecke 
 	% museum ganz : 789 fuer alles
 	%
diff --git a/tex_review/egbib.bib b/tex_review/egbib.bib
index 38cdb00..cb397c3 100644
--- a/tex_review/egbib.bib
+++ b/tex_review/egbib.bib
@@ -2974,3 +2974,19 @@ address = {{Rothenburg, Germany}},
   publisher={IEEE}
 }
 
+
+
+
+@INPROCEEDINGS{navMeshAlg1,
+	author={W. van Toll and A. F. Cook and R. Geraerts},
+	booktitle={2011 IEEE/RSJ International Conference on Intelligent Robots and Systems},
+	title={Navigation meshes for realistic multi-layered environments},
+	year={2011},
+	REM_volume={},
+	REM_number={},
+	pages={3526-3532},
+	REM_keywords={mesh generation;navigation;virtual reality;navigation meshes;realistic multilayered environments;virtual characters;path planning;airport;multistorey building;two-dimensional polygons;Navigation;Data structures;Complexity theory;Buildings;Airports;Path planning;Graphics},
+	REM_doi={10.1109/IROS.2011.6094790},
+	REM_ISSN={2153-0866},
+	REM_month={Sept},
+}