mirror of https://github.com/CGAL/cgal
CGAL -> \cgal\
This commit is contained in:
Sébastien Loriot
parent
0bed78feda
commit
ca13392880
|
|
@ -6,7 +6,7 @@ In the following example a set of 3D triangles is stored in a list. The AABB pri
|
|||
\ccIncludeExampleCode{AABB_tree/AABB_triangle_3_example.cpp}
|
||||
|
||||
\subsection{Tree of Polyhedron Triangle Facets for Intersection Queries}
|
||||
In the following example the AABB primitive wraps a facet handle of a triangle polyhedral surface as \ccc{id} and the corresponding 3D triangle as geometric object. From a segment query we test the intersections, then compute the number of intersections, compute the first encountered intersection (generally a point), compute all intersections (where each intersection is a pair of one CGAL object and one primitive id - here a face handle) and compute all intersected primitives. The latter involves only tests and no predicates and is hence faster than computing all intersections. We also compute the first encountered intersection with a plane query, which is generally a segment.
|
||||
In the following example the AABB primitive wraps a facet handle of a triangle polyhedral surface as \ccc{id} and the corresponding 3D triangle as geometric object. From a segment query we test the intersections, then compute the number of intersections, compute the first encountered intersection (generally a point), compute all intersections (where each intersection is a pair of one \cgal\ object and one primitive id - here a face handle) and compute all intersected primitives. The latter involves only tests and no predicates and is hence faster than computing all intersections. We also compute the first encountered intersection with a plane query, which is generally a segment.
|
||||
\ccIncludeExampleCode{AABB_tree/AABB_polyhedron_facet_intersection_example.cpp}
|
||||
|
||||
\subsection{Tree of Polyhedron Triangle Facets for Distance Queries}
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ The experiments described above are neither exhaustive nor conclusive as we have
|
|||
|
||||
\begin{itemize}
|
||||
|
||||
\item Kernel: The type of CGAL kernel turns out to dominate the final execution times, the maximum performances being obtained with the simple Cartesian kernel parameterized with the double precision number type. In applications where the intersection and distance execution times are crucial it is possible to use this kernel for the AABB tree in combination with a more robust kernel for the main data structure.
|
||||
\item Kernel: The type of \cgal\ kernel turns out to dominate the final execution times, the maximum performances being obtained with the simple Cartesian kernel parameterized with the double precision number type. In applications where the intersection and distance execution times are crucial it is possible to use this kernel for the AABB tree in combination with a more robust kernel for the main data structure.
|
||||
|
||||
\item Primitives: Although the number of input primitives plays an obvious role in the final performance, their distribution in space is at least equally important in order to obtain a well-balanced AABB tree. Ideally the primitives must be evenly distributed in space and the long primitives spanning the bounding box of the tree root node must be avoided as much as possible. It is often beneficial to split these long primitives into smaller ones before constructing the tree, e.g., through recursive longest edge bisection for triangle surface meshes.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
\section{Design and Implementation History}
|
||||
|
||||
The package is part of CGAL since release 3.3. Of course the package is based
|
||||
The package is part of \cgal\ since release 3.3. Of course the package is based
|
||||
on the former Number type support of CGAL. This goes back to Stefan Schirra and Andreas Fabri. But on the other hand the package is to a large extend influenced
|
||||
by the experience with the number type support in \exacus~\cite{beh+-eeeafcs-05},
|
||||
which in the main goes back to
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
\section{Real Number Types}
|
||||
Every CGAL \ccc{Kernel} comes with two \emph{real number types}
|
||||
Every \cgal\ \ccc{Kernel} comes with two \emph{real number types}
|
||||
(number types embeddable into the real numbers). One of them is a
|
||||
\ccc{FieldNumberType}, and the other a \ccc{RingNumberType}. The
|
||||
coordinates of the basic kernel objects (points, vectors, etc.) come
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ interfaces between layers. Specifically, working with
|
|||
only one number type allows to optimize some polynomial operations
|
||||
as well as memory handling. The implementation of these kernels
|
||||
make heavy use of the \mpfr~\cite{cgal:mt-mpfr} and \mpfi~\cite{cgal:r-mpfi}
|
||||
libraries, and of their CGAL interfaces, \ccc{Gmpfr} and \ccc{Gmpfi}.
|
||||
libraries, and of their \cgal\ interfaces, \ccc{Gmpfr} and \ccc{Gmpfi}.
|
||||
The algebraic numbers (roots of the polynomials) are represented
|
||||
in the two \rs~kernels by a \ccc{Gmpfi} interval and a pointer to
|
||||
the polynomial of which they are roots. See \cite{cgal:lpt-wea-09}
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
\begin{ccAdvanced}
|
||||
As in Curved-kernel, I use the ``Advanced'' environment in this
|
||||
document to distinguish between my current submission to the CGAL
|
||||
document to distinguish between my current submission to the \cgal\
|
||||
editorial board and plans for the future, related to ACS. The
|
||||
``Advanced'' parts will disappear if/when this is released.
|
||||
\end{ccAdvanced}
|
||||
|
|
@ -33,10 +33,10 @@ Polynomial-2-2's gives Root-of-4's...)
|
|||
General remark about the suffix \ccc{_d_v}: \ccc{_d} stands
|
||||
for the degree of the polynomials and the algebraic numbers, and
|
||||
\ccc{_v} stands for the number of variables, which is analogous to the
|
||||
dimension for CGAL geometric objects. I had already mentioned this in an
|
||||
earlier version of this document (presented at the CGAL meeting at
|
||||
dimension for \cgal\ geometric objects. I had already mentioned this in an
|
||||
earlier version of this document (presented at the \cgal\ meeting at
|
||||
INRIA in march 05), and it is consistent with what Menelaos proposed
|
||||
later (CGAL meeting in Pisa in june 05) for a hierarchy of algebraic kernels.
|
||||
later (\cgal\ meeting in Pisa in june 05) for a hierarchy of algebraic kernels.
|
||||
\end{ccAdvanced}
|
||||
|
||||
\subsubsection*{Functors}
|
||||
|
|
|
|||
|
|
@ -246,7 +246,7 @@ point set $S$ and the convex hull of \ccc{lift(S)}: The nearest site
|
|||
Delaunay triangulation is the projection of the lower hull and the
|
||||
furthest site Delaunay triangulation is the upper hull. For
|
||||
implementation details we refer the reader to the implementation
|
||||
report available from the CGAL server.
|
||||
report available from the \cgal\ server.
|
||||
|
||||
The space requirement is the same as for convex hulls. The time
|
||||
requirement for an insert is the time to insert the lifted point
|
||||
|
|
|
|||
|
|
@ -110,10 +110,10 @@ The directory structure of a package named Package should be as follows:
|
|||
instance, GMP goes here when using the Windows installer.
|
||||
The average package won't have this directory.
|
||||
\item[{\tt scripts}]\index{scripts directory@{\tt scripts}
|
||||
directory} contains scripts that are of interest to CGAL users.
|
||||
directory} contains scripts that are of interest to \cgal\ users.
|
||||
\item[{\tt developer\_scripts}]\index{developers\_scripts
|
||||
directory@{\tt developers\_scripts} directory} contains
|
||||
scripts that are of interest to CGAL developers. This directory
|
||||
scripts that are of interest to \cgal\ developers. This directory
|
||||
is included in internal releases only, not in public releases.
|
||||
\item[{\tt dont\_submit}]%
|
||||
\ccIndexMainItem{\tt dont\_submit} specifies files and directories
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ The macro \ccc{CGAL_ALLOCATOR}\ccIndexMainItem{\ccFont CGAL_ALLOCATOR}
|
|||
is defined in the file \ccc{<CGAL/memory.h>} to be the standard allocator
|
||||
from \ccc{<memory>}.
|
||||
However, the user can redefine it, for example, if \leda\ is present,
|
||||
he can define it (before including any CGAL header file) this way :
|
||||
he can define it (before including any \cgal\ header file) this way :
|
||||
|
||||
\begin{verbatim}
|
||||
#include <LEDA/allocator.h>
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ Requirements:
|
|||
(including namespaces nested in namespace \ccc{CGAL}).
|
||||
\item explicitly prefix calls to template functions of CGAL
|
||||
(such as \ccc{square}, \ccc{sign}, \ccc{abs}, \dots) by \ccc{CGAL::}
|
||||
to ensure the functions used are the one from CGAL and not one from another
|
||||
to ensure the functions used are the one from \cgal\ and not one from another
|
||||
library. If you want to allow an optimized function from another library
|
||||
to be used, then you should not qualify the call and document it explicitly
|
||||
(if appropriate).
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ It is strongly recommended for a test suite of a package to
|
|||
should be called at least once. (See Section~\ref{sec:gcov} for
|
||||
a description of a tool you can use to test for code coverage.)
|
||||
\item Use more than one instantiation of templated functions or classes.
|
||||
\item A lot of classes in CGAL can be parametrized by traits classes, so
|
||||
\item A lot of classes in \cgal\ can be parametrized by traits classes, so
|
||||
that they are usable with different kernels. In such cases more than one
|
||||
kernel should be used for testing.
|
||||
\item Use pre- and postcondition checkers wherever it is possible in the
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Most of these scripts can be in at least two places.
|
|||
|
||||
The script
|
||||
\ccAnchor{https://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/Scripts/developer_scripts/create_new_release?root=cgal&view=markup}
|
||||
{{\tt create\_new\_release}} builds a tarball of CGAL from an SVN working
|
||||
{{\tt create\_new\_release}} builds a tarball of \cgal\ from an SVN working
|
||||
copy of the trunk (or a branch).
|
||||
The command
|
||||
\begin{verse}
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ The Bourne-shell script \texttt{cgal\_create\_cmake\_script} is contained in the
|
|||
\texttt{cgal\_create\_cmake\_script} in an application directory creates a
|
||||
\texttt{CMakeLists.txt} containing rules for every \texttt{*.cpp} file
|
||||
there. Currently, that script only works for applications that only need
|
||||
the CGAL and CGALCore libraries.
|
||||
the \cgal\ and CGALCore libraries.
|
||||
|
||||
|
||||
%%
|
||||
|
|
|
|||
|
|
@ -803,9 +803,9 @@ cmake -DCGAL_DIR=CGAL-3.8 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS=-O2 -DCGAL_
|
|||
|
||||
For relatively simple programs the Bourne-shell script \texttt{cgal\_create\_cmake\_script} can be used
|
||||
(a short description of this file is provided in Appendix \ref{sec:create_cgal_cmake_script}).
|
||||
More generally, within a cmake script, once CGAL has been found using \texttt{find\_package}
|
||||
More generally, within a cmake script, once \cgal\ has been found using \texttt{find\_package}
|
||||
the variable \texttt{CGAL\_USE\_FILE} is set to a compilation environment CMake file. Including
|
||||
this file within a cmake script sets up include paths and libraries to link with of CGAL and third party libraries.
|
||||
this file within a cmake script sets up include paths and libraries to link with of \cgal\ and third party libraries.
|
||||
|
||||
|
||||
\section{Summary of Configuration Variables}
|
||||
|
|
@ -984,7 +984,7 @@ Under Linux, the GMPXX is also searched for, and you may specify the following v
|
|||
\index{cgal!general-config-cmake-vars-dep-mpfi}\index{cgal configuration cmake variables - dependencies - mpfi}
|
||||
\subsubsection{MPFI library}
|
||||
|
||||
CGAL provides a number type based on this library, but the CGAL library
|
||||
\cgal\ provides a number type based on this library, but the \cgal\ library
|
||||
itself does not depend on MPFI. This means that this library must be
|
||||
configured when compiling an application that uses the above number type.
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ kernel concept. For all kernel objects types, the types
|
|||
\ccHtmlNoLinksFrom{\ccc{CGAL::Type<Kernel>}} and
|
||||
\ccHtmlNoLinksFrom{\ccc{Kernel::Type}} are identical.
|
||||
|
||||
CGAL offers four families of concrete models for the concept Kernel,
|
||||
\cgal\ offers four families of concrete models for the concept Kernel,
|
||||
two based on the \ccHtmlNoLinksFrom{Cartesian} representation of
|
||||
points and two based on the homogeneous representation of points. The
|
||||
interface of the kernel objects is designed such that it works well
|
||||
|
|
@ -92,7 +92,7 @@ this case. With \ccc{Cartesian<FieldNumberType>}, both
|
|||
\ccc{FieldNumberType}.
|
||||
|
||||
\ccc{Cartesian<FieldNumberType>} uses reference counting internally to
|
||||
save copying costs. CGAL also provides
|
||||
save copying costs. \cgal\ also provides
|
||||
\ccc{Simple_cartesian<FieldNumberType>}, a kernel that uses
|
||||
\ccHtmlNoLinksFrom{Cartesian} representation but no reference
|
||||
counting. Debugging is easier with
|
||||
|
|
@ -131,7 +131,7 @@ quotients, i.e., a numerator and a denominator. With
|
|||
\ccc{RingNumberType}.
|
||||
|
||||
\ccc{Homogeneous<RingNumberType>} uses reference counting internally
|
||||
to save copying costs. CGAL also provides
|
||||
to save copying costs. \cgal\ also provides
|
||||
\ccc{Simple_homogeneous<RingNumberType>}, a kernel that uses
|
||||
\ccHtmlNoLinksFrom{homogeneous} representation but no reference
|
||||
counting. Debugging is easier with
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ especially for equality testing.
|
|||
\ccNestedType{RT}{a model of \ccc{RingNumberType}}
|
||||
|
||||
The following types describe the return types of predicates. They typically
|
||||
map to \ccc{bool} and CGAL kernel enum types, except when an interval arithmetic
|
||||
map to \ccc{bool} and \cgal\ kernel enum types, except when an interval arithmetic
|
||||
number type is used such as within the filtering kernels, in which case it is
|
||||
\ccc{Uncertain<bool>} or similar.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ original design was driven by the realization of a d-dimensional
|
|||
convex hull data type developed at the
|
||||
\ccHtmlNoLinksFrom{Max-Planck Institut f\"ur Informatik}.
|
||||
|
||||
The code base was discussed and reviewed within the CGAL kernel group
|
||||
The code base was discussed and reviewed within the \cgal\ kernel group
|
||||
(of the low-dimensional kernel). This led to the identification of
|
||||
the concept interfaces and in parallel to adaptations according to the
|
||||
evolution of the low-dimensional kernel. The kernel was revised
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ class provides the actual implementations of the kernel objects. For
|
|||
all kernel objects \ccc{Kernel_object}, the types
|
||||
\ccc{CGAL::Kernel_object<R>} and \ccc{R::Kernel_object} are identical.
|
||||
|
||||
CGAL offers two families of concrete models for the concept
|
||||
\cgal\ offers two families of concrete models for the concept
|
||||
representation class, one based on the \ccHtmlNoLinksFrom{Cartesian}
|
||||
representation of points and one based on the homogeneous
|
||||
representation of points. The interface of the kernel objects is
|
||||
|
|
@ -153,7 +153,7 @@ makes all \cgal\ classes very uniform. They {\bf always} consist of:
|
|||
|
||||
\subsection{Kernel as a Traits Class}
|
||||
|
||||
Algorithms and data structures in the basic library of CGAL are
|
||||
Algorithms and data structures in the basic library of \cgal\ are
|
||||
parameterized by a traits class that subsumes the objects on which the
|
||||
algorithm or data structure operates as well as the operations to do
|
||||
so. For most of the algorithms and data structures in the basic
|
||||
|
|
|
|||
|
|
@ -211,7 +211,7 @@ structure.
|
|||
\subsection{The Kinetic::InstantaneousKernel\label{sec:kds_instantaneous_kernel}}
|
||||
|
||||
|
||||
The \ccc{Kinetic::InstantaneousKernel} allows existing CGAL data structures
|
||||
The \ccc{Kinetic::InstantaneousKernel} allows existing \cgal\ data structures
|
||||
to be used on moving data as it appears at some instant of time.
|
||||
Models of this concept are, by definition, models of a CGAL
|
||||
Kernel or a traits class, and, therefore, can then be used as
|
||||
|
|
@ -227,7 +227,7 @@ initialization, as well as at times during the simulation when we want
|
|||
to insert a point to the kinetic Delaunay triangulation, a static
|
||||
version of the Delaunay triangulation is conceptually instantiated.
|
||||
More precisely, the time for the copy of the model of the
|
||||
\ccc{Kinetic::InstantaneousKernel} stored in the CGAL triangulation is set
|
||||
\ccc{Kinetic::InstantaneousKernel} stored in the \cgal\ triangulation is set
|
||||
to be the current time (or rather, as discussed in the introduction, a
|
||||
more convenient time determined by the \ccc{Kinetic::Simulator}
|
||||
combinatorially equivalent to the current time). The kinetic data
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ structure interacts with the various parts. The main concepts are
|
|||
the correct order and audit kinetic data structures. There should be
|
||||
one instance of a model of this concept per simulation.
|
||||
\item the \ccc{Kinetic::Kernel}. The structure of a
|
||||
\ccc{Kinetic::Kernel} is analogous to the static CGAL (i.e.,
|
||||
\ccc{Kinetic::Kernel} is analogous to the static \cgal\ (i.e.,
|
||||
non-kinetic) kernels in that it defines a set of primitives and
|
||||
functors which generate certificates from the primitives.
|
||||
\item the \ccc{Kinetic::ActiveObjectsTable}. Models of this concept hold a
|
||||
|
|
@ -42,7 +42,7 @@ structure interacts with the various parts. The main concepts are
|
|||
primitives are added or primitives are deleted.
|
||||
There is generally one instance of a model of this concept per simulation.
|
||||
\item the \ccc{Kinetic::InstantaneousKernel}. Models of this concept allow
|
||||
existing non-kinetic CGAL data structures to be used on a snapshot
|
||||
existing non-kinetic \cgal\ data structures to be used on a snapshot
|
||||
of kinetic data. As a result, pre-existing static structures can be
|
||||
used to initialize and audit kinetic data structures.
|
||||
\item the \ccc{Kinetic::FunctionKernel}. This concept is the computational
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@
|
|||
|
||||
This class provides a model of \ccc{Kinetic::Kernel} for use with general Cartesian geometry.
|
||||
|
||||
The IO format for points is currently $p_0$, $p_1$, ... $w$. $p_i$ and $w$ are instances of Function. There IO format is typically $c_0+c_1t+c_2t^2+...$. Beware of issues with CGAL IO of the coeffients as exact number typles often require that the coefficents be expressed as $a/b$ even when $b$ is 1.
|
||||
The IO format for points is currently $p_0$, $p_1$, ... $w$. $p_i$ and $w$ are instances of Function. There IO format is typically $c_0+c_1t+c_2t^2+...$. Beware of issues with \cgal\ IO of the coeffients as exact number typles often require that the coefficents be expressed as $a/b$ even when $b$ is 1.
|
||||
|
||||
\ccInclude{CGAL/Kinetic/Cartesian.h}
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@
|
|||
|
||||
\ccDefinition
|
||||
|
||||
The concept \ccRefName\ acts as the kinetic analog of a CGAL kernel.
|
||||
The concept \ccRefName\ acts as the kinetic analog of a \cgal\ kernel.
|
||||
It provides some set of primitives and predicats acting on them. The
|
||||
predicates are instances of \ccc{Kinetic::CertificateGenerator} and
|
||||
can be used to either create \ccc{Certificate}s or to evaluate
|
||||
|
|
|
|||
|
|
@ -1440,8 +1440,8 @@ Notably still missing are \verb+\left|+ and similar constructs for arrays.
|
|||
|
||||
\section{CGAL Related Macros}
|
||||
\subsection{Package Description}
|
||||
The HTML version of the CGAL Manual allows to give short descriptions for
|
||||
each CGAL package. It is considered good practice to put the package
|
||||
The HTML version of the \cgal\ Manual allows to give short descriptions for
|
||||
each \cgal\ package. It is considered good practice to put the package
|
||||
description in a file called \verb+PkgDescription.tex+. This file has to be
|
||||
included explicitly from the main tex file.
|
||||
|
||||
|
|
@ -1455,7 +1455,7 @@ enclosed in
|
|||
At least there has to be a summary text given by
|
||||
\verb+\ccPkgSummary{+{\em text}\verb+}+. For the hurried user, small
|
||||
illustrations provide a nice graphical overview of
|
||||
CGAL packages. It is strongly encouraged to provide such illustrations.
|
||||
\cgal\ packages. It is strongly encouraged to provide such illustrations.
|
||||
Thumbnails are rendered to the left of the summary and can be clicked to
|
||||
reveal a larger, more detailled image:
|
||||
|
||||
|
|
@ -1484,7 +1484,7 @@ Packages may have individual licenses. To indicate which one, use
|
|||
\item \verb+\ccLicenseCommercial+
|
||||
\end{itemize}
|
||||
|
||||
Finally, you have the opportunity to let other researchers cite your CGAL package using
|
||||
Finally, you have the opportunity to let other researchers cite your \cgal\ package using
|
||||
\verb+\ccPkgHowToCiteCgal{+{\em bibkey}\verb+}+.
|
||||
|
||||
A typical package description may look like this:
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ points on constrained edges.
|
|||
\ccMethod{Angle_2 angle_2_object();}{}
|
||||
|
||||
\ccHasModels
|
||||
Any model of \ccc{Kernel} concept. In particular, all CGAL kernels.
|
||||
Any model of \ccc{Kernel} concept. In particular, all \cgal\ kernels.
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ object \ccc{Construct_circumcenter_2}.
|
|||
\ccMethod{Compute_area_2 compute_area_2_object();}{}
|
||||
|
||||
\ccHasModels
|
||||
Any model of the \ccc{Kernel} concept. In particular, all CGAL kernels.
|
||||
Any model of the \ccc{Kernel} concept. In particular, all \cgal\ kernels.
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
||||
|
|
|
|||
|
|
@ -865,7 +865,7 @@ with 32GB of RAM. The program has been compiled with g++ v4.3.2 with the -O3 opt
|
|||
Note that our implementation does not take advantage of multi-core
|
||||
architectures.
|
||||
|
||||
Those benchmarks have been done using CGAL v3.8.
|
||||
Those benchmarks have been done using \cgal\ v3.8.
|
||||
|
||||
\subsection{Delaunay refinement}
|
||||
|
||||
|
|
@ -969,7 +969,7 @@ shows the mesh obtained for size set to 4.
|
|||
\subsubsection{Theoretical foundations}
|
||||
|
||||
|
||||
The CGAL mesh generation package implements a meshing engine based
|
||||
The \cgal\ mesh generation package implements a meshing engine based
|
||||
on the method of Delaunay refinement introduced by Chew~\cite{c-gqmgc-93} and Ruppert~\cite{r-draq2d-95}
|
||||
and pioneered in 3D by Shewchuk~\cite{s-tmgdr-98}.
|
||||
It uses the notion of restricted Delaunay triangulation
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ $O(n^3m^3)$ time.
|
|||
|
||||
Since the computation of the Minkowski sum takes quite some time, we
|
||||
give the running times of some Minkowski sum computations. They were
|
||||
computed with CGAL 3.3 on a machine with a 2.4 GHz AMD Opteron
|
||||
computed with \cgal\ 3.3 on a machine with a 2.4 GHz AMD Opteron
|
||||
processor and 4 GB RAM. The code was compiled with
|
||||
g++ 3.2 and compiler options -O2. The
|
||||
\ccc{Nef\_polyhedron\_3} class was instantiated with the geometric
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ operations.
|
|||
|
||||
In the following examples skip the typedefs at the beginning at first
|
||||
and take the types \ccc{Point} and \ccc{Line} to be models of the
|
||||
standard two-dimensional CGAL kernel (\ccc{CGAL::Point_2<K>}
|
||||
standard two-dimensional \cgal\ kernel (\ccc{CGAL::Point_2<K>}
|
||||
and \ccc{CGAL::Line_2<K>}). Their user interface is thus defined in
|
||||
the corresponding reference pages.
|
||||
|
||||
|
|
|
|||
|
|
@ -264,7 +264,7 @@ construct the intersection of two halfspaces.
|
|||
|
||||
After line (*) \ccc{N3} is the intersection of \ccc{N1} and \ccc{N2}.
|
||||
The member types of \ccc{Nef_polyhedron_2< Extended_homogeneous<NT> >}
|
||||
map to corresponding types of the standard CGAL geometry kernel
|
||||
map to corresponding types of the standard \cgal\ geometry kernel
|
||||
(type equality in pseudo-code notation):
|
||||
\begin{ccExampleCode}
|
||||
CGAL::Nef_polyhedron_2< CGAL::Extended_cartesian<FT> >::Point
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ type \ccc{unsafe_comparison}.
|
|||
\ccFunction{Uncertain<Sign> sign(Interval_nt i);}{}
|
||||
|
||||
\ccTypedef{typedef Interval_nt<false> Interval_nt_advanced;}
|
||||
{This typedef (at namespace CGAL scope) exists for backward compatibility,
|
||||
{This typedef (at namespace \cgal\ scope) exists for backward compatibility,
|
||||
as well as removing the need to remember the Boolean value for the template
|
||||
parameter.}
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ Keep in mind:
|
|||
|
||||
\item \ccc{mpz_class}:\\
|
||||
Implementation supports expression templates,
|
||||
up to the same level as the old CGAL implementation.
|
||||
up to the same level as the old \cgal\ implementation.
|
||||
i.e. it is possible to call CGAL::square(x+x) but the result is
|
||||
\ccc{mpz_class } and not the according expression template.
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ In the context of surface reconstruction we can position the elements of this co
|
|||
\begin{figure}[h]
|
||||
\caption{Point set processing pipeline for surface reconstruction.
|
||||
The algorithms listed in gray are available from other
|
||||
CGAL components (bounding volumes and principal
|
||||
\cgal\ components (bounding volumes and principal
|
||||
component analysis).}
|
||||
\label{Point_set_processing_3-fig-pipeline}
|
||||
\end{figure}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
This package provides functions to analyze sets of objects in 2D and 3D. It provides the computation of axis-aligned bounding boxes, centers of mass and principal component analysis for all bounded objects, as well as barycenters for sets of weighted points. Note that unlike most of the CGAL packages, this package uses approximation methods (in particular for linear least squares fitting) and is not intended to provide an exact canonical result in any sense.
|
||||
This package provides functions to analyze sets of objects in 2D and 3D. It provides the computation of axis-aligned bounding boxes, centers of mass and principal component analysis for all bounded objects, as well as barycenters for sets of weighted points. Note that unlike most of the \cgal\ packages, this package uses approximation methods (in particular for linear least squares fitting) and is not intended to provide an exact canonical result in any sense.
|
||||
|
||||
\section{Definitions}
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ provides overloaded operators and functions to naturally extend the Boolean
|
|||
operations for \ccc{Uncertain<bool>} for example, or the operations on
|
||||
enumeration types.
|
||||
|
||||
\ccc{Uncertain<T>} is used in CGAL as the return type of geometric predicates
|
||||
\ccc{Uncertain<T>} is used in \cgal\ as the return type of geometric predicates
|
||||
when the number type used is interval arithmetic like \ccc{Interval_nt}. End
|
||||
users typically do not see it, as it is hidden in the implementation of the
|
||||
filtered predicates provided by the various filtered kernels, but it is
|
||||
|
|
|
|||
|
|
@ -1434,7 +1434,7 @@
|
|||
%% +--------------------------------------------------------+
|
||||
|
||||
\begin{ccRefClass}{Twotuple<T>}
|
||||
This class is deprecated, and will be removed in some future CGAL release.
|
||||
This class is deprecated, and will be removed in some future \cgal\ release.
|
||||
Please use \ccc{CGAL::cpp0x::array} instead.
|
||||
|
||||
\begin{ccDeprecated}
|
||||
|
|
@ -1474,7 +1474,7 @@
|
|||
%% +--------------------------------------------------------+
|
||||
|
||||
\begin{ccRefClass}{Threetuple<T>}
|
||||
This class is deprecated, and will be removed in some future CGAL release.
|
||||
This class is deprecated, and will be removed in some future \cgal\ release.
|
||||
Please use \ccc{CGAL::cpp0x::array} instead.
|
||||
|
||||
\begin{ccDeprecated}
|
||||
|
|
@ -1516,7 +1516,7 @@
|
|||
%% +--------------------------------------------------------+
|
||||
|
||||
\begin{ccRefClass}{Fourtuple<T>}
|
||||
This class is deprecated, and will be removed in some future CGAL release.
|
||||
This class is deprecated, and will be removed in some future \cgal\ release.
|
||||
Please use \ccc{CGAL::cpp0x::array} instead.
|
||||
|
||||
\begin{ccDeprecated}
|
||||
|
|
@ -1560,7 +1560,7 @@
|
|||
%% +--------------------------------------------------------+
|
||||
|
||||
\begin{ccRefClass}{Sixtuple<T>}
|
||||
This class is deprecated, and will be removed in some future CGAL release.
|
||||
This class is deprecated, and will be removed in some future \cgal\ release.
|
||||
Please use \ccc{CGAL::cpp0x::array} instead.
|
||||
|
||||
\begin{ccDeprecated}
|
||||
|
|
|
|||
|
|
@ -59,10 +59,10 @@ This is equivalent to \ccc{arrange_offset_polygons_2(create_exterior_skeleton_an
|
|||
\ccRequirements
|
||||
|
||||
\begin{enumerate}
|
||||
\item \ccc{OffsettingK} is the CGAL kernel used to instantiate
|
||||
\item \ccc{OffsettingK} is the \cgal\ kernel used to instantiate
|
||||
\ccc{Polygon_offset_builder_traits_2<K>} for constructing
|
||||
the offset polygons.
|
||||
\item \ccc{SkeletonK} is the CGAL kernel used to instantiate
|
||||
\item \ccc{SkeletonK} is the \cgal\ kernel used to instantiate
|
||||
\ccc{Straight_skeleton_builder_traits_2<K>} for constructing
|
||||
the straight skeleton.
|
||||
If \ccc{SkeletonK != OffsettingK} the constructed straight skeleton
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ $d$ is a margin sufficiently large to allow an outer offset at dinstance \ccc{ma
|
|||
\ccHeading{Requirements}
|
||||
|
||||
\begin{enumerate}
|
||||
\item \ccc{K} is any CGAL kernel.
|
||||
\item \ccc{K} is any \cgal\ kernel.
|
||||
\item \ccc{PointIterator::value_type} is equivalent to \ccc{K2::Point_2}.
|
||||
A cartesian converter is used to convert from \ccc{K2::Point_2} to \ccc{K::Point_2}
|
||||
\item \ccc{Polygon} is \ccc{Polygon_2<K>} or a standard container of \ccc{K2::Point_2} elements
|
||||
|
|
|
|||
|
|
@ -103,10 +103,10 @@ create_interior_skeleton_and_offset_polygons_with_holes_2
|
|||
This is equivalent to \ccc{arrange_offset_polygons_2(create_interior_skeleton_and_offset_polygons_2(offset,poly_with_holes,okk,ssk))}.}
|
||||
|
||||
\begin{enumerate}
|
||||
\item \ccc{OffsettingK} is the CGAL kernel used to instantiate
|
||||
\item \ccc{OffsettingK} is the \cgal\ kernel used to instantiate
|
||||
\ccc{Polygon_offset_builder_traits_2<K>} for constructing
|
||||
the offset polygons.
|
||||
\item \ccc{SkeletonK} is the CGAL kernel used to instantiate
|
||||
\item \ccc{SkeletonK} is the \cgal\ kernel used to instantiate
|
||||
\ccc{Straight_skeleton_builder_traits_2<K>} for constructing
|
||||
the straight skeleton.
|
||||
If \ccc{SkeletonK != OffsettingK} the constructed straight skeleton
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ create_interior_straight_skeleton_2 ( Polygon const& outer_contour
|
|||
|
||||
|
||||
\begin{enumerate}
|
||||
\item \ccc{K} is any CGAL kernel.
|
||||
\item \ccc{K} is any \cgal\ kernel.
|
||||
\item \ccc{PointIterator::value_type} is equivalent to \ccc{K2::Point_2}.
|
||||
A cartesian converter is used to convert from \ccc{K2::Point_2} to \ccc{K::Point_2}
|
||||
\item \ccc{HoleIterator::value_type} and \ccc{Polygon} are \ccc{Polygon_2<K>}
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ the straight skeleton $s$.
|
|||
|
||||
|
||||
\begin{enumerate}
|
||||
\item \ccc{K} is any CGAL kernel.
|
||||
\item \ccc{K} is any \cgal\ kernel.
|
||||
\item \ccc{FT} is any number type implicitly convertible to \ccc{K::FT}.
|
||||
\item \ccc{Straight_skeleton} is \ccc{Straight_skeleton_2<K2>}.
|
||||
If $K != K2$ the straight skeleton is converted to \ccc{Straight_skeleton_2<K>}.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@
|
|||
The class \ccRefName\ provides a model for the
|
||||
\ccc{StraightSkeletonBuilderTraits_2} concept which is the traits class
|
||||
required by the \ccc{Straight_skeleton_builder_2} algorithm class. The class
|
||||
\ccRefName\ has one template argument: a 2D CGAL Kernel. This parameter must be a model for the \ccc{Kernel} concept, such as the \ccc{Exact_predicates_inexact_constructions_kernel}, which is the recommended one.\\
|
||||
\ccRefName\ has one template argument: a 2D \cgal\ Kernel. This parameter must be a model for the \ccc{Kernel} concept, such as the \ccc{Exact_predicates_inexact_constructions_kernel}, which is the recommended one.\\
|
||||
It is unspecified which subset of the kernel is used into the output sequence and the returned iterator will be equal to \ccc{out}.
|
||||
|
||||
For any given input polygon, it in this traits class (and by extension in the builder class). This is to avoid restricting the choices in the implementation.
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ This concept provides the types handled by the
|
|||
|
||||
|
||||
\ccHasModels
|
||||
The kernels of CGAL are models for this traits class. \\
|
||||
The kernels of \cgal\ are models for this traits class. \\
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@
|
|||
|
||||
\ccc{Parameterization_polyhedron_adaptor_3} is an adaptor class to access to a Polyhedron 3D mesh using the \ccc{ParameterizationPatchableMesh_3} interface. Among other things, this concept defines the accessor to the (u, v) values computed by parameterizations methods.
|
||||
|
||||
Note that these interfaces are decorators that add {\em on the fly} the necessary fields to unmodified CGAL data structures (using STL maps). For performance reasons, it is recommended to use CGAL data structures enriched with the proper fields.
|
||||
Note that these interfaces are decorators that add {\em on the fly} the necessary fields to unmodified \cgal\ data structures (using STL maps). For performance reasons, it is recommended to use \cgal\ data structures enriched with the proper fields.
|
||||
|
||||
A \ccc{ParameterizationMesh_3} surface consists of vertices, facets and an incidence relation on them. No notion of edge is requested.
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ facets of the 2D complex and to antenna edges or marked edges.
|
|||
\ccParameters
|
||||
The class \ccRefName\ is parametrized by the underlying
|
||||
3D triangulation.
|
||||
Any triangulation can of CGAL can be used to instantiate this parameter.
|
||||
Any triangulation can of \cgal\ can be used to instantiate this parameter.
|
||||
The parameters \ccc{Facet_info} and \ccc{Edge_info}
|
||||
provide the types of the information the wishes to attached
|
||||
respectively to the facets of the 2D complex or to the marked
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ objects:
|
|||
|
||||
\ccHasModels
|
||||
|
||||
Any CGAL Kernel.
|
||||
Any \cgal\ Kernel.
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ The algorithm is in general not robust to outliers, although a few outliers do n
|
|||
\end{center}
|
||||
|
||||
|
||||
The algorithm works well even when the inferred surface is composed of several connected components, provided that both all normals are properly estimated and oriented (the current CGAL normal orienter algorithm may fail in some cases, see \ccc{CGAL::mst_orient_normals()}), and that the final contouring algorithm is properly seeded for each component. When the inferred surface is composed of several nested connected components care should be taken to orient the normals of each component in alternation (inward/outward) so that the final contouring stage picks a proper contouring value.
|
||||
The algorithm works well even when the inferred surface is composed of several connected components, provided that both all normals are properly estimated and oriented (the current \cgal\ normal orienter algorithm may fail in some cases, see \ccc{CGAL::mst_orient_normals()}), and that the final contouring algorithm is properly seeded for each component. When the inferred surface is composed of several nested connected components care should be taken to orient the normals of each component in alternation (inward/outward) so that the final contouring stage picks a proper contouring value.
|
||||
|
||||
|
||||
\subsubsection{Contouring Parameters}
|
||||
|
|
|
|||
|
|
@ -832,7 +832,7 @@ instance of the \ccc{Filtered_kernel} template.
|
|||
|
||||
The base vertex type of a regular triangulation
|
||||
includes a Boolean data member to mark the hidden state of the vertex.
|
||||
Therefore CGAL defines the concept
|
||||
Therefore \cgal\ defines the concept
|
||||
\ccc{RegularTriangulationVertexBase_2} which refine
|
||||
the concept \ccc{TriangulationVertexBase_2}
|
||||
and provides a default model
|
||||
|
|
@ -919,7 +919,7 @@ constraints and its constrained triangulation">
|
|||
</CENTER>
|
||||
\end{ccHtmlOnly}
|
||||
|
||||
A constrained triangulation is represented in the CGAL library as an
|
||||
A constrained triangulation is represented in the \cgal\ library as an
|
||||
object of the class \ccc{Constrained_triangulation_2<Traits,Tds,Itag>}.
|
||||
The third parameter \ccc{Itag} is the intersection tag
|
||||
which serves to choose how intersecting constraints
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ constraints and its constrained triangulation">
|
|||
</CENTER>
|
||||
\end{ccHtmlOnly}
|
||||
|
||||
The class \ccRefName\ of the CGAL library
|
||||
The class \ccRefName\ of the \cgal\ library
|
||||
implements constrained triangulations.
|
||||
The template parameter \ccc{Traits}
|
||||
stands for a geometric traits class. It has to be a model
|
||||
|
|
|
|||
|
|
@ -141,7 +141,7 @@ called.}
|
|||
|
||||
|
||||
\ccHasModels
|
||||
All the CGAL Kernels \\
|
||||
All the \cgal\ Kernels \\
|
||||
\ccRefIdfierPage{CGAL::Triangulation_euclidean_traits_2<K>} \\
|
||||
\ccRefIdfierPage{CGAL::Projection_traits_xy_3<K>}\\
|
||||
\ccc{CGAL::Projection_traits_yz_3<K>}\\
|
||||
|
|
|
|||
|
|
@ -847,7 +847,7 @@ In 2011, Pedro de Castro and Olivier Devillers implemented in release
|
|||
3.8 the
|
||||
structural filtering method, improving the efficiency of point location.
|
||||
|
||||
A new demo of this package was introduced in CGAL 3.8, coded by Fei
|
||||
A new demo of this package was introduced in \cgal\ 3.8, coded by Fei
|
||||
(Sophie) Che, who was co-mentored by Manuel Caroli and Monique
|
||||
Teillaud in the framework of the Google Summer of Code, 2010.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue