[255] | 1 | \chapter{Overview of visibility problems and algorithms}%\chapter
|
---|
| 2 |
|
---|
| 3 | \label{chap:overview}
|
---|
| 4 | \label{chap:classes}
|
---|
| 5 |
|
---|
| 6 | This chapter provides a taxonomy of visibility problems encountered
|
---|
| 7 | in computer graphics based on the {\em problem domain} and the {\em
|
---|
| 8 | type of the answer}. The taxonomy helps to understand the nature of a
|
---|
| 9 | particular visibility problem and provides a tool for grouping
|
---|
| 10 | problems of similar complexity independently of their target
|
---|
| 11 | application. We discuss typical visibility problems encountered in
|
---|
| 12 | computer graphics and identify their relation to the proposed
|
---|
| 13 | taxonomy. A visibility problem can be solved by means of various
|
---|
| 14 | visibility algorithms. We classify visibility algorithms according to
|
---|
| 15 | several important criteria and discuss important concepts in the
|
---|
| 16 | design of a visibility algorithm. The taxonomy and the discussion of
|
---|
| 17 | the algorithm design sums up ideas and concepts that are independent
|
---|
| 18 | of any specific algorithm. This can help algorithm designers to
|
---|
| 19 | transfer the existing algorithms to solve visibility problems in other
|
---|
| 20 | application areas.
|
---|
| 21 |
|
---|
| 22 |
|
---|
| 23 |
|
---|
| 24 | %% summarize the state of the art
|
---|
| 25 | %% visibility algorithms and their relation to the proposed taxonomy of
|
---|
| 26 | %% visibility problems. The second part of the survey should serve as a
|
---|
| 27 | %% catalogue of visibility algorithms that is indexed by the proposed
|
---|
| 28 | %% taxonomy of visibility problems.
|
---|
| 29 |
|
---|
| 30 |
|
---|
| 31 |
|
---|
| 32 | \subsection{Problem domain}
|
---|
| 33 | \label{sec:prob_domain}
|
---|
| 34 |
|
---|
| 35 | Computer graphics deals with visibility problems in the context of
|
---|
| 36 | 2D, \m25d, or 3D scenes. The actual problem domain is given by
|
---|
| 37 | restricting the set of rays for which visibility should be
|
---|
| 38 | determined.
|
---|
| 39 |
|
---|
| 40 | Below we list common problem domains used and the corresponding domain
|
---|
| 41 | restrictions:
|
---|
| 42 |
|
---|
| 43 | \begin{enumerate}
|
---|
| 44 | \item
|
---|
| 45 | {\em visibility along a line}
|
---|
| 46 | \begin{enumerate}
|
---|
| 47 | \item line
|
---|
| 48 | \item ray (origin + direction)
|
---|
| 49 | \end{enumerate}
|
---|
| 50 | \newpage
|
---|
| 51 | \item
|
---|
| 52 | {\em visibility from a point} ({\em from-point visibility})
|
---|
| 53 | \begin{enumerate}
|
---|
| 54 | \item point
|
---|
| 55 | \item point + restricted set of rays
|
---|
| 56 | \begin{enumerate}
|
---|
| 57 | \item point + raster image (discrete form)
|
---|
| 58 | \item point + beam (continuous form)
|
---|
| 59 | \end{enumerate}
|
---|
| 60 | \end{enumerate}
|
---|
| 61 |
|
---|
| 62 |
|
---|
| 63 | \item
|
---|
| 64 | {\em visibility from a line segment} ({\em from-segment visibility})
|
---|
| 65 | \begin{enumerate}
|
---|
| 66 | \item line segment
|
---|
| 67 | \item line segment + restricted set of rays
|
---|
| 68 | \end{enumerate}
|
---|
| 69 |
|
---|
| 70 | \item
|
---|
| 71 | {\em visibility from a polygon} ({\em from-polygon visibility})
|
---|
| 72 | \begin{enumerate}
|
---|
| 73 | \item polygon
|
---|
| 74 | \item polygon + restricted set of rays
|
---|
| 75 | \end{enumerate}
|
---|
| 76 |
|
---|
| 77 | \item
|
---|
| 78 | {\em visibility from a region} ({\em from-region visibility})
|
---|
| 79 | \begin{enumerate}
|
---|
| 80 | \item region
|
---|
| 81 | \item region + restricted set of rays
|
---|
| 82 | \end{enumerate}
|
---|
| 83 |
|
---|
| 84 | \item
|
---|
| 85 | {\em global visibility}
|
---|
| 86 | \begin{enumerate}
|
---|
| 87 | \item no further input (all rays in the scene)
|
---|
| 88 | \item restricted set of rays
|
---|
| 89 | \end{enumerate}
|
---|
| 90 | \end{enumerate}
|
---|
| 91 |
|
---|
| 92 | The domain restrictions can be given independently of the dimension
|
---|
| 93 | of the scene, but the impact of the restrictions differs depending on
|
---|
| 94 | the scene dimension. For example, visibility from a polygon is
|
---|
| 95 | equivalent to visibility from a (polygonal) region in 2D, but not in
|
---|
| 96 | 3D.
|
---|
| 97 |
|
---|
| 98 | %*****************************************************************************
|
---|
| 99 |
|
---|
| 100 | \section{Dimension of the problem-relevant line set}
|
---|
| 101 |
|
---|
| 102 | The six domains of visibility problems stated in
|
---|
| 103 | Section~\ref{sec:prob_domain} can be characterized by the {\em
|
---|
| 104 | problem-relevant line set} denoted ${\cal L}_R$. We give a
|
---|
| 105 | classification of visibility problems according to the dimension of
|
---|
| 106 | the problem-relevant line set. We discuss why this classification is
|
---|
| 107 | important for understanding the nature of the given visibility problem
|
---|
| 108 | and for identifying its relation to other problems.
|
---|
| 109 |
|
---|
| 110 |
|
---|
| 111 | For the following discussion we assume that a line in {\em primal
|
---|
| 112 | space} can be mapped to a point in {\em line space}. For purposes of
|
---|
| 113 | the classification we define the line space as a vector space where a
|
---|
| 114 | point corresponds to a line in the primal space\footnote{A classical
|
---|
| 115 | mathematical definition says: Line space is a direct product of two
|
---|
| 116 | Hilbert spaces~\cite{Weisstein:1999:CCE}. However, this definition
|
---|
| 117 | differs from the common understanding of line space in computer
|
---|
| 118 | graphics~\cite{Durand99-phd}}.
|
---|
| 119 |
|
---|
| 120 |
|
---|
| 121 |
|
---|
| 122 | \subsection{Parametrization of lines in 2D}
|
---|
| 123 |
|
---|
| 124 | There are two independent parameters that specify a 2D line and thus
|
---|
| 125 | the corresponding set of lines is two-dimensional. There is a natural
|
---|
| 126 | duality between lines and points in 2D. For example a line expressed
|
---|
| 127 | as: $l:y=ax+c$ is dual to a point $p=(-c,a)$. This particular duality
|
---|
| 128 | cannot handle vertical lines. See Figure~\ref{fig:duality2d} for an
|
---|
| 129 | example of other dual mappings in the plane. To avoid the singularity
|
---|
| 130 | in the mapping, a line $l:ax+by+c=0$ can be represented as a point
|
---|
| 131 | $p_l=(a,b,c)$ in 2D projective space ${\cal
|
---|
| 132 | P}^2$~\cite{Stolfi:1991:OPG}. Multiplying $p_l$ by a non-zero scalar
|
---|
| 133 | we obtain a vector that represents the same line $l$. More details
|
---|
| 134 | about this singularity-free mapping will be discussed in
|
---|
| 135 | Chapter~\ref{chap:vfr2d}.
|
---|
| 136 |
|
---|
| 137 |
|
---|
| 138 | \begin{figure}[!htb]
|
---|
| 139 | \centerline{
|
---|
| 140 | \includegraphics[width=0.9\textwidth,draft=\DRAFTFIGS]{figs/duality2d}}
|
---|
| 141 | \caption{Duality between points and lines in 2D.}
|
---|
| 142 | \label{fig:duality2d}
|
---|
| 143 | \end{figure}
|
---|
| 144 |
|
---|
| 145 |
|
---|
| 146 |
|
---|
| 147 |
|
---|
| 148 |
|
---|
| 149 | To sum up: In 2D there are two degrees of freedom in description of a
|
---|
| 150 | line and the corresponding line space is two-dimensional. The
|
---|
| 151 | problem-relevant line set ${\cal L}_R$ then forms a $k$-dimensional
|
---|
| 152 | subset of ${\cal P}^2$, where $0\leq k \leq 2$. An illustration of the
|
---|
| 153 | concept of the problem-relevant line set is depicted in
|
---|
| 154 | Figure~\ref{fig:classes}.
|
---|
| 155 |
|
---|
| 156 |
|
---|
| 157 | \begin{figure}[htb]
|
---|
| 158 | \centerline{
|
---|
| 159 | \includegraphics[width=0.8\textwidth,draft=\DRAFTFIGS]{figs/classes}}
|
---|
| 160 | \caption{The problem-relevant set of lines in 2D. The ${\cal L}_R$ for
|
---|
| 161 | visibility along a line is formed by a single point that is a mapping
|
---|
| 162 | of the given line. The ${\cal L}_R$ for visibility from a point $p$ is
|
---|
| 163 | formed by points lying on a line. This line is a dual mapping of the
|
---|
| 164 | point $p$. ${\cal L}_R$ for visibility from a line segment is formed
|
---|
| 165 | by a 2D region bounded by dual mappings of endpoints of the given
|
---|
| 166 | segment.}
|
---|
| 167 | \label{fig:classes}
|
---|
| 168 | \end{figure}
|
---|
| 169 |
|
---|
| 170 |
|
---|
| 171 | \subsection{Parametrization of lines in 3D}
|
---|
| 172 |
|
---|
| 173 |
|
---|
| 174 | Lines in 3D form a four-parametric space~\cite{p-rsls-97}. A line
|
---|
| 175 | intersecting a given scene can be described by two points on a sphere
|
---|
| 176 | enclosing the scene. Since the surface of the sphere is a two
|
---|
| 177 | parametric space, we need four parameters to describe the line.
|
---|
| 178 |
|
---|
| 179 | The {\em two plane parametrization} of 3D lines describes a line by
|
---|
| 180 | points of intersection with the given two
|
---|
| 181 | planes~\cite{Gu:1997:PGT}. This parametrization exhibits a singularity
|
---|
| 182 | since it cannot describe lines parallel to these planes. See
|
---|
| 183 | Figure~\ref{fig:3dlines} for illustrations of the spherical and the
|
---|
| 184 | two plane parameterizations.
|
---|
| 185 |
|
---|
| 186 |
|
---|
| 187 | \begin{figure}[htb]
|
---|
| 188 | \centerline{
|
---|
| 189 | \includegraphics[width=0.78\textwidth,draft=\DRAFTFIGS]{figs/3dlines}}
|
---|
| 190 | \caption{Parametrization of lines in 3D. (left) A line can be
|
---|
| 191 | described by two points on a sphere enclosing the scene. (right) The
|
---|
| 192 | two plane parametrization describes a line by point of intersection
|
---|
| 193 | with two given planes.}
|
---|
| 194 | \label{fig:3dlines}
|
---|
| 195 | \end{figure}
|
---|
| 196 |
|
---|
| 197 | Another common parametrization of 3D lines are the {\em \plucker
|
---|
| 198 | coordinates}. \plucker coordinates of an oriented 3D line are a six
|
---|
| 199 | tuple that can be understood as a point in 5D oriented projective
|
---|
| 200 | space~\cite{Stolfi:1991:OPG}. There are six coordinates in \plucker
|
---|
| 201 | representation of a line although we know that the ${\cal L}_R$ is
|
---|
| 202 | four-dimensional. This can be explained as follows:
|
---|
| 203 |
|
---|
| 204 | \begin{itemize}
|
---|
| 205 | \item Firstly, \plucker coordinates are {\em homogeneous
|
---|
| 206 | coordinates} of a 5D point. By multiplication of the coordinates
|
---|
| 207 | by any positive scalar we get a mapping of the same line.
|
---|
| 208 | \item Secondly, only 4D subset of the 5D oriented projective space
|
---|
| 209 | corresponds to real lines. This subset is a 4D ruled quadric called
|
---|
| 210 | the {\em \plucker quadric} or the {\em Grassman
|
---|
| 211 | manifold}~\cite{Stolfi:1991:OPG,Pu98-DSGIV}.
|
---|
| 212 | \end{itemize}
|
---|
| 213 |
|
---|
| 214 | Although the \plucker coordinates need more coefficients they have no
|
---|
| 215 | singularity and preserve some linearities: lines intersecting a set of
|
---|
| 216 | lines in 3D correspond to an intersection of 5D hyperplanes. More details
|
---|
| 217 | on \plucker coordinates will be discussed in
|
---|
| 218 | Chapters~\ref{chap:vfr25d} and~\ref{chap:vfr3d} where they are used to
|
---|
| 219 | solve the from-region visibility problem.
|
---|
| 220 |
|
---|
| 221 | To sum up: In 3D there are four degrees of freedom in the
|
---|
| 222 | description of a line and thus the corresponding line space is
|
---|
| 223 | four-dimensional. Fixing certain line parameters (e.g. direction) the
|
---|
| 224 | problem-relevant line set, denoted ${\cal L}_R$, forms a
|
---|
| 225 | $k$-dimensional subset of ${\cal P}^4$, where $0\leq k \leq 4$.
|
---|
| 226 |
|
---|
| 227 |
|
---|
| 228 | \subsection{Visibility along a line}
|
---|
| 229 |
|
---|
| 230 | The simplest visibility problems deal with visibility along a single
|
---|
| 231 | line. The problem-relevant line set is zero-dimensional, i.e. it is
|
---|
| 232 | fully specified by the given line. A typical example of a visibility
|
---|
| 233 | along a line problem is {\em ray shooting}.
|
---|
| 234 |
|
---|
| 235 | A similar problem to ray shooting is the {\em point-to-point}
|
---|
| 236 | visibility. The point-to-point visibility determines whether the
|
---|
| 237 | line segment between two points is occluded, i.e. it has an
|
---|
| 238 | intersection with an opaque object in the scene. Point-to-point
|
---|
| 239 | visibility provides a visibility classification (answer 1a), whereas
|
---|
| 240 | ray shooting determines a visible object (answer 2a) and/or a point of
|
---|
| 241 | intersection (answer 3a). Note that the {\em point-to-point}
|
---|
| 242 | visibility can be solved easily by means of ray shooting. Another
|
---|
| 243 | constructive visibility along a line problem is determining the {\em
|
---|
| 244 | maximal free line segments} on a given line. See Figure~\ref{fig:val}
|
---|
| 245 | for an illustration of typical visibility along a line problems.
|
---|
| 246 |
|
---|
| 247 | \begin{figure}[htb]
|
---|
| 248 | \centerline{
|
---|
| 249 | \includegraphics[width=0.85\textwidth,draft=\DRAFTFIGS]{figs/val}}
|
---|
| 250 | \caption{Visibility along a line. (left) Ray shooting. (center) Point-to-point visibility. (right) Maximal free line segments between two points.}
|
---|
| 251 | \label{fig:val}
|
---|
| 252 | \end{figure}
|
---|
| 253 |
|
---|
| 254 |
|
---|
| 255 | \subsection{Visibility from a point}
|
---|
| 256 |
|
---|
| 257 | Lines intersecting a point in 3D can be described by two
|
---|
| 258 | parameters. For example the lines can be expressed by an intersection
|
---|
| 259 | with a unit sphere centered at the given point. The most common
|
---|
| 260 | parametrization describes a line by a point of intersection with a
|
---|
| 261 | given viewport. Note that this parametrization accounts only for a
|
---|
| 262 | subset of lines that intersect the viewport (see Figure~\ref{fig:vfp}).
|
---|
| 263 |
|
---|
| 264 | \begin{figure}[htb]
|
---|
| 265 | \centerline{
|
---|
| 266 | \includegraphics[width=0.6\textwidth,draft=\DRAFTFIGS]{figs/vfp}}
|
---|
| 267 | \caption{Visibility from a point. Lines intersecting a point can be described by a
|
---|
| 268 | point of intersection with the given viewport.}
|
---|
| 269 | \label{fig:vfp}
|
---|
| 270 | \end{figure}
|
---|
| 271 |
|
---|
| 272 | In 3D the problem-relevant line set ${\cal L}_R$ is a 2D subset of
|
---|
| 273 | the 4D line space. In 2D the ${\cal L}_R$ is a 1D subset of the 2D
|
---|
| 274 | line space. The typical visibility from a point problem is the visible
|
---|
| 275 | surface determination. Due to its importance the visible surface
|
---|
| 276 | determination is covered by the majority of existing visibility
|
---|
| 277 | algorithms. Other visibility from a point problem is the construction
|
---|
| 278 | of the {\em visibility map} or the {\em point-to-region visibility}
|
---|
| 279 | that classifies a region as visible, invisible, or partially visible
|
---|
| 280 | with respect to the given point.
|
---|
| 281 |
|
---|
| 282 |
|
---|
| 283 | \subsection{Visibility from a line segment}
|
---|
| 284 |
|
---|
| 285 | Lines intersecting a line segment in 3D can be described by three
|
---|
| 286 | parameters. One parameter fixes the intersection of the line with the
|
---|
| 287 | segment the other two express the direction of the line. The
|
---|
| 288 | problem-relevant line set ${\cal L}_R$ is three-dimensional and it can
|
---|
| 289 | be understood as a 2D cross section of ${\cal L}_R$ swept according
|
---|
| 290 | to the translation on the given line segment (see
|
---|
| 291 | Figure~\ref{fig:vls}).
|
---|
| 292 |
|
---|
| 293 |
|
---|
| 294 | \begin{figure}[htb]
|
---|
| 295 | \centerline{
|
---|
| 296 | \includegraphics[width=0.8\textwidth,draft=\DRAFTFIGS]{figs/vls}}
|
---|
| 297 | \caption{Visibility from a line segment. (left) Line segment, a
|
---|
| 298 | spherical object $O$, and its projections $O^*_0$, $O^*_{0.5}$, $O^*_{1}$
|
---|
| 299 | with respect to the three points on the line segment. (right)
|
---|
| 300 | A possible parametrization of lines that stacks up 2D planes.
|
---|
| 301 | Each plane corresponds to mappings of lines intersecting a given
|
---|
| 302 | point on the line segment.}
|
---|
| 303 | \label{fig:vls}
|
---|
| 304 | \end{figure}
|
---|
| 305 |
|
---|
| 306 | In 2D lines intersecting a line segment form a two-dimensional
|
---|
| 307 | problem-relevant line set. Thus for the 2D case the ${\cal L}_R$ is a
|
---|
| 308 | two-dimensional subset of 2D line space.
|
---|
| 309 |
|
---|
| 310 |
|
---|
| 311 | \subsection{Visibility from a region}
|
---|
| 312 |
|
---|
| 313 | Visibility from a region (or from-region visibility) involves the
|
---|
| 314 | most general visibility problems. In 3D the ${\cal L}_R$ is a 4D
|
---|
| 315 | subset of the 4D line space. In 2D the ${\cal L}_R$ is a 2D subset of
|
---|
| 316 | the 2D line space. Consequently, in the proposed classification
|
---|
| 317 | visibility from a region in 2D is equivalent to visibility from a line
|
---|
| 318 | segment in 2D.
|
---|
| 319 |
|
---|
| 320 | A typical visibility from a region problem is the problem of {\em
|
---|
| 321 | region-to-region} visibility that aims to determine if the two given
|
---|
| 322 | regions in the scene are visible, invisible, or partially visible (see
|
---|
| 323 | Figure~\ref{fig:vfr}). Another visibility from region problem is the
|
---|
| 324 | computation of a {\em potentially visible set} (PVS) with respect to a
|
---|
| 325 | given view cell. The PVS consists of a set of objects that are
|
---|
| 326 | potentially visible from any point inside the view cell. Further
|
---|
| 327 | visibility from a region problems include computing form factors
|
---|
| 328 | between two polygons, soft shadow algorithms or discontinuity meshing.
|
---|
| 329 |
|
---|
| 330 |
|
---|
| 331 | \begin{figure}[htb]
|
---|
| 332 | \centerline{
|
---|
| 333 | \includegraphics[width=0.6\textwidth,draft=\DRAFTFIGS]{figs/vfr}}
|
---|
| 334 | \caption{Visibility from a region --- an example of the region-to-region
|
---|
| 335 | visibility. Two regions and two occluders $A$, $B$
|
---|
| 336 | in a 2D scene. In line space the region-to-region visibility can be
|
---|
| 337 | solved by subtracting the sets of lines $A^*$ and $B^*$
|
---|
| 338 | intersecting objects $A$ and $B$ from the lines intersecting both
|
---|
| 339 | regions.}
|
---|
| 340 | \label{fig:vfr}
|
---|
| 341 | \end{figure}
|
---|
| 342 |
|
---|
| 343 |
|
---|
| 344 | \subsection{Global visibility}
|
---|
| 345 |
|
---|
| 346 | According to the classification the global visibility problems can be
|
---|
| 347 | seen as an extension of the from-region visibility problems. The
|
---|
| 348 | dimension of the problem-relevant line set is the same ($k=2$ for 2D
|
---|
| 349 | and $k=4$ for 3D scenes). Nevertheless, the global visibility problems
|
---|
| 350 | typically deal with much larger set of rays, i.e. all rays that
|
---|
| 351 | penetrate the scene. Additionally, there is no given set of reference
|
---|
| 352 | points from which visibility is studied and hence there is no given
|
---|
| 353 | priority ordering of objects along each particular line from ${\cal
|
---|
| 354 | L}_R$. Therefore an additional parameter must be used to describe
|
---|
| 355 | visibility (visible object) along each ray.
|
---|
| 356 |
|
---|
| 357 |
|
---|
| 358 | \subsection{Summary}
|
---|
| 359 |
|
---|
| 360 | The classification of visibility problems according to the dimension
|
---|
| 361 | of the problem-relevant line set is summarized in
|
---|
| 362 | Table~\ref{table:classification3D}. This classification provides
|
---|
| 363 | means for understanding how difficult it is to compute, describe, and
|
---|
| 364 | maintain visibility for a particular class of problems. For example a
|
---|
| 365 | data structure representing the visible or occluded parts of the scene
|
---|
| 366 | for the visibility from a point problem needs to partition a 2D ${\cal
|
---|
| 367 | L}_R$ into visible and occluded sets of lines. This observation
|
---|
| 368 | conforms with the traditional visible surface algorithms -- they
|
---|
| 369 | partition a 2D viewport into empty/nonempty regions and associate each
|
---|
| 370 | nonempty regions (pixels) with a visible object. In this case the
|
---|
| 371 | viewport represents the ${\cal L}_R$ as each point of the viewport
|
---|
| 372 | corresponds to a line through that point. To analytically describe
|
---|
| 373 | visibility from a region a subdivision of 4D ${\cal L}_R$ should be
|
---|
| 374 | performed. This is much more difficult than the 2D
|
---|
| 375 | subdivision. Moreover the description of visibility from a region
|
---|
| 376 | involves non-linear subdivisions of both primal space and line space
|
---|
| 377 | even for polygonal scenes~\cite{Teller:1992:CAA,Durand99-phd}.
|
---|
| 378 |
|
---|
| 379 | \begin{table*}[htb]
|
---|
| 380 | \begin{small}
|
---|
| 381 | \begin{center}
|
---|
| 382 | \begin{tabular}{|l|c|l|}
|
---|
| 383 | \hline
|
---|
| 384 | \multicolumn{3}{|c|}{2D} \\
|
---|
| 385 | \hline
|
---|
| 386 | \mc{domain} & $d({\cal L}_R)$ & \mc{problems} \\
|
---|
| 387 | \hline
|
---|
| 388 | \hline
|
---|
| 389 | \begin{tabular}{l}visibility along a line\end{tabular} & 0 & \begin{tabular}{l}ray shooting, point-to-point visibility\end{tabular}\\
|
---|
| 390 | \hline
|
---|
| 391 | \begin{tabular}{l}visibility from a point\end{tabular} & 1 & \begin{tabular}{l}view around a point, point-to-region visibility\end{tabular}\\
|
---|
| 392 | \hline
|
---|
| 393 | \begin{tabular}{l} visibility from a line segment \\ visibility from region \\ global visibility \end{tabular}
|
---|
| 394 | & 2 & \begin{tabular}{l} region-to-region visibility, PVS \end{tabular}\\
|
---|
| 395 | \hline
|
---|
| 396 | \hline
|
---|
| 397 | \multicolumn{3}{|c|}{3D} \\
|
---|
| 398 | \hline
|
---|
| 399 | \mc{domain} & $d({\cal L}_R)$ & \mc{problems} \\
|
---|
| 400 | \hline
|
---|
| 401 | \hline
|
---|
| 402 | \begin{tabular}{l}visibility along a line\end{tabular} & 0 & \begin{tabular}{l} ray shooting, point-to-point visibility \end{tabular}\\
|
---|
| 403 | \hline
|
---|
| 404 | \begin{tabular}{l}from point in a surface\end{tabular} & 1 & \begin{tabular}{l} see visibility from point in 2D \end{tabular}\\
|
---|
| 405 | \hline
|
---|
| 406 | \begin{tabular}{l}visibility from a point\end{tabular} & 2 & \begin{tabular}{l} visible (hidden) surfaces, point-to-region visibility,\\
|
---|
| 407 | visibility map, hard shadows
|
---|
| 408 | \end{tabular} \\
|
---|
| 409 | \hline
|
---|
| 410 | \begin{tabular}{l}visibility from a line segment\end{tabular} & 3 & \begin{tabular}{l} segment-to-region visibility (rare) \end{tabular}\\
|
---|
| 411 | \hline
|
---|
| 412 | \begin{tabular}{l}visibility from a region\\global visibility\end{tabular} & 4 & \begin{tabular}{l} region-region visibility, PVS, aspect graph,\\
|
---|
| 413 | soft shadows, discontinuity meshing
|
---|
| 414 | \end{tabular} \\
|
---|
| 415 |
|
---|
| 416 | \hline
|
---|
| 417 | \end{tabular}
|
---|
| 418 | \end{center}
|
---|
| 419 | \end{small}
|
---|
| 420 | \caption{Classification of visibility problems in 2D and 3D according
|
---|
| 421 | to the dimension of the problem-relevant line set.}
|
---|
| 422 | \label{table:classification3D}
|
---|
| 423 | \end{table*}
|
---|
| 424 |
|
---|
| 425 |
|
---|
| 426 |
|
---|
| 427 |
|
---|
| 428 |
|
---|
| 429 | \section{Classification of visibility algorithms}
|
---|
| 430 |
|
---|
| 431 |
|
---|
| 432 | The taxonomy of visibility problems groups similar visibility problems
|
---|
| 433 | in the same class. A visibility problem can be solved by means of
|
---|
| 434 | various visibility algorithms. A visibility algorithm poses further
|
---|
| 435 | restrictions on the input and output data. These restrictions can be
|
---|
| 436 | seen as a more precise definition of the visibility problem that is
|
---|
| 437 | solved by the algorithm.
|
---|
| 438 |
|
---|
| 439 | Above we classified visibility problems according to the problem
|
---|
| 440 | domain and the desired answers. In this section we provide a
|
---|
| 441 | classification of visibility algorithms according to other
|
---|
| 442 | important criteria characterizing a particular visibility algorithm.
|
---|
| 443 |
|
---|
| 444 |
|
---|
| 445 | \subsection{Scene restrictions}
|
---|
| 446 | \label{sec:scene_restrictions}
|
---|
| 447 |
|
---|
| 448 | Visibility algorithms can be classified according to the restrictions
|
---|
| 449 | they pose on the scene description. The type of the scene description
|
---|
| 450 | influences the difficulty of solving the given problem: it is simpler
|
---|
| 451 | to implement an algorithm computing a visibility map for scenes
|
---|
| 452 | consisting of triangles than for scenes with NURBS surfaces. We list
|
---|
| 453 | common restrictions on the scene primitives suitable for visibility
|
---|
| 454 | computations:
|
---|
| 455 |
|
---|
| 456 |
|
---|
| 457 | \begin{itemize}
|
---|
| 458 | \item
|
---|
| 459 | triangles, convex polygons, concave polygons,
|
---|
| 460 |
|
---|
| 461 | \item
|
---|
| 462 | volumetric data,
|
---|
| 463 |
|
---|
| 464 | \item
|
---|
| 465 | points,
|
---|
| 466 |
|
---|
| 467 | \item
|
---|
| 468 | general parametric, implicit, or procedural surfaces.
|
---|
| 469 |
|
---|
| 470 | \end{itemize}
|
---|
| 471 |
|
---|
| 472 | Some attributes of scenes objects further increase the complexity of the visibility computation:
|
---|
| 473 |
|
---|
| 474 | \begin{itemize}
|
---|
| 475 |
|
---|
| 476 | \item
|
---|
| 477 | transparent objects,
|
---|
| 478 |
|
---|
| 479 | \item
|
---|
| 480 | dynamic objects.
|
---|
| 481 |
|
---|
| 482 | \end{itemize}
|
---|
| 483 |
|
---|
| 484 | The majority of analytic visibility algorithms deals with static
|
---|
| 485 | polygonal scenes without transparency. The polygons are often
|
---|
| 486 | subdivided into triangles for easier manipulation and representation.
|
---|
| 487 |
|
---|
| 488 | \subsection{Accuracy}
|
---|
| 489 | \label{sec:accuracy}
|
---|
| 490 |
|
---|
| 491 | Visibility algorithms can be classified according to the accuracy of
|
---|
| 492 | the result as:
|
---|
| 493 |
|
---|
| 494 | \begin{itemize}
|
---|
| 495 | \item exact,
|
---|
| 496 | \item conservative,
|
---|
| 497 | \item aggressive,
|
---|
| 498 | \item approximate.
|
---|
| 499 | \end{itemize}
|
---|
| 500 |
|
---|
| 501 |
|
---|
| 502 | An exact algorithm provides an exact analytic result for the given
|
---|
| 503 | problem (in practice however this result is typically influenced by
|
---|
| 504 | the finite precision of the floating point arithmetics). A
|
---|
| 505 | conservative algorithm overestimates visibility, i.e. it never
|
---|
| 506 | misses any visible object, surface or point. An aggressive algorithm
|
---|
| 507 | always underestimates visibility, i.e. it never reports an invisible
|
---|
| 508 | object, surface or point as visible. An approximate algorithm
|
---|
| 509 | provides only an approximation of the result, i.e. it can overestimate
|
---|
| 510 | visibility for one input and underestimate visibility for another
|
---|
| 511 | input.
|
---|
| 512 |
|
---|
| 513 | The classification according to the accuracy is best illustrated on
|
---|
| 514 | computing PVS: an exact algorithm computes an exact PVS. A
|
---|
| 515 | conservative algorithm computes a superset of the exact PVS. An
|
---|
| 516 | aggressive algorithm determines a subset of the exact PVS. An
|
---|
| 517 | approximate algorithm computes an approximation to the exact PVS that
|
---|
| 518 | is neither its subset or its superset for all possible inputs.
|
---|
| 519 |
|
---|
| 520 |
|
---|
| 521 | \subsection{Solution space}
|
---|
| 522 |
|
---|
| 523 | \label{sec:solspace}
|
---|
| 524 |
|
---|
| 525 | The solution space is the domain in which the algorithm determines
|
---|
| 526 | the desired result. Note that the solution space does not need to
|
---|
| 527 | match the domain of the result.
|
---|
| 528 |
|
---|
| 529 | The algorithms can be classified as:
|
---|
| 530 |
|
---|
| 531 | \begin{itemize}
|
---|
| 532 | \item discrete,
|
---|
| 533 | \item continuous,
|
---|
| 534 | \item hybrid.
|
---|
| 535 | \end{itemize}
|
---|
| 536 |
|
---|
| 537 | A discrete algorithm solves the problem using a discrete solution
|
---|
| 538 | space; the solution is typically an approximation of the result. A
|
---|
| 539 | continuous algorithm works in a continuous domain and often computes an
|
---|
| 540 | analytic solution to the given problem. A hybrid algorithm uses both
|
---|
| 541 | the discrete and the continuous solution space.
|
---|
| 542 |
|
---|
| 543 | The classification according to the solution space is easily
|
---|
| 544 | demonstrated on visible surface algorithms (these algorithms will be
|
---|
| 545 | discussed in Section~\ref{chap:traditional}). The
|
---|
| 546 | z-buffer~\cite{Catmull:1975:CDC} is a common example of a discrete
|
---|
| 547 | algorithm. The Weiler-Atherton algorithm~\cite{Weiler:1977:HSR} is an
|
---|
| 548 | example of a continuous one. A hybrid solution space is used by
|
---|
| 549 | scan-line algorithms that solve the problem in discrete steps
|
---|
| 550 | (scan-lines) and for each step they provide a continuous solution
|
---|
| 551 | (spans).
|
---|
| 552 |
|
---|
| 553 | Further classification reflects the semantics of the solution
|
---|
| 554 | space. According to this criteria we can classify the algorithms as:
|
---|
| 555 |
|
---|
| 556 | \begin{itemize}
|
---|
| 557 | \item primal space (object space),
|
---|
| 558 | \item line space,
|
---|
| 559 | \begin{itemize}
|
---|
| 560 | \item image space,
|
---|
| 561 | \item general,
|
---|
| 562 | \end{itemize}
|
---|
| 563 | \item hybrid.
|
---|
| 564 | \end{itemize}
|
---|
| 565 |
|
---|
| 566 | A primal space algorithm solves the problem by studying the
|
---|
| 567 | visibility between objects without a transformation to a different
|
---|
| 568 | solution space. A line space algorithm studies visibility using a
|
---|
| 569 | transformation of the problem to line space. Image space algorithms
|
---|
| 570 | can be seen as an important subclass of line space algorithms for
|
---|
| 571 | solving visibility from a point problems in 3D. These algorithms cover
|
---|
| 572 | all visible surface algorithms and many visibility culling
|
---|
| 573 | algorithms. They solve visibility in a given image plane that
|
---|
| 574 | represents the problem-relevant line set ${\cal L}_R$ --- each ray
|
---|
| 575 | originating at the viewpoint corresponds to a point in the image plane.
|
---|
| 576 |
|
---|
| 577 | The described classification differs from the sometimes mentioned
|
---|
| 578 | understanding of image space and object space algorithms that
|
---|
| 579 | incorrectly considers all image space algorithms discrete and all
|
---|
| 580 | object space algorithms continuous.
|
---|
| 581 |
|
---|
| 582 |
|
---|
| 583 | %*****************************************************************************
|
---|
| 584 |
|
---|
| 585 | \section{Visibility algorithm design}
|
---|
| 586 |
|
---|
| 587 | Visibility algorithm design can be decoupled into a series of
|
---|
| 588 | important design decisions. The first step is to clearly formulate a
|
---|
| 589 | problem that should be solved by the algorithm. The taxonomy stated
|
---|
| 590 | above can help to understand the difficulty of solving the given
|
---|
| 591 | problem and its relationship to other visibility problems in computer
|
---|
| 592 | graphics. The following sections summarize important steps in the
|
---|
| 593 | design of a visibility algorithm and discuss some commonly used
|
---|
| 594 | techniques.
|
---|
| 595 |
|
---|
| 596 |
|
---|
| 597 | \subsection{Scene structuring}
|
---|
| 598 |
|
---|
| 599 | We discuss two issues dealing with structuring of the scene:
|
---|
| 600 | identifying occluders and occludees, and spatial data structures for
|
---|
| 601 | scene description.
|
---|
| 602 |
|
---|
| 603 | \subsubsection{Occluders and occludees}
|
---|
| 604 | %occluders, occludees,
|
---|
| 605 |
|
---|
| 606 | Many visibility algorithms restructure the scene description to
|
---|
| 607 | distinguish between {\em occluders} and {\em occludees}. Occluders
|
---|
| 608 | are objects that cause changes in visibility (occlusion). Occludees
|
---|
| 609 | are objects that do not cause occlusion, but are sensitive to
|
---|
| 610 | visibility changes. In other words the algorithm studies visibility of
|
---|
| 611 | occludees with respect to occluders.
|
---|
| 612 |
|
---|
| 613 | The concept of occluders and occludees is used to increase the
|
---|
| 614 | performance of the algorithm in both the running time and the accuracy
|
---|
| 615 | of the algorithm by reducing the number of primitives used for
|
---|
| 616 | visibility computations (the performance measures of visibility
|
---|
| 617 | algorithms will be discussed in
|
---|
| 618 | Section~\ref{sec:performance}). Typically, the number of occluders and
|
---|
| 619 | occludees is significantly smaller than the total number of objects in
|
---|
| 620 | the scene. Additionally, both the occluders and the occludees can be
|
---|
| 621 | accompanied with a topological (connectivity) information that might
|
---|
| 622 | be necessary for an efficient functionality of the algorithm.
|
---|
| 623 |
|
---|
| 624 | The concept of occluders is applicable to most visibility
|
---|
| 625 | algorithms. The concept of occludees is useful for algorithms
|
---|
| 626 | providing answers (1) and (2) according to the taxonomy of
|
---|
| 627 | Section~\ref{sec:answers}. Some visibility algorithms do not
|
---|
| 628 | distinguish between occluders and occludees at all. For example all
|
---|
| 629 | traditional visible surface algorithms use all scene objects as both
|
---|
| 630 | occluders and occludees.
|
---|
| 631 |
|
---|
| 632 | Both the occluders and the occludees can be represented by {\em
|
---|
| 633 | virtual objects} constructed from the scene primitives: the occluders
|
---|
| 634 | as simplified inscribed objects, occludees as simplified circumscribed
|
---|
| 635 | objects such as bounding boxes. Algorithms can be classified according
|
---|
| 636 | to the type of occluders they deal with. The classification follows
|
---|
| 637 | the scene restrictions discussed in
|
---|
| 638 | Section~\ref{sec:scene_restrictions} and adds classes specific to
|
---|
| 639 | occluder restrictions:
|
---|
| 640 |
|
---|
| 641 | \begin{itemize}
|
---|
| 642 | \item
|
---|
| 643 | vertical prisms,
|
---|
| 644 | \item
|
---|
| 645 | axis-aligned polygons,
|
---|
| 646 | \item
|
---|
| 647 | axis-aligned rectangles.
|
---|
| 648 | \end{itemize}
|
---|
| 649 |
|
---|
| 650 | The vertical prisms that are specifically important for computing
|
---|
| 651 | visibility in \m25d scenes. Some visibility algorithms can deal only
|
---|
| 652 | with axis-aligned polygons or even more restrictive axis-aligned
|
---|
| 653 | rectangles.
|
---|
| 654 |
|
---|
| 655 |
|
---|
| 656 | \begin{figure}[htb]
|
---|
| 657 | \centerline{
|
---|
| 658 | \includegraphics[width=0.7\textwidth,draft=\DRAFTIMAGES]{images/houses}}
|
---|
| 659 | \caption{Occluders in an urban scene. In urban scenes the occluders
|
---|
| 660 | can be considered vertical prisms erected above the ground.}
|
---|
| 661 | \label{fig:houses}
|
---|
| 662 | \end{figure}
|
---|
| 663 |
|
---|
| 664 | Other important criteria for evaluating algorithms according to
|
---|
| 665 | occluder restrictions include:
|
---|
| 666 |
|
---|
| 667 |
|
---|
| 668 | \begin{itemize}
|
---|
| 669 | \item
|
---|
| 670 | connectivity information,
|
---|
| 671 | \item
|
---|
| 672 | intersecting occluders.
|
---|
| 673 | \end{itemize}
|
---|
| 674 |
|
---|
| 675 |
|
---|
| 676 | The explicit knowledge of the connectivity is crucial for efficient
|
---|
| 677 | performance of some visibility algorithms (performance measures will
|
---|
| 678 | be discussed in the Section~\ref{sec:performance}). Intersecting
|
---|
| 679 | occluders cannot be handled properly by some visibility algorithms.
|
---|
| 680 | In such a case the possible occluder intersections should be resolved
|
---|
| 681 | in preprocessing.
|
---|
| 682 |
|
---|
| 683 | A similar classification can be applied to occludees. However, the
|
---|
| 684 | visibility algorithms typically pose less restrictions on occludees
|
---|
| 685 | since they are not used to describe visibility but only to check
|
---|
| 686 | visibility with respect to the description provided by the occluders.
|
---|
| 687 |
|
---|
| 688 |
|
---|
| 689 | %occluder selection, occluder LOD, virtual occluders,
|
---|
| 690 |
|
---|
| 691 | \subsubsection{Scene description}
|
---|
| 692 |
|
---|
| 693 | The scene is typically represented by a collection of objects. For
|
---|
| 694 | purposes of visibility computations it can be advantageous to transform
|
---|
| 695 | the object centered representation to a spatial representation by
|
---|
| 696 | means of a spatial data structure. For example the scene can be
|
---|
| 697 | represented by an octree where full voxels correspond to opaque parts
|
---|
| 698 | of the scene. Such a data structure is then used as an input to the
|
---|
| 699 | visibility algorithm. The spatial data structures for the scene
|
---|
| 700 | description are used for the following reasons:
|
---|
| 701 |
|
---|
| 702 | \begin{itemize}
|
---|
| 703 |
|
---|
| 704 | \item {\em Regularity}. A spatial data structure typically provides a
|
---|
| 705 | regular description of the scene that avoids complicated
|
---|
| 706 | configurations or overly detailed input. Furthermore, the
|
---|
| 707 | representation can be rather independent of the total scene
|
---|
| 708 | complexity.
|
---|
| 709 |
|
---|
| 710 | \item {\em Efficiency}. The algorithm can be more efficient in both
|
---|
| 711 | the running time and the accuracy of the result.
|
---|
| 712 |
|
---|
| 713 | \end{itemize}
|
---|
| 714 |
|
---|
| 715 |
|
---|
| 716 | Additionally, spatial data structures can be applied to structure the
|
---|
| 717 | solution space and/or to represent the desired solution. Another
|
---|
| 718 | application of spatial data structures is the acceleration of the
|
---|
| 719 | algorithm by providing spatial indexing. These applications of spatial
|
---|
| 720 | data structures will be discussed in
|
---|
| 721 | Sections~\ref{sec:solution_space_ds}
|
---|
| 722 | and~\ref{sec:acceleration_ds}. Note that a visibility algorithm can
|
---|
| 723 | use a single data structure for all three purposes (scene
|
---|
| 724 | structuring, solution space structuring, and spatial indexing) while
|
---|
| 725 | another visibility algorithm can use three conceptually different data
|
---|
| 726 | structures.
|
---|
| 727 |
|
---|
| 728 |
|
---|
| 729 | % gernots alg.
|
---|
| 730 | %used as solution space DS and/or acceleration DS
|
---|
| 731 |
|
---|
| 732 | \subsection{Solution space data structures}
|
---|
| 733 | \label{sec:solution_space_ds}
|
---|
| 734 |
|
---|
| 735 | A solution space data structure is used to maintain an intermediate
|
---|
| 736 | result during the operation of the algorithm and it is used to
|
---|
| 737 | generate the result of the algorithm. We distinguish between the
|
---|
| 738 | following solution space data structures:
|
---|
| 739 |
|
---|
| 740 | \begin{itemize}
|
---|
| 741 |
|
---|
| 742 | \item general data structures
|
---|
| 743 |
|
---|
| 744 | single value (ray shooting), winged edge, active edge table, etc.
|
---|
| 745 |
|
---|
| 746 | \item primal space (spatial) data structures
|
---|
| 747 |
|
---|
| 748 | uniform grid, BSP tree (shadow volumes),
|
---|
| 749 | bounding volume hierarchy, kD-tree, octree, etc.
|
---|
| 750 |
|
---|
| 751 | \item image space data structures
|
---|
| 752 |
|
---|
| 753 | 2D uniform grid (shadow map), 2D BSP tree, quadtree, kD-tree, etc.
|
---|
| 754 |
|
---|
| 755 | \item line space data structures
|
---|
| 756 |
|
---|
| 757 | regular grid, kD-tree, BSP tree, etc.
|
---|
| 758 |
|
---|
| 759 | \end{itemize}
|
---|
| 760 |
|
---|
| 761 | The image space data structures can be considered a special case of
|
---|
| 762 | the line space data structures since a point in the image represents a
|
---|
| 763 | ray through that point (see also Section~\ref{sec:solspace}).
|
---|
| 764 |
|
---|
| 765 | If the dimension of the solution space matches the dimension of the
|
---|
| 766 | problem-relevant line set, the visibility problem can often be solved
|
---|
| 767 | with high accuracy by a single sweep through the scene. If the
|
---|
| 768 | dimensions do not match, the algorithm typically needs more passes to
|
---|
| 769 | compute a result with satisfying accuracy~\cite{EVL-2000-60,wonka00}
|
---|
| 770 | or neglects some visibility effects altogether~\cite{EVL-2000-59}.
|
---|
| 771 |
|
---|
| 772 |
|
---|
| 773 | %ray shooting none
|
---|
| 774 | %visible surface algorithms - list of scan-line intersections, BSP tree,
|
---|
| 775 | % z-buffer (graphics hardware)
|
---|
| 776 | %shadow computation shadow volumes, BSP tree, shadow map (graphics hardware)
|
---|
| 777 | %PVS for view cell - occlusion tree
|
---|
| 778 |
|
---|
| 779 |
|
---|
| 780 | \subsection{Performance}
|
---|
| 781 | \label{sec:performance}
|
---|
| 782 |
|
---|
| 783 | %output sensitivity, memory consumption, running time, scalability
|
---|
| 784 |
|
---|
| 785 |
|
---|
| 786 | The performance of a visibility algorithm can be evaluated by measuring
|
---|
| 787 | the quality of the result, the running time and the memory consumption.
|
---|
| 788 | In this section we discuss several concepts related to these
|
---|
| 789 | performance criteria.
|
---|
| 790 |
|
---|
| 791 |
|
---|
| 792 | \subsubsection{Quality of the result}
|
---|
| 793 |
|
---|
| 794 | One of the important performance measures of a visibility algorithm
|
---|
| 795 | is the quality of the result. The quality measure depends on the type
|
---|
| 796 | of the answer to the problem. Generally, the quality of the result
|
---|
| 797 | can be expressed as a distance from an exact result in the solution
|
---|
| 798 | space. Such a quality measure can be seen as a more precise
|
---|
| 799 | expression of the accuracy of the algorithm discussed in
|
---|
| 800 | Section~\ref{sec:accuracy}.
|
---|
| 801 |
|
---|
| 802 | For example a quality measure of algorithms computing a PVS can be
|
---|
| 803 | expressed by the {\em relative overestimation} and the {\em relative
|
---|
| 804 | underestimation} of the PVS with respect to the exact PVS. We can
|
---|
| 805 | define a quality measure of an algorithm $A$ on input $I$ as a tuple
|
---|
| 806 | $\mbi{Q}^A(I)$:
|
---|
| 807 |
|
---|
| 808 | \begin{eqnarray}
|
---|
| 809 | \mbi{Q}^A(I) & = & (Q^A_o(I), Q^A_u(I)), \qquad I \in {\cal D} \\
|
---|
| 810 | Q^A_o(I) & = & {|S^A(I) \setminus S^{\cal E}(I)| \over |S^{\cal E}(I)|} \\
|
---|
| 811 | Q^A_u(I) & = & {|S^{\cal E}(I) \setminus S^A(I) | \over |S^{\cal E}(I)|}
|
---|
| 812 | \end{eqnarray}
|
---|
| 813 |
|
---|
| 814 | where $I$ is an input from the input domain ${\cal D}$, $S^A(I)$ is
|
---|
| 815 | the PVS determined by the algorithm $A$ for input $I$ and $S^{\cal
|
---|
| 816 | E}(I)$ is the exact PVS for the given input. $Q^A_o(I)$ expresses the
|
---|
| 817 | {\em relative overestimation} of the PVS, $Q^A_u(I)$ is the {\em
|
---|
| 818 | relative underestimation}.
|
---|
| 819 |
|
---|
| 820 | The expected quality of the algorithm over all possible inputs can be
|
---|
| 821 | given as:
|
---|
| 822 |
|
---|
| 823 | \begin{eqnarray}
|
---|
| 824 | Q^A & = & E[\| \mbi{Q}^A(I) \|] \\
|
---|
| 825 | & = & \sum_{\forall I \in {\cal D}} f(I).\sqrt{Q^A_o(I)^2 + Q^A_o(I)^2}
|
---|
| 826 | \end{eqnarray}
|
---|
| 827 |
|
---|
| 828 | where f(I) is the probability density function expressing the
|
---|
| 829 | probability of occurrence of input $I$. The quality measure
|
---|
| 830 | $\mbi{Q}^A(I)$ can be used to classify a PVS algorithm into one of the
|
---|
| 831 | four accuracy classes according to Section~\ref{sec:accuracy}:
|
---|
| 832 |
|
---|
| 833 | \begin{enumerate}
|
---|
| 834 | \item exact\\
|
---|
| 835 | $\forall I \in {\cal D} :Q_o^A(I) = 0 \wedge Q_u^A(I) = 0$
|
---|
| 836 | \item conservative\\
|
---|
| 837 | $\forall I \in {\cal D} : Q_o^A(I) \geq 0 \wedge Q_u^A(I) = 0$
|
---|
| 838 | \item aggressive \\
|
---|
| 839 | $\forall I \in {\cal D} : Q_o^A(I) = 0 \wedge Q_u^A(I) \geq 0$
|
---|
| 840 | \item approximate \\
|
---|
| 841 | $\qquad \exists I_j, I_k \in {\cal D}: Q_o^A(I_j) > 0 \wedge Q_u^A(I_k) > 0$
|
---|
| 842 | \end{enumerate}
|
---|
| 843 |
|
---|
| 844 |
|
---|
| 845 |
|
---|
| 846 | \subsubsection{Scalability}
|
---|
| 847 |
|
---|
| 848 | Scalability expresses the ability of the visibility algorithm to cope
|
---|
| 849 | with larger inputs. A more precise definition of scalability of an
|
---|
| 850 | algorithm depends on the problem for which the algorithm is
|
---|
| 851 | designed. The scalability of an algorithm can be studied with respect
|
---|
| 852 | to the size of the scene (e.g. number of scene objects). Another
|
---|
| 853 | measure might consider the dependence of the algorithm on the number
|
---|
| 854 | of only the visible objects. Scalability can also be studied
|
---|
| 855 | according to the given domain restrictions, e.g. volume of the view
|
---|
| 856 | cell.
|
---|
| 857 |
|
---|
| 858 | A well designed visibility algorithm should be scalable with respect
|
---|
| 859 | to the number of structural changes or discontinuities of
|
---|
| 860 | visibility. Furthermore, its performance should be given by the
|
---|
| 861 | complexity of the visible part of the scene. These two important
|
---|
| 862 | measures of scalability of an algorithm are discussed in the next two
|
---|
| 863 | sections.
|
---|
| 864 |
|
---|
| 865 | \subsubsection{Use of coherence}
|
---|
| 866 |
|
---|
| 867 | Scenes in computer graphics typically consist of objects whose
|
---|
| 868 | properties vary smoothly from one part to another. A view of such a
|
---|
| 869 | scene contains regions of smooth changes (changes in color, depth,
|
---|
| 870 | texture,etc.) and discontinuities that let us distinguish between
|
---|
| 871 | objects. The degree to which the scene or its projection exhibit local
|
---|
| 872 | similarities is called {\em coherence}~\cite{Foley90}.
|
---|
| 873 |
|
---|
| 874 | Coherence can be exploited by reusing calculations made for one part
|
---|
| 875 | of the scene for nearby parts. Algorithms exploiting coherence are
|
---|
| 876 | typically more efficient than algorithms computing the result from the
|
---|
| 877 | scratch.
|
---|
| 878 |
|
---|
| 879 | Sutherland et al.~\cite{Sutherland:1974:CTH} identified several
|
---|
| 880 | different types of coherence in the context of visible surface
|
---|
| 881 | algorithms. We simplify the classification proposed by Sutherland et
|
---|
| 882 | al. to reflect general visibility problems and distinguish between the
|
---|
| 883 | following three types of {\em visibility coherence}:
|
---|
| 884 |
|
---|
| 885 | \begin{itemize}
|
---|
| 886 |
|
---|
| 887 | \item {\em Spatial coherence}. Visibility of points in space tends to
|
---|
| 888 | be coherent in the sense that the visible part of the scene consists
|
---|
| 889 | of compact sets (regions) of visible and invisible points. We can
|
---|
| 890 | reuse calculations made for a given region for the neighboring
|
---|
| 891 | regions or its subregions.
|
---|
| 892 |
|
---|
| 893 | \item {\em Line-space coherence}. Sets of similar rays tend to have the
|
---|
| 894 | same visibility classification, i.e. the rays intersect the same
|
---|
| 895 | object. We can reuse calculations for the given set of rays for its
|
---|
| 896 | subsets or the sets of nearby rays.
|
---|
| 897 |
|
---|
| 898 | \item {\em Temporal coherence}. Visibility at two successive moments is
|
---|
| 899 | likely to be similar despite small changes in the scene or a
|
---|
| 900 | region/point of interest. Calculations made for one frame can be
|
---|
| 901 | reused for the next frame in a sequence.
|
---|
| 902 |
|
---|
| 903 | \end{itemize}
|
---|
| 904 |
|
---|
| 905 | The degree to which the algorithm exploits various types of coherence
|
---|
| 906 | is one of the major design paradigms in research of new visibility
|
---|
| 907 | algorithms. The importance of exploiting coherence is emphasized by
|
---|
| 908 | the large amount of data that need to be processed by the current
|
---|
| 909 | rendering algorithms.
|
---|
| 910 |
|
---|
| 911 |
|
---|
| 912 | \subsubsection{Output sensitivity}
|
---|
| 913 |
|
---|
| 914 |
|
---|
| 915 | An algorithm is said to be {\em output-sensitive} if its running time
|
---|
| 916 | is sensitive to the size of output. In the computer graphics community
|
---|
| 917 | the term output-sensitive algorithm is used in a broader meaning than
|
---|
| 918 | in computational geometry~\cite{berg:97}. The attention is paid to a
|
---|
| 919 | practical usage of the algorithm, i.e. to an efficient implementation
|
---|
| 920 | in terms of the practical average case performance. The algorithms are
|
---|
| 921 | usually evaluated experimentally using test data and measuring the
|
---|
| 922 | running time and the size of output of the algorithm. The formal
|
---|
| 923 | average case analysis is usually not carried out for the following two
|
---|
| 924 | reasons:
|
---|
| 925 |
|
---|
| 926 | \begin{enumerate}
|
---|
| 927 |
|
---|
| 928 | \item {\em The algorithm is too obscured}. Visibility algorithms
|
---|
| 929 | exploit data structures that are built according to various heuristics
|
---|
| 930 | and it is difficult to derive proper bounds even on the expected size
|
---|
| 931 | of these supporting data structures.
|
---|
| 932 |
|
---|
| 933 | \item {\em It is difficult to properly model the input data}. In
|
---|
| 934 | general it is difficult to create a reasonable model that captures
|
---|
| 935 | properties of real world scenes as well as the probability of
|
---|
| 936 | occurrence of a particular configuration.
|
---|
| 937 |
|
---|
| 938 | \end{enumerate}
|
---|
| 939 |
|
---|
| 940 | A visibility algorithm can often be divided into the {\em offline}
|
---|
| 941 | phase and the {\em online} phase. The offline phase is also called
|
---|
| 942 | preprocessing. The preprocessing is often amortized over many
|
---|
| 943 | executions of the algorithm and therefore it is advantageous to
|
---|
| 944 | express it separately from the online running time.
|
---|
| 945 |
|
---|
| 946 | For example an ideal output-sensitive visible surface algorithm runs
|
---|
| 947 | in $O(n\log n + k^2)$, where $n$ is the number of scene polygons (size
|
---|
| 948 | of input) and $k$ is the number of visible polygons (in the worst case
|
---|
| 949 | $k$ visible polygons induce $O(k^2)$ visible polygon fragments).
|
---|
| 950 |
|
---|
| 951 |
|
---|
| 952 |
|
---|
| 953 | \subsubsection{Acceleration data structures}
|
---|
| 954 | \label{sec:acceleration_ds}
|
---|
| 955 |
|
---|
| 956 | Acceleration data structures are often used to achieve the performance
|
---|
| 957 | goals of a visibility algorithm. These data structures allow efficient
|
---|
| 958 | point location, proximity queries, or scene traversal required by many
|
---|
| 959 | visibility algorithms.
|
---|
| 960 |
|
---|
| 961 | With a few exceptions the acceleration data structures provide a {\em
|
---|
| 962 | spatial index} for the scene by means of a spatial data structure.
|
---|
| 963 | The spatial data structures group scene objects according to the
|
---|
| 964 | spatial proximity. On the contrary line space data structures group
|
---|
| 965 | rays according to their proximity in line space.
|
---|
| 966 |
|
---|
| 967 | The common acceleration data structures can be divided into the
|
---|
| 968 | following categories:
|
---|
| 969 |
|
---|
| 970 | \begin{itemize}
|
---|
| 971 | \item Spatial data structures
|
---|
| 972 | \begin{itemize}
|
---|
| 973 | \item {\em Spatial subdivisions}
|
---|
| 974 |
|
---|
| 975 | uniform grid, hierarchical grid, kD-tree, BSP tree, octree, quadtree, etc.
|
---|
| 976 |
|
---|
| 977 | \item {\em Bounding volume hierarchies}
|
---|
| 978 |
|
---|
| 979 | hierarchy of bounding spheres,
|
---|
| 980 | hierarchy of bounding boxes, etc.
|
---|
| 981 |
|
---|
| 982 | \item {\em Hybrid}
|
---|
| 983 |
|
---|
| 984 | hierarchy of uniform grids, hierarchy of kD-trees, etc.
|
---|
| 985 |
|
---|
| 986 | \end{itemize}
|
---|
| 987 |
|
---|
| 988 | \item Line space data structures
|
---|
| 989 | \begin{itemize}
|
---|
| 990 | \item {\em General}
|
---|
| 991 |
|
---|
| 992 | regular grid, kD-tree, BSP tree, etc.
|
---|
| 993 | \end{itemize}
|
---|
| 994 |
|
---|
| 995 | \end{itemize}
|
---|
| 996 |
|
---|
| 997 |
|
---|
| 998 |
|
---|
| 999 | \subsubsection{Use of graphics hardware}
|
---|
| 1000 |
|
---|
| 1001 | Visibility algorithms can be accelerated by exploiting dedicated
|
---|
| 1002 | graphics hardware. The hardware implementation of the z-buffer
|
---|
| 1003 | algorithm that is common even on a low-end graphics hardware can be
|
---|
| 1004 | used to accelerate solutions to other visibility problems. Recall that the
|
---|
| 1005 | z-buffer algorithm solves the visibility from a point problem by
|
---|
| 1006 | providing a discrete approximation of the visible surfaces.
|
---|
| 1007 | %$(3-D-2b(i), A-3b)$
|
---|
| 1008 |
|
---|
| 1009 | A visibility algorithm can be accelerated by the graphics hardware if
|
---|
| 1010 | it can be decomposed so that the decomposition includes the
|
---|
| 1011 | problem solved by the z-buffer or a series of such problems.
|
---|
| 1012 | %$(3-D-2b(i), A-3b)$
|
---|
| 1013 | Prospectively, the recent features of the graphics hardware, such as
|
---|
| 1014 | the pixel and vertex shaders allow easier application of the graphics
|
---|
| 1015 | hardware for solving specific visibility tasks. The software interface
|
---|
| 1016 | between the graphics hardware and the CPU is usually provided by
|
---|
| 1017 | OpenGL~\cite{Moller02-RTR}.
|
---|
| 1018 |
|
---|
| 1019 |
|
---|
| 1020 | \section{Visibility in urban environments}
|
---|
| 1021 |
|
---|
| 1022 | Urban environments constitute an important class of real world scenes
|
---|
| 1023 | computer graphics deals with. We can identify two fundamental
|
---|
| 1024 | subclasses of urban scenes. Firstly, we consider {\em outdoor} scenes,
|
---|
| 1025 | i.e. urban scenes as observed from streets, parks, rivers, or a
|
---|
| 1026 | bird's-eye view. Secondly, we consider {\em indoor} scenes, i.e. urban
|
---|
| 1027 | scenes representing building interiors. In the following two sections
|
---|
| 1028 | we discuss the essential characteristics of visibility in both the
|
---|
| 1029 | outdoor and the indoor scenes. The discussion is followed by
|
---|
| 1030 | summarizing the suitable visibility techniques.
|
---|
| 1031 |
|
---|
| 1032 |
|
---|
| 1033 | \subsection{Analysis of visibility in outdoor urban areas}
|
---|
| 1034 |
|
---|
| 1035 | \label{sec:analysis_ue}
|
---|
| 1036 | \label{sec:ANALYSIS_UE}
|
---|
| 1037 |
|
---|
| 1038 |
|
---|
| 1039 | Outdoor urban scenes are viewed using two different scenarios. In a
|
---|
| 1040 | {\em flyover} scenario the scene is observed from the bird's eye
|
---|
| 1041 | view. A large part of the scene is visible. Visibility is mainly
|
---|
| 1042 | restricted due to the structure of the terrain, atmospheric
|
---|
| 1043 | constraints (fog, clouds) and the finite resolution of human
|
---|
| 1044 | retina. Rendering of the flyover scenarios is usually accelerated
|
---|
| 1045 | using LOD, image-based rendering and terrain visibility algorithms,
|
---|
| 1046 | but there is no significant potential for visibility culling.
|
---|
| 1047 |
|
---|
| 1048 | In a {\em walkthrough} scenario the scene is observed from a
|
---|
| 1049 | pedestrians point of view and the visibility is often very
|
---|
| 1050 | restricted. In the remainder of this section we discuss the walkthrough
|
---|
| 1051 | scenario in more detail.
|
---|
| 1052 |
|
---|
| 1053 | Due to technological and physical restrictions urban scenes viewed
|
---|
| 1054 | from outdoor closely resemble a 2D {\em height function}, i.e. a
|
---|
| 1055 | function expressing the height of the scene elements above the ground.
|
---|
| 1056 | The height function cannot capture certain objects such as bridges,
|
---|
| 1057 | passages, subways, or detailed objects such as trees. Nevertheless
|
---|
| 1058 | buildings, usually the most important part of the scene, can be
|
---|
| 1059 | captured accurately by the height function in most cases. For the
|
---|
| 1060 | sake of visibility computations the objects that cannot be represented
|
---|
| 1061 | by the height function can be ignored. The resulting scene is then
|
---|
| 1062 | called a {\em \m25d scene}.
|
---|
| 1063 |
|
---|
| 1064 | In a dense urban area with high buildings visibility is very
|
---|
| 1065 | restricted when the scene is viewed from a street (see
|
---|
| 1066 | Figure~\ref{fig:outdoor}-a). Only buildings from nearby streets are
|
---|
| 1067 | visible. Often there are no buildings visible above roofs of buildings
|
---|
| 1068 | close to the viewpoint. In such a case visibility is essentially
|
---|
| 1069 | two-dimensional, i.e. it could be solved accurately using a 2D
|
---|
| 1070 | footprint of the scene and a 2D visibility algorithm. In areas with
|
---|
| 1071 | smaller houses of different shapes visibility is not so severely
|
---|
| 1072 | restricted since some objects can be visible by looking over other
|
---|
| 1073 | objects. The view complexity increases (measured in number of visible
|
---|
| 1074 | objects) and the height structure becomes increasingly
|
---|
| 1075 | important. Complex views with far visibility can be seen also near
|
---|
| 1076 | rivers, squares, and parks (see Figure~\ref{fig:outdoor}-b).
|
---|
| 1077 |
|
---|
| 1078 | \begin{figure}[htb]
|
---|
| 1079 | \centerline{
|
---|
| 1080 | \hfill
|
---|
| 1081 | \includegraphics[width=0.45\textwidth,draft=\DRAFTIMAGES]{images/foto_street1}
|
---|
| 1082 | \hfill
|
---|
| 1083 | \includegraphics[width=0.45\textwidth,draft=\DRAFTIMAGES]{images/foto_castle1}
|
---|
| 1084 | \hfill
|
---|
| 1085 | }
|
---|
| 1086 | \caption{Visibility in outdoor urban areas. (left) In the center of a city
|
---|
| 1087 | visibility is typically restricted to a few nearby streets. (right)
|
---|
| 1088 | Near river banks typically a large part of the city is visible. Note
|
---|
| 1089 | that many distant objects are visible due to the terrain gradation.}
|
---|
| 1090 | \label{fig:outdoor}
|
---|
| 1091 | \end{figure}
|
---|
| 1092 |
|
---|
| 1093 | In scenes with large differences in terrain height the view complexity
|
---|
| 1094 | is often very high. Many objects can be visible that are situated for
|
---|
| 1095 | example on a hill or on a slope behind a river. Especially in areas
|
---|
| 1096 | with smaller housing visibility is much defined by the terrain itself.
|
---|
| 1097 |
|
---|
| 1098 | We can summarize the observations as follows (based on
|
---|
| 1099 | Wonka~\cite{wonka_phd}) :
|
---|
| 1100 |
|
---|
| 1101 | \begin{itemize}
|
---|
| 1102 |
|
---|
| 1103 | \item
|
---|
| 1104 | Outdoor urban environments have basically \m25d structure and
|
---|
| 1105 | consequently visibility is restricted accordingly.
|
---|
| 1106 |
|
---|
| 1107 | \item
|
---|
| 1108 | The view is very restricted in certain areas, such as in the
|
---|
| 1109 | city center. However the complexity of the view can vary
|
---|
| 1110 | significantly. It is always not the case that only few objects are
|
---|
| 1111 | visible.
|
---|
| 1112 |
|
---|
| 1113 | \item
|
---|
| 1114 | If there are large height differences in the terrain, many
|
---|
| 1115 | objects are visible for most viewpoints.
|
---|
| 1116 |
|
---|
| 1117 | \item
|
---|
| 1118 | In the same view a close object can be visible next to a very
|
---|
| 1119 | distant one.
|
---|
| 1120 |
|
---|
| 1121 | \end{itemize}
|
---|
| 1122 |
|
---|
| 1123 |
|
---|
| 1124 | In the simplest case the outdoor scene consists only of the terrain
|
---|
| 1125 | populated by a few buildings. Then the visibility can be calculated on
|
---|
| 1126 | the terrain itself with satisfying
|
---|
| 1127 | accuracy~\cite{Floriani:1995:HCH,Cohen-Or:1995:VDZ, Stewart:1997:HVT}.
|
---|
| 1128 | Outdoor urban environments have a similar structure as terrains:
|
---|
| 1129 | buildings can be treated as a terrain with {\em many discontinuities}
|
---|
| 1130 | in the height function (assuming that the buildings do not contain
|
---|
| 1131 | holes or significant variations in their fa{\c{c}}ades). To
|
---|
| 1132 | accurately capture visibility in such an environment specialized
|
---|
| 1133 | algorithms have been developed that compute visibility from a given
|
---|
| 1134 | viewpoint~\cite{downs:2001:I3DG} or view
|
---|
| 1135 | cell~\cite{wonka00,koltun01,bittner:2001:PG}.
|
---|
| 1136 |
|
---|
| 1137 | % The methods presented later in the thesis make use of the specific
|
---|
| 1138 | % structure of the outdoor scenes to efficiently compute a PVS for the
|
---|
| 1139 | % given view cell. The key observation is that the PVS for a view cell
|
---|
| 1140 | % in a \m25d can be determined by computing visibility from its top
|
---|
| 1141 | % boundary edges. This problem becomes a restricted variant of the
|
---|
| 1142 | % visibility from a line segment in 3D with $d({\cal L}_R) = 3$.
|
---|
| 1143 |
|
---|
| 1144 |
|
---|
| 1145 | \subsection{Analysis of indoor visibility}
|
---|
| 1146 |
|
---|
| 1147 | Building interiors constitute another important class of real world
|
---|
| 1148 | scenes. A typical building consists of rooms, halls, corridors, and
|
---|
| 1149 | stairways. It is possible to see from one room to another through an
|
---|
| 1150 | open door or window. Similarly it is possible to see from one corridor
|
---|
| 1151 | to another one through a door or other connecting structure. In
|
---|
| 1152 | general the scene can be subdivided into cells corresponding to the
|
---|
| 1153 | rooms, halls, corridors, etc., and transparent portals that connect
|
---|
| 1154 | the cells~\cite{Airey90,Teller:1991:VPI}. Some portals
|
---|
| 1155 | correspond to the real doors and windows, others provide only a
|
---|
| 1156 | virtual connection between cells. For example an L-shaped corridor
|
---|
| 1157 | can be represented by two cells and one virtual portal connecting them.
|
---|
| 1158 |
|
---|
| 1159 | Visibility in a building interior is often significantly restricted
|
---|
| 1160 | (see Figure~\ref{fig:indoor}). We can see the room we are located at
|
---|
| 1161 | and possibly few other rooms visible through open doors. Due to the
|
---|
| 1162 | natural partition of the scene into cells and portals visibility can
|
---|
| 1163 | be solved by determining which cells can be seen through a give set of
|
---|
| 1164 | portals and their sequences. A sequence of portals that we can see
|
---|
| 1165 | through is called {\em feasible}.
|
---|
| 1166 |
|
---|
| 1167 | \begin{figure}[htb]
|
---|
| 1168 | \centerline{
|
---|
| 1169 | \hfill
|
---|
| 1170 | \includegraphics[width=0.45\textwidth,draft=\DRAFTIMAGES]{images/foto_chodba1}
|
---|
| 1171 | \hfill
|
---|
| 1172 | \includegraphics[width=0.45\textwidth,draft=\DRAFTIMAGES]{images/foto_sloupy2}
|
---|
| 1173 | \hfill
|
---|
| 1174 | }
|
---|
| 1175 | \caption{Indoor visibility. (left) Visibility in indoor scenes is typically
|
---|
| 1176 | restricted to a few rooms or corridors. (right) In scenes with more complex
|
---|
| 1177 | interior structure visibility gets more complicated.
|
---|
| 1178 | }
|
---|
| 1179 | \label{fig:indoor}
|
---|
| 1180 | \end{figure}
|
---|
| 1181 |
|
---|
| 1182 |
|
---|
| 1183 | Many algorithms for computing indoor visibility~\cite{Airey90,
|
---|
| 1184 | Teller92phd, Luebke:1995:PMS} exploit the cell/portal structure of the
|
---|
| 1185 | scene. The potential problem of this approach is its strong
|
---|
| 1186 | sensitivity to the arrangement of the environment. In a scene with a
|
---|
| 1187 | complicated structure with many portals there are many feasible portal
|
---|
| 1188 | sequences. Imagine a hall with columns arranged on a grid. The number
|
---|
| 1189 | of feasible portal sequences rapidly increases with the distance from
|
---|
| 1190 | the given view cell~\cite{Teller92phd} if the columns are sufficiently
|
---|
| 1191 | small (see Figure~\ref{fig:portal_explosion}). Paradoxically most of
|
---|
| 1192 | the scene is visible and there is almost no benefit of using any
|
---|
| 1193 | visibility culling algorithm.
|
---|
| 1194 |
|
---|
| 1195 | The methods presented later in the report partially avoids this
|
---|
| 1196 | problem since it does not rely on finding feasible portal sequences
|
---|
| 1197 | even in the indoor scenes. Instead of determining what {\em can} be
|
---|
| 1198 | visible through a transparent complement of the scene (portals) the
|
---|
| 1199 | method determines what {\em cannot} be visible due to the scene
|
---|
| 1200 | objects themselves (occluders). This approach also avoids the explicit
|
---|
| 1201 | enumeration of portals and the construction of the cell/portal graph.
|
---|
| 1202 |
|
---|
| 1203 |
|
---|
| 1204 |
|
---|
| 1205 | \begin{figure}[htb]
|
---|
| 1206 | \centerline{
|
---|
| 1207 | \includegraphics[width=0.45\textwidth,draft=\DRAFTFIGS]{figs/portals_explosion}}
|
---|
| 1208 | \caption{In sparsely occluded scenes the cell/portal algorithm can
|
---|
| 1209 | exhibit a combinatorial explosion in number of feasible portal
|
---|
| 1210 | sequences. Paradoxically visibility culling provides almost no
|
---|
| 1211 | benefit in such scenes.}
|
---|
| 1212 | \label{fig:portal_explosion}
|
---|
| 1213 | \end{figure}
|
---|
| 1214 |
|
---|
| 1215 |
|
---|
| 1216 |
|
---|
| 1217 | \section{Summary}
|
---|
| 1218 |
|
---|
| 1219 | Visibility problems and algorithms penetrate a large part of computer
|
---|
| 1220 | graphics research. The proposed taxonomy aims to classify visibility
|
---|
| 1221 | problems independently of their target application. The
|
---|
| 1222 | classification should help to understand the nature of the given
|
---|
| 1223 | problem and it should assist in finding relationships between
|
---|
| 1224 | visibility problems and algorithms in different application areas.
|
---|
| 1225 | The tools address the following classes of visibility problems:
|
---|
| 1226 |
|
---|
| 1227 | \begin{itemize}
|
---|
| 1228 | \item Visibility from a point in 3D $d({\cal L}_R)=2$.
|
---|
| 1229 | \item Global visibility in 3D $d({\cal L}_R)=4$.
|
---|
| 1230 | \item Visibility from a region in 3D, $d({\cal L}_R)=4$.
|
---|
| 1231 | \end{itemize}
|
---|
| 1232 |
|
---|
| 1233 | This chapter discussed several important criteria for the
|
---|
| 1234 | classification of visibility algorithms. This classification can be
|
---|
| 1235 | seen as a finer structuring of the taxonomy of visibility problems. We
|
---|
| 1236 | discussed important steps in the design of a visibility algorithm that
|
---|
| 1237 | should also assist in understanding the quality of a visibility
|
---|
| 1238 | algorithm. According to the classification the tools address
|
---|
| 1239 | algorithms with the following properties:
|
---|
| 1240 |
|
---|
| 1241 | \begin{itemize}
|
---|
| 1242 | \item Domain:
|
---|
| 1243 | \begin{itemize}
|
---|
| 1244 | \item viewpoint (Chapter~\ref{chap:online}),
|
---|
| 1245 | \item polygon or polyhedron (Chapters~\ref{chap:sampling,chap:mutual})
|
---|
| 1246 | \end{itemize}
|
---|
| 1247 | \item Scene restrictions (occluders):
|
---|
| 1248 | \begin{itemize}
|
---|
| 1249 | \item meshes consisting of convex polygons
|
---|
| 1250 | \end{itemize}
|
---|
| 1251 | \item Scene restrictions (group objects):
|
---|
| 1252 | \begin{itemize}
|
---|
| 1253 | \item bounding boxes (Chapters~\ref{chap:rtviscull},~\ref{chap:vismap},~Chapter~\ref{chap:rot25d} and~\ref{chap:rot3d}),
|
---|
| 1254 | \end{itemize}
|
---|
| 1255 | \item Output:
|
---|
| 1256 | \begin{itemize}
|
---|
| 1257 | \item Visibility classification of objects or hierarchy nodes
|
---|
| 1258 | \item PVS
|
---|
| 1259 | \end{itemize}
|
---|
| 1260 | \item Accuracy:
|
---|
| 1261 | \begin{itemize}
|
---|
| 1262 | \item conservative
|
---|
| 1263 | \item exact
|
---|
| 1264 | \item aggresive
|
---|
| 1265 | \end{itemize}
|
---|
| 1266 | \item Solution space:
|
---|
| 1267 | \begin{itemize}
|
---|
| 1268 | \item discrete (Chapters~\ref{chap:online},~\ref{chap:sampling})
|
---|
| 1269 | \item continuous, line space / primal space (Chapter~\ref{chap:rot25d})
|
---|
| 1270 | \end{itemize}
|
---|
| 1271 | \item Solution space data structures: viewport (Chapter~\ref{chap:online}), ray stack (Chapter~\ref{chap:sampling}), ray stack or BSP tree (Chapter~\ref{chap:mutual})
|
---|
| 1272 | \item Use of coherence of visibility:
|
---|
| 1273 | \begin{itemize}
|
---|
| 1274 | \item spatial coherence (all methods)
|
---|
| 1275 | \item temporal coherence (Chapter~\ref{chap:online})
|
---|
| 1276 | \end{itemize}
|
---|
| 1277 | \item Output sensitivity: expected in practice (all methods)
|
---|
| 1278 | \item Acceleration data structure: kD-tree (all methods)
|
---|
| 1279 | \item Use of graphics hardware: Chapter~\ref{chap:online}
|
---|
| 1280 |
|
---|
| 1281 | \end{itemize}
|
---|
| 1282 |
|
---|
| 1283 |
|
---|