Index: trunk/VUT/doc/SciReport/introduction.tex
===================================================================
--- trunk/VUT/doc/SciReport/introduction.tex	(revision 273)
+++ trunk/VUT/doc/SciReport/introduction.tex	(revision 277)
@@ -1,16 +1,33 @@
 \chapter{Introduction}%\chapter
 
-\label{chap:overview}
-\label{chap:classes}
-
- This chapter provides introduction to visibility problems and
-algorithms for computer graphics. In particular it presents a taxonomy
-of visibility problems and algorithms. We discuss typical visibility
-problems encountered in computer graphics including their relation to
-the presented taxonomy. Finally, we classify the later described
-visibility tools according to the presented taxonomy.
-
+\label{chap:introduction}
 
 \section{Structure of the report}
+
+  The report consists of two introductory chapters, which provide a
+ theoretical background for description of the algorithms, and three
+ chapters dealing with the actual visibility algorithms.
+
+  This chapter provides an introduction to visibility by using a
+ taxonomy of visibility problems and algorithms. The taxonomy is used
+ to classify the later described visibility
+ algorithms. Chapter~\ref{chap:analysis} provides an analysis of
+ visibility in 2D and 3D polygonal scenes. This analysis also includes
+ formal description of visibility using \plucker coordinates of
+ lines. \plucker coordinates are exploited later in algorithms for
+ mutual visibility verification (Chapter~\ref{chap:mutual}).
+
+ Chapter~\ref{chap:online} describes a visibility culling algorithm
+ used to implement the online visibility culling module. This
+ algorithm can be used accelerate rendering of fully dynamic scenes
+ using recent graphics hardware.  Chapter~\ref{chap:sampling}
+ describes global visibility sampling algorithm which forms a core of
+ the PVS computation module. This chapter also describes view space
+ partitioning algorithms used in close relation with the PVS
+ computation. Finally, Chapter~\ref{chap:mutual} describes mutual
+ visibility verification algorithms, which are used by the PVS
+ computation module to generate the final solution for precomputed
+ visibility.
+
 
 
@@ -127,5 +144,5 @@
 we obtain a vector that represents the same line $l$. More details
 about this singularity-free mapping will be discussed in
-Chapter~\ref{chap:vfr2d}.
+Chapter~\ref{chap:analysis}.
 
 
@@ -207,9 +224,9 @@
 
  Although the \plucker coordinates need more coefficients they have no
-singularity and preserve some linearities: lines intersecting a set of 
-lines in 3D correspond to an intersection of 5D hyperplanes. More details
-on \plucker coordinates will be discussed in
-Chapters~\ref{chap:vfr25d} and~\ref{chap:vfr3d} where they are used to
-solve the from-region visibility problem.
+singularity and preserve some linearities: lines intersecting a set of
+lines in 3D correspond to an intersection of 5D hyperplanes. More
+details on \plucker coordinates will be discussed in
+Chapter~\ref{chap:analysis} and Chapter~\ref{chap:mutual} where they
+are used to solve the from-region visibility problem.
 
   To sum up: In 3D there are four degrees of freedom in the
@@ -627,5 +644,5 @@
 the nature of the given problem and it should assist in finding
 relationships between visibility problems and algorithms in different
-application areas.  The tools address the following classes of
+application areas.  The algorithms address the following classes of
 visibility problems:
 
@@ -641,13 +658,14 @@
 discussed important steps in the design of a visibility algorithm that
 should also assist in understanding the quality of a visibility
-algorithm. According to the classification the tools address
-algorithms with the following properties:
+algorithm. According to the classification the visibility algorithms
+described later in the report address algorithms with the following
+properties:
 
 \begin{itemize}
 \item Domain:
   \begin{itemize}
-  \item viewpoint (online culling tool),
-  \item global visibility (global visibility sampling tool)
-  \item polygon or polyhedron (mutual visibility tool)
+  \item viewpoint (online visibility culling),
+  \item global visibility (global visibility sampling)
+  \item polygon or polyhedron (mutual visibility verification)
   \end{itemize}
 \item Scene restrictions (occluders):
@@ -671,16 +689,16 @@
 \item Solution space:
   \begin{itemize}
-  \item discrete (online culling tool, global visibility sampling tool, conservative and approximate algorithm from the mutual visibility tool)
-  \item continuous (exact algorithm from mutual visibility tool)
+  \item discrete (online visibility culling, global visibility sampling, conservative and approximate algorithm from the mutual visibility verification)
+  \item continuous (exact algorithm from mutual visibility verification)
   \end{itemize}
-  \item Solution space data structures: viewport (online culling tool), ray stack (global visibility sampling tool, conservative and approximate algorithm from the mutual visibility tool), BSP tree (exact algorithm from the mutual visibility tool)
+  \item Solution space data structures: viewport (online visibility culling), ray stack (global visibility sampling, conservative and approximate algorithm from the mutual visibility verification), BSP tree (exact algorithm from the mutual visibility verification)
   \item Use of coherence of visibility:
     \begin{itemize}
-    \item spatial coherence (all tools)
-    \item temporal coherence (online culling tool)
+    \item spatial coherence (all algorithms)
+    \item temporal coherence (online visibility culling)
     \end{itemize}
-  \item Output sensitivity: expected in practice (all tools)
-  \item Acceleration data structure: kD-tree (all tools)
-  \item Use of graphics hardware: online culling tool
+  \item Output sensitivity: expected in practice (all algorithms)
+  \item Acceleration data structure: kD-tree (all algorithms)
+  \item Use of graphics hardware: online visibility culling
   \end{itemize}
 
Index: trunk/VUT/doc/SciReport/analysis.tex
===================================================================
--- trunk/VUT/doc/SciReport/analysis.tex	(revision 266)
+++ trunk/VUT/doc/SciReport/analysis.tex	(revision 277)
@@ -1,6 +1,8 @@
 \chapter{Analysis of Visibility in Polygonal Scenes}
 
+\label{chap:analysis}
+
 This chapter provides analysis of the visibility in polygonal scenes,
-which are the input for all developed tools. The visibility analysis
+which are the input for all developed algorithms. The visibility analysis
 uncoveres the complexity of the from-region and global visibility
 problems and thus it especially important for a good design of the
@@ -9,5 +11,5 @@
 visibility interactions can be observed easily by interactions of sets
 of points. Additionally for the sake of clarity, we first analyze
-visibility in 2D and then extend the analysis to 3D polygonal scenes.
+visibility in 2D and then extend the analysis to 3D polygonal scenes. Visibility in 3D is described using \plucker 
 
 \section{Analysis of visibility in 2D}
@@ -51,6 +53,6 @@
 coordinates $l^*_1 = (a, b, c)$ and $l^*_2 = -(a,b,c)$.  The \plucker
 coordinates of 2D lines defined in this chapter are a simplified form
-of the \plucker coordinates for 3D lines that will be discussed in
-Chapter~\ref{chap:rot3d}: \plucker coordinates of a 2D line correspond
+of the \plucker coordinates for 3D lines, which will be discussed
+bellow in this chapter: \plucker coordinates of a 2D line correspond
 to the \plucker coordinates of a 3D line embedded in the $z = 0$ plane
 after removal of redundant coordinates (equal to 0) and permutation of
@@ -287,5 +289,5 @@
 primal space. This observation is supported by the classification of
 visibility problems presented in
-Chapter~\ref{chap:classes}. Visibility from point in 3D and visibility
+Chapter~\ref{chap:introduction}. Visibility from point in 3D and visibility
 from region in 2D induce a two-dimensional problem-relevant line
 set. This suggests the possibility of mapping one problem to another.
@@ -500,5 +502,5 @@
 equation~\ref{eq:plucker_quadric}. Thus there are four degrees of
 freedom in the description of a 3D line, which conforms with the
-classification from Chapter~\ref{chap:overview}.
+classification from Chapter~\ref{chap:introduction}.
 
  \plucker coordinates allow to detect an incidence of two lines by
@@ -799,6 +801,5 @@
  The blocker polyhedron describes lines intersecting the source
  polygon and the given occluder.  The blocker polyhedron can be seen
- as an extension of the blocker polygon discussed in
- Chapters~\ref{chap:rot2d} and~\ref{chap:rot3d} for the from-region
+ as an extension of the blocker polygon discussed above for the from-region
  visibility in 3D scenes. The blocker polyhedron is a 5D polyhedron in
  a 5D projective space.  To avoid singularities in the projection from
@@ -899,10 +900,10 @@
 
 
-For solution of some from-region visibility problems (e.g. PVS
-computation, region-to-region visibility) the event swaths need not be
-reconstructed. For example the visibility culling algorithm that will
-be discussed in Section~\ref{sec:rot3pvs} only computes extremal
-\plucker points and uses them to test an existence of a set of
-stabbers of a given size.
+% For solution of some from-region visibility problems (e.g. PVS
+% computation, region-to-region visibility) the event swaths need not be
+% reconstructed. For example the visibility culling algorithm that will
+% be discussed in Section~\ref{sec:rot3pvs} only computes extremal
+% \plucker points and uses them to test an existence of a set of
+% stabbers of a given size.
 
 
Index: trunk/VUT/doc/SciReport/online.tex
===================================================================
--- trunk/VUT/doc/SciReport/online.tex	(revision 273)
+++ trunk/VUT/doc/SciReport/online.tex	(revision 277)
@@ -1,4 +1,5 @@
-\chapter{Online Culling Tool}
+\chapter{Online Visibility Culling}
 %*****************************************************************************
+\label{chap:online}
 
 \section{Introduction}
@@ -74,10 +75,10 @@
 simplicity and versatility: the method can be easily integrated in
 existing real-time rendering packages on architectures supporting the
-underlying occlusion query.  In
+underlying occlusion query~\cite{wimmer05:gpugems}.  In
 figure~\ref{fig:online_culling_example}, the same scene (top row) is
 rendered using view frustum culling (visualization in the bottom left
-image) versus online culling using occlusion queries (visualization
-in the bottom right image). It can be seen that with view frustum
-culling only many objects are still rendered.
+image) versus online culling using occlusion queries (visualization in
+the bottom right image). It can be seen that with view frustum culling
+only many objects are still rendered.
 %Using spatial and assuming temporal coherence
 
