% geometric computing

There are geometric algorithms available in \cgal, not directly
processing a mesh, but that can be helpful in the mesh processing
context, for example, a fast self intersection test, the smallest
enclosing sphere, or the minimum width of a point set. We use a few
large meshes (see Fig.~\ref{fig:models}) to evaluate performance on a
laptop with an Intel Mobile Pentium4 running at 1.80GHz with 512KB
cache and 254MB main memory under Linux. For our largest mesh, the
Raptor, the algorithms started swapping. Nevertheless, the runtimes
are acceptable. For the final paper, we can in addition run the
experiments on a larger machine.

The self intersection test is based on the general algorithm for fast
box intersections~\cite{cgal:ze-fsbi-02}, applied to the bounding
boxes of individual facets, i.e. triangles, as a filtering step. The
triangles of intersecting boxes are then checked in detail, i.e., if
they share common edge, they do not intersect, if they share a common
vertex, the may intersect or not depending on the opposite edge, and
otherwise the intersection test for triangles in the \cgal\ geometric
kernel is used to decide the intersection. A geometric kernel with
exact predicates is sufficient for this algorithm. Interestingly, only
the lion vase is free of self intersections. The algorithm is fast,
see the table below, though not sufficient for interactive use.
Nevertheless, a final quality check is possible for quite large meshes
before they, for example, go into production.

\noindent\hspace*{-3mm}%
{\small
\begin{tabular}{l|ccccc}
  \multicolumn{1}{l}{{\footnotesize time in}}
  & \multicolumn{2}{c}{\textbf{min. sphere}}
  & \textbf{convex} & \textbf{min.} & \textbf{self inter-}\\
  \multicolumn{1}{l}{{\footnotesize seconds}}
  & \CodeFmt{double} & \CodeFmt{gmpq}
  & \textbf{hull} & \textbf{width}  & \textbf{section}\\\hline
  Bunny     &  0.02 & \hspace*{1ex}14 & 
                 \hspace*{1ex}3.5 & 111 & \hspace*{1ex}3.2\\
  Lion vase\hspace*{-16mm} & 0.19 & 396 & 13.1 & 276 & 22.9 \\
  David     & 0.12 & 215 & 20.3 & 112 & 41.6 \\
  Raptor    & 0.35 & 589 & 45.5 & 123 & 92.3
\end{tabular}
}

% figure trimming
\begin{figure}
  \centering
  \epsfig{file=figs/trimming.eps, width=\linewidth}
  \caption{Remeshing phase: a dome-like shape is sampled with lines of
  curvatures. All the curvature line segments (red/blue) and the
  feature edges (green) are added as constraints in a CDT in parameter
  space. The CDT creates a dense triangulation; a vertex
  decimation (A,B) then suppresses most small edges, and leaves only
  few vertices, defining a quad-dominant polygonal mesh.}
  \label{fig:trimming}\vspace{-3mm}
\end{figure}


Smallest enclosing spheres, min.~sphere for short, are commonly used
as bounding volumes in bounding volume hierarchies, for example, to
speed up intersection tests. This algorithm~\cite{fg-sebbc-03} needs a
geometric kernel with an exact number type for correctness, but
specializations for the number types \CodeFmt{double} and
\CodeFmt{float} have been written to be very robust as well. We use
\CodeFmt{gmpq} from the GMP number type package
here~\cite{cgal:g-gmpal-96}. The runtimes are slow, but still feasible
for huge meshes. In contrast, when we run the algorithm with the
\CodeFmt{double} number type, it becomes fast enough to be considered
for interactive purposes, for example, selecting a good view frustum
in a viewer. We compared the resulting spheres of the algorithm
running with the exact and with the floating-point number type. In all
cases the sphere center coordinates and the radius where exactly the
same up to the seven digits after the decimal. We want to point out
the running time anomaly in above table---the smaller lion vase needs
longer than the larger David sculpture---which is o.k. for this data
sensitive algorithm. It is worst-case linear time, but depends on a
heuristic to be really fast.


% models used for benchmarking
\begin{figure}
  \centering
  \epsfig{file=figs/models.eps, width=\linewidth}
  \caption{Models used for benchmarking. 
           Complexity (in triangles):
           Bunny: 69,451,
           Lion vase: 400k,
           David (simplified version): 700k,
           Raptor: 2M.}
  \label{fig:models}\vspace{-3mm}
\end{figure}


% \begin{tabular}{l|ll}
%   \textbf{smallest enclosing sphere} & \texttt{double} & exact
%     \texttt{gmpq} (non opt.)\\\hline
%   Bunny     & 0.02 &  14 \\
%   Lion vase & 0.19 & 396 \\
%   David     & 0.12 & 215 \\
%   Raptor    & 0.35  & 589
% \end{tabular}


Convex hulls are, similar to the smallest enclosing sphere, sometimes
useful as a bounding volumes, for example, as a placeholder for faster
interaction. For the quickhull algorithm~\cite{bdh-qach-96} used here
in \cgal\ a \cgal\ geometric kernel with exact predicates suffices,
and the convex hull can be computed significantly faster than the
exact smallest enclosing sphere, however, also far slower than the
\CodeFmt{double} version of the smallest enclosing sphere.

In fact we are more interested in the convex hull as a preprocessing
to another optimization algorithm, the width of a point set. The
minimum width is obtained by two parallel planes of smallest possible
distance that enclose all point between them. The printing time for
three-dimensional stereo-lithographic printer is proportional to the
height of the object printed. Minimizing this height can be done by
computing the normal direction that minimizes the width between the
two planes, and then align this normal direction with the printer
height direction.

The width algorithm requires an exact number type, so we use the
result of the convex hull computation, convert all vertices to exact
points, recompute the convex hull, and run the width algorithm. The
runtimes in the table above are for the conversion, recomputing of the
convex hull and the width computation together, but excluding the
first convex hull computation that runs on the full data set.


% \begin{tabular}{l|l}
%   & \textbf{self intersection} \\\hline
%   Bunny     & 3.2 \\
%   Lion vase & 22.9 \\
%   David     & 41.6 \\
%   Raptor    & 92.3
% \end{tabular}