@@ -177,5 +178,5 @@
 %% occlusion trees~\cite{bittner98b_long}.
 
-On a theoretical level, our paper is related to methods aiming to
+On a theoretical level, our method is related to methods aiming to
 exploit the temporal coherence of visibility. Greene et
 al.~\cite{Greene93a} used the set of visible objects from one frame to
@@ -194,13 +195,13 @@
 acceleration technique for exploiting spatial and temporal coherence
 in hierarchical visibility algorithms. The central idea, which is also
-vital for the online culling tool, is to avoid repeated visibility tests of
-interior nodes of the hierarchy. The problem of direct adoption of
-this method is that it is designed for the use with instantaneous CPU
-based occlusion queries, whereas hardware occlusion queries exhibit
-significant latency. The method presented herein efficiently overcomes
-the problem of latency while keeping the benefits of a generality and
-simplicity of the original hierarchical technique. As a result we
-obtain a simple and efficient occlusion culling algorithm utilizing
-hardware occlusion queries.
+vital for the online occlusion culling, is to avoid repeated
+visibility tests of interior nodes of the hierarchy. The problem of
+direct adoption of this method is that it is designed for the use with
+instantaneous CPU based occlusion queries, whereas hardware occlusion
+queries exhibit significant latency. The method presented herein
+efficiently overcomes the problem of latency while keeping the
+benefits of a generality and simplicity of the original hierarchical
+technique. As a result we obtain a simple and efficient occlusion
+culling algorithm utilizing hardware occlusion queries.
 
 
@@ -209,12 +210,12 @@
 
 
-The rest of the paper is organized as follows:
-Section~\ref{sec:hwqueries} discusses hardware supported occlusion
-queries and a basic application of these queries using a kD-tree.
-Section~\ref{sec:hoq} presents our new algorithm and
-Section~\ref{sec:optimizations} describes several additional
-optimizations. Section~\ref{sec:results} presents results obtained by
-experimental evaluation of the method and discusses its
-behavior. Finally Section~\ref{sec:conclusion} concludes the paper.
+% The rest of the chapter is organized as follows:
+% Section~\ref{sec:hwqueries} discusses hardware supported occlusion
+% queries and a basic application of these queries using a kD-tree.
+% Section~\ref{sec:hoq} presents our new algorithm and
+% Section~\ref{sec:optimizations} describes several additional
+% optimizations. Section~\ref{sec:results} presents results obtained by
+% experimental evaluation of the method and discusses its
+% behavior. Finally Section~\ref{sec:conclusion} concludes the chapter.
 
 
@@ -1119,15 +1120,16 @@
 \begin{figure*}[htb]
   \centerline{
-     \includegraphics[width=0.4\textwidth,draft=\DRAFTFIGS]{images/teapots}
-     }
+    \hfill
+    \includegraphics[height=0.3\textwidth,draft=\DRAFTFIGS]{images/teapots}
+    \hfill
+    \includegraphics[height=0.3\textwidth,draft=\DRAFTFIGS]{images/city}
+    \hfill
+  }
   \centerline{
-     \includegraphics[width=0.4\textwidth,draft=\DRAFTFIGS]{images/city}
-     }
-  \centerline{
-     \includegraphics[width=0.4\textwidth,draft=\DRAFTFIGS]{images/pplant}
-     }
-   
-   \caption{The test scenes: the teapots, the city, and the power plant.}
-   \label{fig:scenes}
+    \includegraphics[width=0.35\textwidth,draft=\DRAFTFIGS]{images/pplant}
+  }
+  
+  \caption{The test scenes: the teapots, the city, and the power plant.}
+  \label{fig:scenes}
 \end{figure*}
 
Index: trunk/VUT/doc/SciReport/figs/sampling.fig
===================================================================
--- trunk/VUT/doc/SciReport/figs/sampling.fig	(revision 277)
+++ trunk/VUT/doc/SciReport/figs/sampling.fig	(revision 277)
@@ -0,0 +1,56 @@
+#FIG 3.2
+Landscape
+Center
+Inches
+Letter  
+100.00
+Single
+-2
+1200 2
+1 3 0 2 0 4 50 -1 20 0.000 1 0.0000 2932 3599 375 375 2932 3599 3307 3599
+1 3 0 2 0 7 50 -1 16 0.000 1 0.0000 4624 3790 318 318 4624 3790 4942 3790
+1 3 0 2 0 7 50 -1 16 0.000 1 0.0000 5850 4125 168 168 5850 4125 5925 4275
+1 3 0 2 0 7 50 -1 16 0.000 1 0.0000 7500 2775 530 530 7500 2775 7875 3150
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+	1 1 2.00 120.00 240.00
+	 3150 3300 4500 2025
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 7 1 0 2
+	1 1 2.00 120.00 240.00
+	 3300 3450 7500 2100
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+	1 1 2.00 120.00 240.00
+	 3300 3600 6900 3000
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+	1 1 2.00 120.00 240.00
+	 3225 3375 8400 3450
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+	1 1 2.00 120.00 240.00
+	 2925 4050 2775 5325
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+	1 1 2.00 120.00 240.00
+	 3375 3750 7125 5250
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+	1 1 2.00 120.00 240.00
+	 2700 3225 2550 2100
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+	1 1 2.00 120.00 240.00
+	 3225 3975 5250 5250
+2 2 0 5 15 7 55 -1 -1 0.000 0 0 -1 0 0 5
+	 2100 1800 8700 1800 8700 5700 2100 5700 2100 1800
+2 1 0 5 15 7 55 -1 -1 0.000 0 0 7 0 0 2
+	 2100 3000 6300 3000
+2 1 0 5 15 7 55 -1 -1 0.000 0 0 7 0 0 2
+	 2100 4350 4200 4350
+2 1 0 5 15 7 55 -1 -1 0.000 0 0 7 0 0 2
+	 4200 3000 4200 5700
+2 1 0 5 15 7 55 -1 -1 0.000 0 0 7 0 0 2
+	 5250 3000 5250 4500
+2 1 0 5 15 7 55 -1 -1 0.000 0 0 7 0 0 2
+	 4200 4500 6300 4500
+2 1 0 5 15 7 55 -1 -1 0.000 0 0 7 0 0 2
+	 6300 1800 6300 5700
+2 1 0 5 15 7 55 -1 -1 0.000 0 0 7 0 0 2
+	 6300 3900 8700 3900
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 7 1 0 2
+	1 1 2.00 120.00 240.00
+	 3375 3675 4275 3750
Index: trunk/VUT/doc/SciReport/Bib/new.bib
===================================================================
--- trunk/VUT/doc/SciReport/Bib/new.bib	(revision 251)
+++ trunk/VUT/doc/SciReport/Bib/new.bib	(revision 277)
@@ -1,2 +1,117 @@
+@Article{avis96,
+  author = "David Avis and Komei Fukuda",
+  title = "Reverse Search for Enumeration",
+  journal =  "Discrete Applied Mathematics",
+  year = "1996",
+  volume = "6",
+  pages = "21--46"
+}
+
+@Article{Fukuda:1996:DDM,
+  author =       "K. Fukuda and A. Prodon",
+  title =        "Double Description Method Revisited",
+  journal =      "Lecture Notes in Computer Science",
+  volume =       "1120",
+  pages =        "91--111",
+  year =         "1996",
+  coden =        "LNCSD9",
+  ISSN =         "0302-9743",
+  bibdate =      "Mon Aug 25 16:23:54 MDT 1997",
+  acknowledgement = ack-nhfb,
+}
+
+@Misc{lrs_site,
+  author = 	 {David Avis},
+  title  = 	 {LRS polyhedra enumeration library},
+  year   =       {2002},
+  note    = 	 "Available at \url{http://cgm.cs.mcgill.ca/~avis/C/lrs.html}",
+}
+
+@InProceedings{buehler2001,
+  pages =        "425--432",
+  year =         "2001",
+  title =        "Unstructured Lumigraph Rendering",
+  author =       "Chris Buehler and Michael Bosse and Leonard McMillan
+                 and Steven J. Gortler and Michael F. Cohen",
+  abstract =     "We describe an image based rendering approach that
+                 generalizes many current image based rendering
+                 algorithms, including light field rendering and
+                 view-dependent texture mapping. In particular, it
+                 allows for lumigraph-style rendering from a set of
+                 input cameras in arbitrary configurations (i.e., not
+                 restricted to a plane or to any specific manifold). In
+                 the case of regular and planar input camera positions,
+                 our algorithm reduces to a typical lumigraph approach.
+                 When presented with fewer cameras and good approximate
+                 geometry, our algorithm behaves like view-dependent
+                 texture mapping. The algorithm achieves this
+                 flexibility because it is designed to meet a set of
+                 specific goals that we describe. We demonstrate this
+                 flexibility with a variety of examples.",
+  keywords =     "Image-Based Rendering",
+  booktitle =    "Computer Graphics (SIGGRAPH '01 Proceedings)",
+}
+
+@InProceedings{haumont2005:egsr,
+  pages =        "211--222",
+  year =         "2005",
+  title =        "A Low Dimensional Framework for Exact Polygon-to-Polygon Occlusion Queries",
+  author =       {Denis Haumont and Otso M\"{a}kinen and Shaun Nirenstein},
+  booktitle =    "Proceedings of Eurographics Symposium on Rendering",
+}
+
+
+
+@InProceedings{Sadagic,
+  pages =        "111--122",
+  year =         "2000",
+  title =        "Dynamic Polygon Visibility Ordering for Head-Slaved
+                 Viewing in Virtual Environments",
+  author =       "Amela Sadagic and Mel Slater",
+  url =          "http://visinfo.zib.de/EVlib/Show?EVL-2000-336",
+  abstract =     "This paper presents an approach to visibility called
+                 the Viewpoint Movement Space (VpMS) algorithm which
+                 supports the concept of dynamic polygon visibility
+                 orderings for head-slaved viewing in virtual
+                 environments (VE). The central idea of the approach is
+                 that the visibility, in terms of back-to-front polygon
+                 visibility ordering, does not change dramatically as
+                 the viewpoint moves. Moreover, it is possible to
+                 construct a partition of the space into cells, where
+                 for each cell the ordering is invariant. As the
+                 viewpoint moves across a cell boundary typically only a
+                 small and predictable change is made to the visibility
+                 ordering. The cost to perform this operation represents
+                 a notable reduction when compared with the cost of
+                 resolving the visibility information from the BSP tree
+                 where the classification of the viewpoint with every
+                 node plane has to be performed. The paper demonstrates
+                 how the subdivision into such cells can represent the
+                 basic source for an acceleration of the rendering
+                 process. We also discuss how the same supportive data
+                 structure can be exploited to solve other tasks in the
+                 graphics pipeline.",
+  organization = "Eurographics Association",
+  volume =       "19(2)",
+  booktitle =    "Computer Graphics Forum",
+}
+
+@Book{dcg-handbook,
+  title =        "Handbook of Discrete and Computational Geometry",
+  booktitle =    "Handbook of Discrete and Computational Geometry",
+  publisher =    "CRC Press",
+  year =         "1997",
+  editor =       "Jacob E. Goodman and Joseph O'Rourke",
+}
+
+@PhdThesis{Pu98-DSGIV,
+  author =       "Fan-Tao Pu",
+  year =         "1998",
+  title =        "Data Structures for Global Illumination and Visibility
+                 Queries in 3-Space",
+  address =      "College Park, MD",
+  school =       "University of Maryland",
+}
+
 @TechReport{Hillesland02,
   author =       "Karl Hillesland and Brian Salomon and Anselmo Lastra
Index: trunk/VUT/doc/SciReport/Bib/jiri.bib
===================================================================
--- trunk/VUT/doc/SciReport/Bib/jiri.bib	(revision 243)
+++ trunk/VUT/doc/SciReport/Bib/jiri.bib	(revision 277)
@@ -1,2 +1,11 @@
+@Article{wimmer05:gpugems,
+  author = 	 {Michael Wimmer and Ji\v{r}\'\i{} Bittner},
+  title = 	 {Hardware Occlusion Queries Made Useful},
+  journal = 	 {GPU Gems 2: Programming Techniques for High-Performance Graphics and General-Purpose Computation},
+  year = 	 {2005},
+  pages = 	 {91--108},
+  publisher = {Addison Wesley}
+}
+
 @Article{bittner03:jep,
   author = 	 {Ji\v{r}\'\i{} Bittner and Peter Wonka},
@@ -12,5 +21,5 @@
 
 
-@PhdThesis{bittner:03:phd,
+@PhdThesis{bittner:02:phd,
   author = 	 {Ji\v{r}\'\i{} Bittner},
   title = 	 {Hierarchical Techniques for Visibility Computations},
Index: trunk/VUT/doc/SciReport/mutual.tex
===================================================================
--- trunk/VUT/doc/SciReport/mutual.tex	(revision 273)
+++ trunk/VUT/doc/SciReport/mutual.tex	(revision 277)
@@ -1,16 +1,18 @@
-\chapter{Mutual Visibility Tool}
-
-
-If a fast visibility solution is required such as during the
-development cycle then the aggresive visibility sampling discussed in
-the previous chapter is a good candidate. However for final solution
-(production) we should either be sure that there can be no visible
-error due to the preprocessed visibility or the error is suffieciently
-small and thus not noticable.
-
-The verification starts with identifiying a minimal set of object/view
-cell pairs which are classified as mutually invisible. We process the
-objects sequentially and for every given object we determine the view
-cells which form the boundary of the invisible view cell set.
+\chapter{Mutual Visibility Verification}
+
+\label{chap:mutual}
+
+The aggressive visibility sampling discussed in the previous chapter is
+a good candidate if a fast visibility solution is required (e.g.
+during the development cycle). However for final solution (production)
+we should either be sure that there can be no visible error due to the
+preprocessed visibility or the error is sufficiently small and thus
+not noticeable.
+
+The mutual visibility verification starts with identifying a minimal
+set of object/view cell pairs which are classified as mutually
+invisible. We process the objects sequentially and for every given
+object we determine the view cells which form the boundary of the
+invisible view cell set.
 
 This boundary it is based on the current view cell visibility
@@ -35,5 +37,5 @@
 Below, we describe three different mutual visibility verification
 algorithms. The first algorithm which is described in most detail
-computes exact visibility. The second one is a coservative algorithm
+computes exact visibility. The second one is a conservative algorithm
 and the third one is an approximate algorithm with a guaranteed error
 bound.
@@ -53,13 +55,14 @@
 
  The occlusion tree for the visibility from region problem is a 5D BSP
-tree maintaining a collection of the 5D blocker polyhedra. The tree is
-constructed for each source polygon $P_S$ and represents all rays
-emerging from $P_S$. Each node $N$ of the tree represents a subset of
-line space ${\mathcal Q^*_N}$. The root of the tree represents the
-whole problem-relevant line set ${\mathcal L}_R$. If $N$ is an
-interior node, it is associated with a \plucker plane $\pplane_N$.
-Left child of $N$ represents ${\mathcal Q^*_N} \cap \pplane^-_N$,
-right child ${\mathcal Q^*_N} \cap \pplane^+_N$, where $\pplane^-_N$
-and $\pplane^+_N$ are halfspaces induced by $\pplane_N$.
+tree maintaining a collection of the 5D blocker
+polyhedra~\cite{bittner:02:phd}. The tree is constructed for each
+source polygon $P_S$ and represents all rays emerging from $P_S$. Each
+node $N$ of the tree represents a subset of line space ${\mathcal
+Q^*_N}$. The root of the tree represents the whole problem-relevant
+line set ${\mathcal L}_R$. If $N$ is an interior node, it is
+associated with a \plucker plane $\pplane_N$.  Left child of $N$
+represents ${\mathcal Q^*_N} \cap \pplane^-_N$, right child ${\mathcal
+Q^*_N} \cap \pplane^+_N$, where $\pplane^-_N$ and $\pplane^+_N$ are
+halfspaces induced by $\pplane_N$.
 
  Leaves of the occlusion tree are classified $in$ or $out$. If $N$ is
@@ -79,5 +82,5 @@
 are represented by polyhedra P1, P2 and P3. The occlusion tree represents a union
 of the polyhedra. Note that P2 has been split during the insertion process.}
-\label{fig:duality2d}
+\label{fig:ot}
 \end{figure}
 
@@ -200,5 +203,5 @@
 
 
-\section{Visibility test}
+\subsection{Visibility test}
 
 \label{sec:rot3d_vistest}
@@ -216,12 +219,46 @@
 tested for visibility by the traversal of the occlusion tree. The
 visibility test proceeds as the algorithms described in
-Section~\ref{sec:rot3d_construct}, but no modifications to the tree are
-performed. If the polyhedron is classified as visible in all reached
-leaves, the current face is fully visible. If the polyhedron is
-invisible in all reached leaves, the face is invisible. Otherwise it
-is partially visible since some rays connecting the face and the
+Section~\ref{sec:rot3d_construct}, but no modifications to the tree
+are performed. If the polyhedron is classified as visible in all
+reached leaves, the current face is fully visible. If the polyhedron
+is invisible in all reached leaves, the face is invisible. Otherwise
+it is partially visible since some rays connecting the face and the
 source polygon are occluded and some are unoccluded. The visibility of
-the whole region is computed using a combination of visibility states
-of its boundary faces according to Table~\ref{table:vis_states}.
+the whole region can computed using a combination of visibility states
+of its boundary faces according to
+Table~\ref{table:vis_states}. However, since we are interested only in
+verification of mutual invisibility as soon as we find a first visible
+fragment the test can be terminated.
+
+\begin{table}[htb]
+\begin{center}
+\begin{tabular}{|c|c||c|}
+\hline
+Fragment A & Fragment B & A $\cup$ B \\
+\hline
+\hline
+F & F & F\\
+\hline
+I & I & I\\
+\hline
+I & F & P\\
+\hline
+F & I & P\\
+\hline
+P & $*$ & P\\
+\hline
+$*$ & P & P\\ 
+\hline
+\end{tabular}
+\begin{tabular}{cl}
+I  & -- invisible\\
+P    & -- partially visible\\
+F  & -- fully visible\\
+$*$  & -- any of the I,P,F states
+\end{tabular}
+\end{center}
+\caption{Combining visibility states of two fragments.}
+\label{table:vis_states}
+\end{table}
 
 
@@ -342,5 +379,5 @@
 visibility verifier described above. The verifier is an extension of
 the strong occlusion algorithm of Cohen-Or et
-al.~\cite{cohen-egc-98}. In particular our verfier refines the search
+al.~\cite{cohen-egc-98}. In particular our verifier refines the search
 for a strong occluder by using a hierarchical subdivision of space of
 lines connecting the two regions tested for mutual
@@ -359,9 +396,9 @@
 \item If the rays do not intersect a single convex object four new
 shafts are constructed by splitting both regions in half and the
-process is repeated recursivelly.
+process is repeated recursively.
 \end{itemize}
 
 If the subdivision does not terminate till reaching a predefined
-subdivision depth, we conservativelly classify the tested regions as
+subdivision depth, we conservatively classify the tested regions as
 mutually visible.
 
@@ -425,9 +462,9 @@
 \label{sec:rot3d_summary}
 
- This chapter presented a mutual visibility tool, which determines
+ This chapter presented a mutual visibility verification algorithms, which determine
  whether two regions in the scene are visible.
 
- First, we have described an advanced exact visibility algorithm which
-is a simple of modification of an algorithm for computing from-region
+ First, we have described an exact visibility algorithm which is a
+simple of modification of an algorithm for computing from-region
 visibility in polygonal scenes. The key idea is a hierarchical
 subdivision of the problem-relevant line set using \plucker
@@ -449,10 +486,9 @@
 Second, we have described a conservative verifier which is an
 extension of the algorithm based on strong occluders. The conservative
-verifier is requires a specification of the shaft size at which the
-tested regions are conservativelly classfied as visible.
-
-Third, we have described an approximate error bound verifier which is
-an extension of the algorithm based on strong occluders. The
-conservative verifier is requires a specification of the shaft size at
-which the tested regions are conservativelly classfied as visible.
-
+verifier requires a specification of the shaft size at which the
+tested regions are conservatively classified as visible.
+
+Third, we have described an approximate error bound verifier which
+extends the conservative verifier by using automatic termination
+criteria based on the estimation of maximal error for the given shaft.
+
Index: trunk/VUT/doc/SciReport/pdfpages.sty
===================================================================
--- trunk/VUT/doc/SciReport/pdfpages.sty	(revision 277)
+++ trunk/VUT/doc/SciReport/pdfpages.sty	(revision 277)
@@ -0,0 +1,455 @@
+%%
+%% This is file `pdfpages.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% pdfpages.dtx  (with options: `package')
+%% 
+%% This is a pdfLaTeX package for including pages
+%% of external PDF documents.
+%% 
+%% This file is part of the pdfpages package.
+%% 
+%%
+%% \CharacterTable
+%%  {Upper-case    \A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z
+%%   Lower-case    \a\b\c\d\e\f\g\h\i\j\k\l\m\n\o\p\q\r\s\t\u\v\w\x\y\z
+%%   Digits        \0\1\2\3\4\5\6\7\8\9
+%%   Exclamation   \!     Double quote  \"     Hash (number) \#
+%%   Dollar        \$     Percent       \%     Ampersand     \&
+%%   Acute accent  \'     Left paren    \(     Right paren   \)
+%%   Asterisk      \*     Plus          \+     Comma         \,
+%%   Minus         \-     Point         \.     Solidus       \/
+%%   Colon         \:     Semicolon     \;     Less than     \<
+%%   Equals        \=     Greater than  \>     Question mark \?
+%%   Commercial at \@     Left bracket  \[     Backslash     \\
+%%   Right bracket \]     Circumflex    \^     Underscore    \_
+%%   Grave accent  \`     Left brace    \{     Vertical bar  \|
+%%   Right brace   \}     Tilde         \~}
+%%
+\NeedsTeXFormat{LaTeX2e}
+\ProvidesPackage{pdfpages}[2001/04/10 v0.1h4 Include pages of external PDF documents (AM)]
+\begingroup
+\@ifundefined{pdfoutput}
+    {\PackageError{pdfpages}
+            {You're either not using pdfLaTeX\MessageBreak
+             or have turn off PDF output.\MessageBreak
+             `pdfpages' works only with pdfLaTeX\MessageBreak
+             and PDF output}
+            {Use `pdflatex' instead of `latex'\MessageBreak
+             and set output to PDF (use: \pdfoutput = 1)!}
+     \expandafter\endinput
+    }{}
+\ifnum\pdfoutput=0
+    \PackageError{pdfpages}
+            {You don't produce PDF output, which\MessageBreak
+             is required for the `pdfpages' package}
+            {Set output to PDF. (use: \pdfoutput = 1)}
+    \expandafter\endinput
+\fi
+\endgroup
+\def\AM@ifdriverlater{\@ifl@ter{def}}
+\AtBeginDocument{%
+  \AM@ifdriverlater{pdftex}{2000/05/12}{}{%
+      \PackageError{pdfpages}{%
+           You have an old `pdftex.def'.\MessageBreak%
+           There is no multipage support\MessageBreak%
+           in `pdftex.def' < 0.02u.\MessageBreak%
+           Update your `pdftex.def'}
+           {Update your `pdftex.def'!}}
+  \AM@ifdriverlater{pdftex}{2000/09/14}{}{%
+      \PackageWarning{pdfpages}{%
+           You have an old `pdftex.def'.\MessageBreak%
+           There might be problems with\MessageBreak%
+           the `trim' and `clip' options.\MessageBreak%
+           Update your `pdftex.def'!\MessageBreak}}
+}% AtBeginDocument
+\RequirePackage{ifthen, graphicx, eso-pic, calc}
+\newcommand{\AM@draft}{false}
+\DeclareOption{draft}{\def\AM@draft{true}}
+\DeclareOption{final}{\def\AM@draft{false}}
+\ProcessOptions
+\newboolean{AM@openright}\setboolean{AM@openright}{false}
+\newboolean{AM@frame}\setboolean{AM@frame}{false}
+\newboolean{AM@landscape}\setboolean{AM@landscape}{false}
+\newboolean{AM@turn}\setboolean{AM@turn}{true}
+\newboolean{AM@thread}\setboolean{AM@thread}{false}
+\newboolean{AM@link}\setboolean{AM@link}{false}
+\newboolean{AM@linktodoc}\setboolean{AM@linktodoc}{false}
+\newboolean{AM@compatibility}\setboolean{AM@compatibility}{false}
+\newcommand{\AM@xoffset}{0pt}\newcommand{\AM@yoffset}{0pt}
+\newcommand{\AM@deltax}{0pt}\newcommand{\AM@deltay}{0pt}
+\newcommand{\AM@xpos}{0pt}\newcommand{\AM@ypos}{0pt}
+\newcommand{\AM@rotate}{0}
+\newcommand{\AM@lscape@roti}{0}\newcommand{\AM@lscape@rotii}{0}
+\newcommand{\AM@pagecommand}{\thispagestyle{empty}}
+\newcommand{\AM@fbox}{}\newcommand{\AM@ph}{}
+\newcommand{\AM@pagestemp}{1}
+\newcommand{\AM@page}{}
+\newcommand{\AM@pagei}{}\newcommand{\AM@pageii}{}
+\newcommand{\AM@pageiii}{}\newcommand{\AM@pageiv}{}
+\newcommand{\AM@@smallpage}{}\newcommand{\AM@smallpage}{\AM@@smallpage}
+\newcommand{\AM@firstpage}{1}\newcommand{\AM@lastpage}{1}
+\newcommand{\AM@nup}{1}
+\newcommand{\AM@linkname}{}
+\newcommand{\AM@threadname}{}
+\newcommand{\AM@linkfit}{fitr}
+\newcommand{\AM@linktodocfit}{/Fit}
+\newcommand{\AM@setunit}{\setlength{\unitlength}{1pt}}
+\newif\ifAM@thumbpdf
+\newif\ifAM@pdflscape
+\newcommand{\AM@setlscape}{}
+\AtBeginDocument{%
+  \@ifpackageloaded{thumbpdf}{\AM@thumbpdftrue}{\AM@thumbpdffalse}%
+  \@ifpackageloaded{pdflscape}{\AM@pdflscapetrue}{\AM@pdflscapefalse}%
+  \ifAM@thumbpdf
+    \ifAM@pdflscape
+      \def\AM@setlscape{\PLS@Rotate{90}}%
+    \else
+      \def\AM@setlscape{\pdfpageattr{/Rotate 90}\AM@thumbpdfwarning}\fi
+  \else
+    \def\AM@setlscape{\pdfpageattr{/Rotate 90}}\fi}
+\newif\ifAM@thumbpdfwarning
+\newcommand{\AM@thumbpdfwarning}{%
+  \ifAM@thumbpdfwarning\else\global\AM@thumbpdfwarningtrue
+  \PackageWarning{pdfpages}{%
+    You are using `thumbpdf.sty' but not\MessageBreak
+    `pdflscape.sty'. \MessageBreak
+    Please include `pdflscape.sty' in  your document\MessageBreak
+    to get a pleasant PDF document with thumbs.\MessageBreak}\fi}
+\newcommand*{\includepdfset}[1]{\setkeys{Gin}{#1}}
+\newcommand*{\includepdf}[2][]{%
+  \begingroup% setkey
+  \filename@parse{#2}
+  \@ifundefined{filename@ext}
+    {\def\AM@linkfilename{#2.pdf}}
+    {\def\AM@linkfilename{#2}}%
+  \def\AM@linkname{#2}%
+  \def\AM@threadname{#2}%
+  \setkeys{Gin}{draft=\AM@draft, #1}%
+  \ifthenelse{\boolean{AM@compatibility}}
+    {\def\AM@pagestemp{\AM@firstpage-\AM@lastpage}}{}%
+  \ifthenelse{\boolean{AM@frame}}
+         {\let\AM@fbox\fbox}{\let\AM@fbox\relax}%
+  \expandafter\AM@pagenumbers\expandafter{\AM@pagestemp}%
+  \ifthenelse{\boolean{AM@openright}}{\AM@openright}{}%
+  \AM@setphantom
+  \AM@filluppagelist
+  \setlength{\fboxsep}{0pt}%
+  \whiledo{\not\boolean{endofpagelist}}{%
+    \newpage
+    \ifthenelse{\boolean{AM@turn}}
+      {\ifthenelse{\boolean{AM@landscape}}
+         {\ifthenelse{\equal{1}{\AM@nup}}{\AM@setlscape}{}%
+          \ifthenelse{\equal{4}{\AM@nup}}{\AM@setlscape}{}}
+         {\ifthenelse{\equal{2}{\AM@nup}}{\AM@setlscape}{}}%
+      }{}%
+    \AM@getpages{\AM@nup}%
+      \ifthenelse{\equal{1}{\AM@nup}}{%
+         \def\AM@@smallpage{%
+           \includegraphics[page=\AM@page, angle=\AM@lscape@rotii,
+                            angle=\AM@rotate, #1]{#2}}%
+         \AddToShipoutPicture{\AM@setunit%
+           \let\AM@page\AM@pagei\AM@isphantom
+           \AM@output{0}{\AM@smallpage}}%
+        }{}%
+      \ifthenelse{\equal{2}{\AM@nup}}{%
+        \def\AM@@smallpage{%
+          \includegraphics[page=\AM@page, angle=90,
+                           angle=\AM@lscape@roti, angle=\AM@rotate,
+                           scale=.7071, #1]{#2}}%
+        \AddToShipoutPicture{\AM@setunit%
+          \ifthenelse{\boolean{AM@landscape}}
+            {\let\AM@page\AM@pagei\AM@isphantom
+             \AM@output{1}{\AM@smallpage}%
+             \let\AM@page\AM@pageii\AM@isphantom
+             \AM@output{2}{\AM@smallpage}}
+            {\let\AM@page\AM@pagei\AM@isphantom
+             \AM@output{2}{\AM@smallpage}%
+             \let\AM@page\AM@pageii\AM@isphantom
+             \AM@output{1}{\AM@smallpage}}}%
+      }{}%
+      \ifthenelse{\equal{4}{\AM@nup}}{%
+        \def\AM@@smallpage{%
+          \includegraphics[page=\AM@page, angle=\AM@lscape@rotii,
+                           angle=\AM@rotate, scale=.5, #1]{#2}}%
+        \AddToShipoutPicture{\AM@setunit%
+          \ifthenelse{\boolean{AM@landscape}}
+            {\let\AM@page\AM@pagei\AM@isphantom
+             \AM@output{5}{\AM@smallpage}%
+             \let\AM@page\AM@pageii\AM@isphantom
+             \AM@output{3}{\AM@smallpage}%
+             \let\AM@page\AM@pageiii\AM@isphantom
+             \AM@output{6}{\AM@smallpage}%
+             \let\AM@page\AM@pageiv\AM@isphantom
+             \AM@output{4}{\AM@smallpage}}
+            {\let\AM@page\AM@pagei\AM@isphantom
+             \AM@output{3}{\AM@smallpage}%
+             \let\AM@page\AM@pageii\AM@isphantom
+             \AM@output{4}{\AM@smallpage}%
+             \let\AM@page\AM@pageiii\AM@isphantom
+             \AM@output{5}{\AM@smallpage}%
+             \let\AM@page\AM@pageiv\AM@isphantom
+             \AM@output{6}{\AM@smallpage}}}%
+     }{}%
+    \AM@pagecommand
+    \hskip0pt
+    \newpage
+    \ifAM@pdflscape\PLS@Rotate{0}\fi
+    \ClearShipoutPicture
+  }% whiledo
+  \endgroup% setkey
+  \ClearShipoutPicture
+}% includepdf
+\newif\ifphantompage
+\newcommand{\AM@isphantom}{%
+  \expandafter\ifx\expandafter\\\AM@page\\%
+    \let\AM@page\AM@phantompage
+    \let\AM@ph\phantom
+    \phantompagefalse
+  \else
+    \let\AM@ph\relax
+    \phantompagetrue
+  \fi}
+\newcommand{\AM@hyper}{%
+  \ifphantompage
+  \ifthenelse{\boolean{AM@link}}{%
+    \pdfdest name {\AM@linkname.\AM@page}%
+             \AM@linkfit}{}%
+  \fi
+  \ifthenelse{\boolean{AM@linktodoc}}{%
+    \@tempcntb\AM@page\relax
+    \advance\@tempcntb by -1
+    \pdfannot width \wd\@tempboxa
+              height \ht\@tempboxa
+              depth \dp\@tempboxa
+              {/Subtype /Link /Border [0 0 0]
+               /A << /S /GoToR /F (\AM@linkfilename)
+                     /D [\the\@tempcntb \AM@linktodocfit]
+                     /NewWindow true >>}}{}%}%
+  \ifphantompage
+  \ifthenelse{\boolean{AM@thread}}{%
+      \pdfthread width \wd\@tempboxa
+                 height \ht\@tempboxa
+                 depth \dp\@tempboxa
+                 name {\AM@threadname}}{}%
+  \fi}%
+\newcommand{\AM@output}[2]{%
+  \setbox\@tempboxa=\hbox{\AM@fbox{#2}}%
+  \def\AM@add{+}%
+  \if@twoside\ifodd\value{page}\else\def\AM@add{-}\fi\fi
+  \ifcase#1 % nup=1
+    \def\AM@xpos{.5\paperwidth - .5\wd\@tempboxa \AM@add\AM@xoffset}%
+    \def\AM@ypos{.5\paperheight - .5\ht\@tempboxa - .5\dp\@tempboxa
+                 \AM@add\AM@yoffset}%
+  \or % nup=2
+    \def\AM@xpos{.5\paperwidth - .5\wd\@tempboxa \AM@add\AM@xoffset}%
+    \def\AM@ypos{.5\paperheight + \AM@deltay*\real{.5} + \AM@yoffset
+                 - .5\fboxrule}%
+  \or
+    \def\AM@xpos{.5\paperwidth - .5\wd\@tempboxa \AM@add\AM@xoffset}%
+    \def\AM@ypos{.5\paperheight - \ht\@tempboxa - \dp\@tempboxa
+                 - \AM@deltay*\real{.5} + \AM@yoffset + .5\fboxrule}%
+  \or % nup=4
+    \def\AM@xpos{.5\paperwidth - \wd\@tempboxa \AM@add\AM@xoffset
+                 + .5\fboxrule - \AM@deltax*\real{.5}}%
+    \def\AM@ypos{.5\paperheight + \AM@deltay*\real{.5} + \AM@yoffset
+                 - .5\fboxrule}%
+  \or
+    \def\AM@xpos{.5\paperwidth \AM@add\AM@xoffset
+                 - .5\fboxrule + \AM@deltax*\real{.5}}%
+    \def\AM@ypos{.5\paperheight + \AM@deltay*\real{.5} + \AM@yoffset
+                 - .5\fboxrule}%
+  \or
+    \def\AM@xpos{.5\paperwidth - \wd\@tempboxa \AM@add\AM@xoffset
+                 + .5\fboxrule - \AM@deltax*\real{.5}}%
+    \def\AM@ypos{.5\paperheight - \ht\@tempboxa - \dp\@tempboxa
+                 - \AM@deltay*\real{.5} + \AM@yoffset + .5\fboxrule}%
+  \or
+    \def\AM@xpos{.5\paperwidth \AM@add\AM@xoffset
+                 - .5\fboxrule + \AM@deltax*\real{.5}}%
+    \def\AM@ypos{.5\paperheight - \ht\@tempboxa - \dp\@tempboxa
+                 - \AM@deltay*\real{.5} + \AM@yoffset + .5\fboxrule}%
+  \fi
+  \setlength{\@tempdima}{\AM@xpos}%
+  \edef\AM@xpos{\strip@pt\@tempdima}%
+  \setlength{\@tempdima}{\AM@ypos}%
+  \edef\AM@ypos{\strip@pt\@tempdima}%
+  \put(\AM@xpos,\AM@ypos){%
+    \AM@ph{\raisebox{\dp\@tempboxa}{%
+      \AM@hyper
+      \box\@tempboxa}}}%
+} % AM@output
+\newcommand{\AM@pagelist}{}
+\newcommand{\saveAM@pagelist}{}
+\newboolean{endofpagelist}
+\newcommand{\AM@pagenumbers}{1}
+\def\AM@pagenumbers#1{%
+  \AM@@pagenumbers#1,\END
+  \let\saveAM@pagelist\AM@pagelist
+  \edef\AM@pagelist{\saveAM@pagelist\noexpand\END}%
+}
+\newcommand{\AM@@pagenumbers}{}
+\def\AM@@pagenumbers#1,#2{%
+  \AM@pagearea#1-\END
+  \ifx#2\END \def\AM@next{\relax}%
+    \else \def\AM@next{\AM@@pagenumbers #2}%
+  \fi
+  \AM@next
+}
+\newcommand{\AM@pagearea}{}
+\def\AM@pagearea#1-#2\END{%
+  \ifx\\#2\\%
+    \AM@addtopagelist{#1}%
+  \else
+    \AM@last#2
+    \@tempcnta=#1
+    \whiledo{\@tempcnta<\@tempcntb}{%
+      \AM@addtopagelist{\the\@tempcnta}%
+      \advance\@tempcnta by 1
+    }%
+  \fi}
+\newcommand{\AM@last}{}
+\def\AM@last#1-{%
+  \@tempcntb=#1 \advance\@tempcntb by 1
+  \def\lastpage{#1}%
+}
+\newcommand{\AM@addtopagelist}{}
+\def\AM@addtopagelist#1{%
+  \let\saveAM@pagelist\AM@pagelist
+  \edef\AM@pagelist{\saveAM@pagelist#1,}%
+}
+\newcommand{\AM@openright}{}
+\def\AM@openright{\expandafter\AM@@openright\AM@pagelist}
+\newcommand{\AM@@openright}{}
+\def\AM@@openright#1\END{%
+  \edef\AM@pagelist{,#1\noexpand\END}%
+}
+\newcommand{\AM@getpages}{}
+\def\AM@getpages#1{%
+  \ifcase#1
+    \or
+    \expandafter\AM@getipages\AM@pagelist \or
+    \expandafter\AM@getiipages\AM@pagelist \or\or
+    \expandafter\AM@getivpages\AM@pagelist \fi
+}
+
+\newcommand{\AM@getipages}{}
+\def\AM@getipages#1,#2\END{%
+  \def\AM@pagei{#1}%
+  %remove page from list
+  \def\AM@pagelist{#2\END}%
+  % checking end of list
+  \ifx\\#2\\\setboolean{endofpagelist}{true}\fi
+}
+\newcommand{\AM@getiipages}{}
+\def\AM@getiipages#1,#2,#3\END{%
+  \def\AM@pagei{#1}%
+  \def\AM@pageii{#2}%
+  %remove pages from list
+  \def\AM@pagelist{#3\END}%
+  % checking end of list
+  \ifx\\#3\\\setboolean{endofpagelist}{true}\fi
+}
+\newcommand{\AM@getivpages}{}
+\def\AM@getivpages#1,#2,#3,#4,#5\END{%
+  \def\AM@pagei{#1}%
+  \def\AM@pageii{#2}%
+  \def\AM@pageiii{#3}%
+  \def\AM@pageiv{#4}%
+  %remove pages from list
+  \def\AM@pagelist{#5\END}%
+  % checking end of list
+  \ifx\\#5\\\setboolean{endofpagelist}{true}\fi
+}
+\newcommand{\AM@countpagelist}{}
+\def\AM@countpagelist{%
+  \@tempcnta=0 \expandafter\AM@@countpagelist\AM@pagelist}
+\newcommand{\AM@@countpagelist}{}
+\def\AM@@countpagelist#1,#2{%
+  \ifx#2\END\def\AM@next{\relax}%
+    \else\def\AM@next{\AM@@countpagelist #2}%
+  \fi
+  \advance\@tempcnta by 1
+  \AM@next
+}
+\newcommand{\AM@filluppagelist}{}
+\def\AM@filluppagelist{%
+  \AM@countpagelist
+  \@tempcntb=\@tempcnta
+  \divide\@tempcntb by \AM@nup%
+  \multiply\@tempcntb by \AM@nup%
+  \advance\@tempcnta by -\@tempcntb
+  \ifnum\@tempcnta=0
+    \else
+      \advance\@tempcnta by -\AM@nup%
+      \multiply\@tempcnta by -1
+  \fi
+  \expandafter\AM@removeend\AM@pagelist
+  \whiledo{\@tempcnta > 0}{%
+    \let\saveAM@pagelist\AM@pagelist
+    \edef\AM@pagelist{\saveAM@pagelist ,}%
+    \advance\@tempcnta by -1
+  }%
+  \let\saveAM@pagelist\AM@pagelist
+  \edef\AM@pagelist{\saveAM@pagelist\noexpand\END}%
+}
+\newcommand{\AM@removeend}{}
+\def\AM@removeend#1\END{%
+  \let\saveAM@pagelist\AM@pagelist
+  \edef\AM@pagelist{#1}%
+}
+\newcommand{\AM@setphantom}{}
+\def\AM@setphantom{\expandafter\AM@@setphantom\AM@pagelist}
+\newcommand{\AM@@setphantom}{}
+\def\AM@@setphantom#1,#2\END{%
+  \ifx\\#1\\ \def\AM@next{\AM@@setphantom#2\END}%
+  \else
+    \edef\AM@phantompage{#1}%
+    \def\AM@next{\relax}%
+  \fi
+  \AM@next
+}
+\define@key{Gin}{pages}{\def\AM@pagestemp{#1}}
+\define@key{Gin}{nup}{\def\AM@nup{#1}}
+\define@key{Gin}{deltax}{\AM@parse@deltax#1 \\}
+\define@key{Gin}{deltay}{\AM@parse@deltay#1 \\}
+\define@key{Gin}{offset}{\AM@parse@offset#1 \\}
+\define@key{Gin}{frame}[true]{\setboolean{AM@frame}{#1}}
+\define@key{Gin}{openright}[true]{\setboolean{AM@openright}{#1}}
+\define@key{Gin}{pagecommand}{\renewcommand{\AM@pagecommand}{#1}}
+\define@key{Gin}{rotate}{\def\AM@rotate{#1}}
+\define@key{Gin}{landscape}[true]{\setboolean{AM@landscape}{#1}%
+                                  \def\AM@lscape@roti{-90}%
+                                  \def\AM@lscape@rotii{90}}
+\define@key{Gin}{turn}[true]{\setboolean{AM@turn}{#1}}
+\define@key{Gin}{firstpage}{\def\AM@firstpage{#1}%
+                            \setboolean{AM@compatibility}{true}}
+\define@key{Gin}{lastpage}{\def\AM@lastpage{#1}%
+                           \setboolean{AM@compatibility}{true}}
+\define@key{Gin}{thread}[true]{\setboolean{AM@thread}{#1}}
+\define@key{Gin}{threadname}{\def\AM@threadname{#1}}
+\define@key{Gin}{link}[true]{\setboolean{AM@link}{#1}}
+\define@key{Gin}{linkfit}{\def\AM@linkfit{#1}}
+\define@key{Gin}{linkname}{\def\AM@linkname{#1}}
+\define@key{Gin}{linktodoc}[true]{\setboolean{AM@linktodoc}{#1}}
+\define@key{Gin}{linktodocfit}{\def\AM@linktodocfit{#1}}
+\define@key{Gin}{linkfilename}{\pdfstringdef\AM@linkfilename{#1}}
+\def\AM@parse@deltax#1 #2\\{\AMGin@defaultbp\AM@deltax{#1}}
+\def\AM@parse@deltay#1 #2\\{\AMGin@defaultbp\AM@deltay{#1}}
+\def\AM@parse@offset#1 #2 #3\\{%
+  \AMGin@defaultbp\AM@xoffset{#1}%
+  \AMGin@defaultbp\AM@yoffset{#2}}
+\def\AMGin@defaultbp#1#2{%
+  \afterassignment\AMGin@def@bp\dimen@#2bp\relax{#1}{#2}}
+\def\AMGin@def@bp#1\relax#2#3{%
+   \if!#1!%
+     \def#2{#3bp}%
+    \else
+      \dimen@.99626\dimen@
+      \edef#2{\strip@pt\dimen@ bp}%
+    \fi}
+\endinput
+%%
+%% End of file `pdfpages.sty'.
Index: trunk/VUT/doc/SciReport/sampling.tex
===================================================================
--- trunk/VUT/doc/SciReport/sampling.tex	(revision 273)
+++ trunk/VUT/doc/SciReport/sampling.tex	(revision 277)
@@ -1,4 +1,5 @@
-\chapter{Global Visibility Sampling Tool}
-
+\chapter{Global Visibility Sampling}
+
+\label{chap:sampling}
 
 The proposed visibility preprocessing framework consists of two major
@@ -6,24 +7,25 @@
 
 \begin{itemize}
-\item The first step is an aggresive visibility sampling which gives
+\item The first step is an aggressive visibility sampling which gives
 initial estimate about global visibility in the scene. The sampling
 itself involves several strategies which will be described bellow.
-The imporant property of the aggresive sampling step is that it
+The important property of the aggressive sampling step is that it
 provides a fast progressive solution to global visibility and thus it
 can be easily integrated into the game development cycle. The
-aggresive sampling will terminate when the average contribution of new
+aggressive sampling will terminate when the average contribution of new
 ray samples falls bellow a predefined threshold.
 
 \item The second step is mutual visibility verification. This step
-turns the previous aggresive visibility solution into either exact,
-conservative or error bound aggresive solution. The choice of the
+turns the previous aggressive visibility solution into either exact,
+conservative or error bound aggressive solution. The choice of the
 particular verifier is left on the user in order to select the best
 one for a particular scene, application context and time
 constrains. For example, in scenes like a forest an error bound
-aggresive visibility can be the best compromise between the resulting
-size of the PVS (and framerate) and the visual quality. The exact or
+aggressive visibility can be the best compromise between the resulting
+size of the PVS (and frame rate) and the visual quality. The exact or
 conservative algorithm can however be chosen for urban scenes where
-ommision of even small objects can be more distructing for the
-user. The mutual visibility tool will be described in the next chapter.
+omission of even small objects can be more distracting for the
+user. The mutual visibility verification will be described in the next
+chapter.
 
 \end{itemize}
@@ -31,9 +33,9 @@
 In traditional visibility preprocessing the view space is
 subdivided into view cells and for each view cell the set of visible
-objects --- potentially visible set (PVS) is computed. This framewoirk
-has been used for conservative, aggresive and exact algorithms.
+objects --- potentially visible set (PVS) is computed. This framework
+has been used for conservative, aggressive and exact algorithms.
 
 We propose a different strategy which has several advantages for
-sampling based aggresive visibility preprocessing. The stategy is
+sampling based aggressive visibility preprocessing. The strategy is
 based on the following fundamental ideas:
 \begin{itemize}
@@ -63,5 +65,5 @@
 the partitioning. The major drawback of this approach is that for
 polygonal scenes with $n$ polygons there can be $\Theta(n^9)$ cells in
-the partitioning for unrestricted viewspace. A {\em scale space}
+the partitioning for unrestricted view space. A {\em scale space}
 aspect graph~\cite{bb12595,bb12590} improves robustness of the method
 by merging similar features according to the given scale.
@@ -121,5 +123,5 @@
 The exact mutual visibility method presented later in the report is
 based on method exploting \plucker coordinates of
-lines~\cite{bittner02phd,nirenstein:02:egwr,haumont2005}. This
+lines~\cite{bittner:02:phd,nirenstein:02:egwr,haumont2005:egsr}. This
 algorithm uses \plucker coordinates to compute visibility in shafts
 defined by each polygon in the scene.
@@ -242,13 +244,4 @@
 
 
-\begin{figure}[htb]
-  \centerline{
-    \includegraphics[height=0.35\textwidth,draft=\DRAFTFIGS]{images/vienna_viewcells_01}
-     \includegraphics[height=0.35\textwidth,draft=\DRAFTFIGS]{images/vienna_viewcells_07}
-    }
-
-  \caption{(left) Vienna viewcells. (right) The view cells are prisms with a triangular base. }
-  \label{fig:vienna_viewcells}
-\end{figure}
 
 
@@ -257,5 +250,5 @@
 partition of the scene into view cells is an essential part of every
 visibility system. If they are chosen too large, the PVS (Potentially
-Visibible Set)  of a view cells is too large for efficient culling. If
+Visible Set)  of a view cells is too large for efficient culling. If
 they are chosen too small or without consideration, then neighbouring
 view cells contain redundant PVS information, hence boosting the PVS
@@ -266,4 +259,14 @@
 height to form a view cell prism.
 
+\begin{figure}[htb]
+  \centerline{
+    \includegraphics[height=0.35\textwidth,draft=\DRAFTFIGS]{images/vienna_viewcells_01}
+     \includegraphics[height=0.35\textwidth,draft=\DRAFTFIGS]{images/vienna_viewcells_07}
+    }
+
+  \caption{(left) Vienna view cells. (right) The view cells are prisms with a triangular base. }
+  \label{fig:vienna_viewcells}
+\end{figure}
+
 In order to efficiently use view cells with our sampling method, we
 require a view cell representation which is
@@ -275,16 +278,19 @@
 \end{itemize}
 
-We meet these requirements by employing spatial subdivisions (i.e., 
-KD trees and BSP trees), to store the view cells. The initial view cells are
-associated with the leaves. The reason why we chose BSP trees as view cell representation 
-is that they are very flexible. View cells forming arbitrary closed meshes can be closely matched.
-Therefore we are able to find a view cells with only a few view ray-plane
-intersections.  Furthermore, the hierarchical structures can be
-exploited as hierarchy of view cells. Interior nodes form larger view cells
-containing the children. If neccessary, a leaf can be easily subdivided into smaller view cells.
-
-Currently we consider three different approaches to generate the initial view cell BSP tree.
-The third method is not restricted to BSP trees, but BSP trees are prefered 
-because of their greater flexibility.
+We meet these requirements by employing spatial subdivisions (i.e.,
+KD trees and BSP trees), to store the view cells. The initial view
+cells are associated with the leaves. The reason why we chose BSP
+trees as view cell representation  is that they are very
+flexible. View cells forming arbitrary closed meshes can be closely
+matched.  Therefore we are able to find a view cells with only a few
+view ray-plane intersections.  Furthermore, the hierarchical
+structures can be exploited as hierarchy of view cells. Interior nodes
+form larger view cells containing the children. If necessary, a leaf
+can be easily subdivided into smaller view cells.
+
+Currently we consider three different approaches to generate the
+initial view cell BSP tree.  The third method is not restricted to BSP
+trees, but BSP trees are preferred  because of their greater
+flexibility.
 
 
@@ -303,5 +309,5 @@
   \#splits & 25 & 188936\\\hline\hline
   max tree depth & 13 & 27\\\hline\hline
-  avg tree depth & 9.747 & 21.11\\\hline\hlien
+  avg tree depth & 9.747 & 21.11\\\hline\hline
   
  \end{tabular}
@@ -312,56 +318,66 @@
 \begin{itemize}
 
-\item We use a number of input view cells given in advance. As input view cell 
-any closed mesh can be applied. The only requirement is that the
-any two view cells do not overlap. 
-First the view cell polygons are extracted, and the BSP is build from
-these polygons using some global optimizations like tree balancing or
-least splits. Then one view cell after the other
-is inserted into the tree to find out the leafes where they are contained
-in. The polygons of the view cell are filtered down the tree,
-guiding the insertion process. Once we reach a leaf and there are no
-more polygons left, we terminate the tree subdivision. If we are on
-the inside of the last split plane (i.e., the leaf represents the
-inside of the view cell), we associate the leaf with the view cell
-(i.e., add a pointer to the view cell). One input view cell can
-be associated with many leafes, whereas each leafs has only one view cell.
-Some statistics about using this method on the vienna view cells set are given in table~\ref{tab:viewcell_bsp}.
-However, sometimes a good set of view cells is not available. Or the scene
-is changed frequently, and the designer does not want to create new view cells on each change.
-In such a case one of the following two methods should rather be chosen, which generate view cells
-automatically.
+\item We use a number of input view cells given in advance. As input
+view cell  any closed mesh can be applied. The only requirement is
+that the any two view cells do not overlap.  First the view cell
+polygons are extracted, and the BSP is build from these polygons using
+some global optimizations like tree balancing or least splits. Then
+one view cell after the other is inserted into the tree to find out
+the leaves where they are contained in. The polygons of the view cell
+are filtered down the tree, guiding the insertion process. Once we
+reach a leaf and there are no more polygons left, we terminate the
+tree subdivision. If we are on the inside of the last split plane
+(i.e., the leaf represents the inside of the view cell), we associate
+the leaf with the view cell (i.e., add a pointer to the view
+cell). One input view cell can be associated with many leaves, whereas
+each leafs has only one view cell.  Some statistics about using this
+method on the Vienna view cells set are given in
+table~\ref{tab:viewcell_bsp}.  However, sometimes a good set of view
+cells is not available. Or the scene is changed frequently, and the
+designer does not want to create new view cells on each change.  In
+such a case one of the following two methods should rather be chosen,
+which generate view cells automatically.
 
 
 \item We apply a BSP tree subdivision to the scene geometry. Whenever
-the subdivision terminates in a leaf, a view cell is associated with the leaf node.
-This simple approach is justified because it places the view cell borders 
-along some discontinuities in the visibility function.
-
-\item  The view cell generation can be guided by the sampling process. We start with
-with a single initial view cell representing the whole space. If a given threshold
-is reached during the preprocessing (e.g., the view cell is pierced by too many rays 
-resulting in a large PVS), the view cell is subdivided into smaller cells using some criteria.
-
-In order to evaluate the best split plane, we first have to define the characteristics of a
-good view cell partition:  The view cells should be quite large, while their PVS stays rather small.
-The PVS of each two view cells should be as distinct as possible, otherwise they could be
-merged into a larger view cell if the PVSs are too similar. 
-E.g., for a building, the perfect view cells are usually the single rooms connected by portals.
-
-Hence we can define some useful criteria for the split: 1) the number of rays should be roughly equal among the new view cells. 2) The split plane should be chosen in a way that the rays are maximal distinct, i.e., the number
-of rays contributing to more than one cell should be minimized => the PVSs are also distinct. 3) For BSP trees,
-the split plane should be aligned with some scene geometry which is large enough to contribute
-a lot of occlusion power. This criterium can be naturally combined with the second one.
-As termination criterium we can choose the minimum PVS / piercing ray size or the maximal tree depth.
+the subdivision terminates in a leaf, a view cell is associated with
+the leaf node.  This simple approach is justified because it places
+the view cell borders  along some discontinuities in the visibility
+function.
+
+\item  The view cell generation can be guided by the sampling
+process. We start with with a single initial view cell representing
+the whole space. If a given threshold is reached during the
+preprocessing (e.g., the view cell is pierced by too many rays
+resulting in a large PVS), the view cell is subdivided into smaller
+cells using some criteria.
+
+In order to evaluate the best split plane, we first have to define the
+characteristics of a good view cell partition:  The view cells should
+be quite large, while their PVS stays rather small.  The PVS of each
+two view cells should be as distinct as possible, otherwise they could
+be merged into a larger view cell if the PVSs are too similar.  E.g.,
+for a building, the perfect view cells are usually the single rooms
+connected by portals.
+
+Hence we can define some useful criteria for the split: 1) the number
+of rays should be roughly equal among the new view cells. 2) The split
+plane should be chosen in a way that the ray sets are disjoint, i.e.,
+the number of rays contributing to more than one cell should be
+minimized. 3) For BSP trees, the split plane should be aligned with
+some scene geometry which is large enough to contribute a lot of
+occlusion power. This criterion can be naturally combined with the
+second one.  As termination criterion we can choose the minimum PVS /
+piercing ray size or the maximal tree depth.
 \end{itemize}
 
-In the future we aim to extend the view cell construction by using
-feedback from the PVS computation: the view cells which contain many
-visibility changes will be subdivided further and neighboring view
-cells with similar PVSs will be merged. We want to gain a more precise
-information about visibility by selectivly storing rays with the
-viewcells and computing visibility statistics for subsets of rays
-which intersect subregions of the given view cell.
-
+
+% In the future we aim to extend the view cell construction by using
+% feedback from the PVS computation: the view cells which contain many
+% visibility changes will be subdivided further and neighboring view
+% cells with similar PVSs will be merged. We want to gain a more precise
+% information about visibility by selectively storing rays with the
+% view cells and computing visibility statistics for subsets of rays
+% which intersect subregions of the given view cell.
 
 \subsection{From-object based visibility}
@@ -386,5 +402,5 @@
 At this phase of the computation we not only start the samples from
 the objects, but we also store the PVS information centered at the
-objects. Instead of storing a PVS consting of objects visible from
+objects. Instead of storing a PVS consisting of objects visible from
 view cells, every object maintains a PVS consisting of potentially
 visible view cells. While these representations contain exactly the
@@ -399,14 +415,17 @@
 of the algorithm visits scene objects sequentially. For every scene
 object we randomly choose a point on its surface. Then a ray is cast
-from the selected point according to the randomly chosen direction. We
-use a uniform distribution of the ray directions with respect to the
-halfspace given by the surface normal. Using this strategy the samples
-at deterministicaly placed at every object, with a randomization of
-the location on the object surface. The uniformly distributed
-direction is a simple and fast strategy to gain initial visibility
-information.
+from the selected point according to the randomly chosen direction
+(see Figure~\ref{fig:sampling}). We use a uniform distribution of the
+ray directions with respect to the half space given by the surface
+normal. Using this strategy the samples at deterministically placed at
+every object, with a randomization of the location on the object
+surface. The uniformly distributed direction is a simple and fast
+strategy to gain initial visibility information.
 
 \begin{figure}%[htb]
-  \includegraphics[width=0.6\textwidth, draft=\DRAFTFIGS]{figs/sampling} \\
+  \centerline{
+    \includegraphics[width=0.4\textwidth, draft=\DRAFTFIGS]{figs/sampling}
+  }
+  
 %\label{tab:online_culling_example}
   \caption{Three objects and a set of view cells corresponding to leaves
@@ -414,5 +433,5 @@
     samples cast from a selected object (shown in red). Note that most
     samples contribute to more view cells.  }
-  \label{fig:online_culling_example}
+  \label{fig:sampling}
 \end{figure}
 
@@ -444,5 +463,5 @@
 local view cell directional density. This means placing more samples at
 directions where more view cells are located: We select a random
-viecell which lies at the halfpace given by the surface normal at the
+view cell which lies at the half space given by the surface normal at the
 chosen point. We pick a random point inside the view cell and cast a
 ray towards this point.
@@ -451,9 +470,9 @@
 \subsection{Accounting for Visibility Events}
 
- Visibility events correspond to appearance and disapearance of
+ Visibility events correspond to appearance and disappearance of
 objects with respect to a moving view point. In polygonal scenes the
 events defined by event surfaces defined by three distinct scene
 edges. Depending on the edge configuration we distinguish between
-vertex-edge events (VE) and tripple edge (EEE) events. The VE surfaces
+vertex-edge events (VE) and triple edge (EEE) events. The VE surfaces
 are planar planes whereas the EEE are in general quadratic surfaces.
 
@@ -467,5 +486,5 @@
 connectivity information we select a random silhouette edge from this
 object and cast a sample which is tangent to that object at the
-selectededge .
+selected edge .
 
 The second strategy works as follows: we randomly pickup two objects
@@ -483,18 +502,18 @@
 \section{Summary}
 
-This chapter described a global visibility sampling tool which forms a
-core of the visibility preprocessing framework. The global visibility
-sampling computes aggresive visibility, i.e. it computes a subset of
-the exact PVS for each view cell. The aggresive sampling provides a
-fast progressive solution and thus it can be easily integrated into
-the game development cycle. The sampling itself involves several
-strategies which aim to pregressively discover more visibility
-relationships in the scene.
+This chapter described the global visibility sampling algorithm which
+forms a core of the visibility preprocessing framework. The global
+visibility sampling computes aggressive visibility, i.e. it computes a
+subset of the exact PVS for each view cell. The aggressive sampling
+provides a fast progressive solution and thus it can be easily
+integrated into the game development cycle. The sampling itself
+involves several strategies which aim to progressively discover more
+visibility relationships in the scene.
 
 The methods presented in this chapter give a good initial estimate
 about visibility in the scene, which can be verified by the mutual
-visibility tool described in the next chapter.
-
-
-
-
+visibility algorithms described in the next chapter.
+
+
+
+
Index: trunk/VUT/doc/SciReport/report.tex
===================================================================
--- trunk/VUT/doc/SciReport/report.tex	(revision 273)
+++ trunk/VUT/doc/SciReport/report.tex	(revision 277)
@@ -8,4 +8,6 @@
 \usepackage{times}
 \usepackage{a4wide}
+\usepackage{pdfpages}
+\usepackage{float}
 
 % For backwards compatibility to old LaTeX type font selection.
@@ -128,9 +130,14 @@
 
 
+\makeindex
 
 %-------------------------------------------------------------------------
 \begin{document}
-
+\setcounter{tocdepth}{1}
+\includepdf[pages=1-2]{cover.pdf}
+\pagenumbering{roman}
 \tableofcontents
+\pagenumbering{arabic}
+
 
 % ---------------------------------------------------------------------
@@ -162,5 +169,5 @@
 
 
-\maketitle
+%\maketitle
 
 \include{introduction}
Index: trunk/VUT/doc/SciReport/everyshi.sty
===================================================================
--- trunk/VUT/doc/SciReport/everyshi.sty	(revision 277)
+++ trunk/VUT/doc/SciReport/everyshi.sty	(revision 277)
@@ -0,0 +1,101 @@
+%%
+%% This is file `everyshi.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% everyshi.dtx  (with options: `package')
+%% 
+%% Copyright (C) [1994..1999] by Martin Schroeder. All rights reserved.
+%% 
+%% This file is part of the EveryShi package
+%% 
+%% This program may be redistributed and/or modified under the terms
+%% of the LaTeX Project Public License, either version 1.0 of this
+%% license, or (at your option) any later version.
+%% The latest version of this license is in
+%%    CTAN:macros/latex/base/lppl.txt.
+%% 
+%% Happy users are requested to send me a postcard. :-)
+%% 
+%% The EveryShi package contains these files:
+%% 
+%%       everyshi.asc
+%%       everyshi.dtx
+%%       everyshi.dvi
+%%       everyshi.ins
+%%       everyshi.bug
+%% 
+%% Error Reports in case of UNCHANGED versions to
+%% 
+%%                         Martin Schr"oder
+%%                         Cr"usemannallee 3
+%%                         D-28213 Bremen
+%%                         Martin.Schroeder@ACM.org
+%% 
+%% File: everyshi.dtx Copyright (C) 1994 Martin Schr\"oder
+\NeedsTeXFormat{LaTeX2e}
+\ProvidesPackage{everyshi}
+         [1999/06/08 v2.03 EveryShipout Package (MS)]
+%% \CharacterTable
+%% {Upper-case    \A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z
+%%  Lower-case    \a\b\c\d\e\f\g\h\i\j\k\l\m\n\o\p\q\r\s\t\u\v\w\x\y\z
+%%  Digits        \0\1\2\3\4\5\6\7\8\9
+%%  Exclamation   \!     Double quote  \"     Hash (number) \#
+%%  Dollar        \$     Percent       \%     Ampersand     \&
+%%  Acute accent  \'     Left paren    \(     Right paren   \)
+%%  Asterisk      \*     Plus          \+     Comma         \,
+%%  Minus         \-     Point         \.     Solidus       \/
+%%  Colon         \:     Semicolon     \;     Less than     \<
+%%  Equals        \=     Greater than  \>     Question mark \?
+%%  Commercial at \@     Left bracket  \[     Backslash     \\
+%%  Right bracket \]     Circumflex    \^     Underscore    \_
+%%  Grave accent  \`     Left brace    \{     Vertical bar  \|
+%%  Right brace   \}     Tilde         \~}
+%%
+%% \iffalse meta-comment
+%% ===================================================================
+%%  @LaTeX-package-file{
+%%     author          = {Martin Schr\"oder},
+%%     version         = "2.03",
+%%     date            = "8 June 1999",
+%%     filename        = "everyshi.sty",
+%%     address         = {Martin Schr\"oder
+%%                        Cr\"usemannallee 3
+%%                        D-28213 Bremen
+%%     telephone       = "+49-421-2239425",
+%%     email           = "Martin.Schroeder@ACM.org",
+%%     pgp-Key         = "2048 bit / KeyID 292814E5",
+%%     pgp-fingerprint = "7E86 6EC8 97FA 2995 82C3  FEA5 2719 090E",
+%%     docstring       = "LaTeX package which defines a new hook
+%%                        \EveryShipout.
+%%  }
+%% ===================================================================
+%% \fi
+
+\let\@EveryShipout@Hook\@empty
+\newcommand{\EveryShipout}{\g@addto@macro\@EveryShipout@Hook}
+\newcommand{\@EveryShipout@Shipout}{%
+   \afterassignment\@EveryShipout@Test
+   \global\setbox\@cclv= %
+   }
+\newcommand{\@EveryShipout@Test}{%
+   \ifvoid\@cclv\relax
+      \aftergroup\@EveryShipout@Output
+   \else
+      \@EveryShipout@Output
+   \fi%
+   }
+\newcommand{\@EveryShipout@Output}{%
+   \@EveryShipout@Hook%
+   \@EveryShipout@Org@Shipout\box\@cclv%
+   }
+\newcommand{\@EveryShipout@Org@Shipout}{}
+\newcommand*{\@EveryShipout@Init}{%
+   \let\@EveryShipout@Org@Shipout\shipout
+   \let\shipout\@EveryShipout@Shipout
+   }
+\AtBeginDocument{\@EveryShipout@Init}
+\endinput
+%%
+%% End of file `everyshi.sty'.
Index: trunk/VUT/doc/SciReport/eso-pic.sty
===================================================================
--- trunk/VUT/doc/SciReport/eso-pic.sty	(revision 277)
+++ trunk/VUT/doc/SciReport/eso-pic.sty	(revision 277)
@@ -0,0 +1,85 @@
+%%
+%% This is file `eso-pic.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% eso-pic.dtx  (with options: `package')
+%% 
+%% Copyright (C) 1998 by Rolf Niepraschk. All rights reserved.
+%% 
+%% This file is part of the eso-pic package
+%% 
+%% Error Reports in case of UNCHANGED versions to niepraschk@ptb.de
+%% 
+%% \CharacterTable
+%%  {Upper-case    \A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z
+%%   Lower-case    \a\b\c\d\e\f\g\h\i\j\k\l\m\n\o\p\q\r\s\t\u\v\w\x\y\z
+%%   Digits        \0\1\2\3\4\5\6\7\8\9
+%%   Exclamation   \!     Double quote  \"     Hash (number) \#
+%%   Dollar        \$     Percent       \%     Ampersand     \&
+%%   Acute accent  \'     Left paren    \(     Right paren   \)
+%%   Asterisk      \*     Plus          \+     Comma         \,
+%%   Minus         \-     Point         \.     Solidus       \/
+%%   Colon         \:     Semicolon     \;     Less than     \<
+%%   Equals        \=     Greater than  \>     Question mark \?
+%%   Commercial at \@     Left bracket  \[     Backslash     \\
+%%   Right bracket \]     Circumflex    \^     Underscore    \_
+%%   Grave accent  \`     Left brace    \{     Vertical bar  \|
+%%   Right brace   \}     Tilde         \~}
+%%
+%% \iffalse meta-comment
+%% ===================================================================
+%%  @LaTeX-package-file{
+%%    author         = {Rolf Niepraschk},
+%%    version        = "0.5",
+%%    date           = "11 July 1998",
+%%    filename       = "eso-pic.sty",
+%%    address        = "",
+%%    telephone      = "",
+%%    email          = "niepraschk@ptb.de",
+%%    codetable      = "ISO/ASCII",
+%%    keywords       = "LaTeX2e, \shipout, picture",
+%%    dependences    = "everyshi",
+%%    supported      = "yes",
+%%    docstring      = "LaTeX package which makes it easy to add some
+%%                      picture commands to every page."
+%%  }
+%% ===================================================================
+%% \fi
+%%
+%%
+%%
+\NeedsTeXFormat{LaTeX2e}[1995/01/25]
+\ProvidesPackage{eso-pic}
+   [1998/07/11 v0.5 eso-pic -- extension to `everyshi' (RN)]
+
+\RequirePackage{everyshi}[1995/01/25]
+
+\newcommand{\@ShipoutPicture@Hook}{}
+\newcommand{\AddToShipoutPicture}{\g@addto@macro\@ShipoutPicture@Hook}
+\newcommand{\ClearShipoutPicture}{\let\@ShipoutPicture@Hook\@empty}
+\newcommand{\@ShipoutPicture}{%
+  \ifx\@ShipoutPicture@Hook\@empty
+  \else
+    \bgroup
+      \@tempdima=1in
+      \@tempcnta=\@tempdima
+      \@tempcntb=-\@tempdima
+      \advance\@tempcntb\paperheight
+      \global\setbox\@cclv\vbox{%
+      \vbox{%
+        \unitlength=1sp%
+        \begin{picture}(0,0)(\@tempcnta,\@tempcntb)%
+          \let\protect\relax\@ShipoutPicture@Hook%
+        \end{picture}}%
+        \box\@cclv%
+      }%
+    \egroup
+  \fi
+}
+
+\EveryShipout{\@ShipoutPicture}
+\endinput
+%%
+%% End of file `eso-pic.sty'.
