mirror of https://github.com/CGAL/cgal
fixed some typos
This commit is contained in:
parent
5ed3b0d266
commit
702ab57f50
|
|
@ -16,7 +16,7 @@
|
||||||
*.py text
|
*.py text
|
||||||
*.xml text
|
*.xml text
|
||||||
*.js text
|
*.js text
|
||||||
*.hmtl text
|
*.html text
|
||||||
*.bib text
|
*.bib text
|
||||||
*.css text
|
*.css text
|
||||||
*.ui text
|
*.ui text
|
||||||
|
|
|
||||||
|
|
@ -106,7 +106,7 @@ it is used only for distance computations.
|
||||||
\warning Having degenerate primitives in the AABB-tree is not recommended as the underlying
|
\warning Having degenerate primitives in the AABB-tree is not recommended as the underlying
|
||||||
predicates and constructions of the traits class might not be able to handle them.
|
predicates and constructions of the traits class might not be able to handle them.
|
||||||
For example if one is using `CGAL::AABB_traits` with a Kernel from \cgal,
|
For example if one is using `CGAL::AABB_traits` with a Kernel from \cgal,
|
||||||
having degenerate triangles or segments in the AABB-tree will results in an undefined
|
having degenerate triangles or segments in the AABB-tree will result in an undefined
|
||||||
behavior or a crash.
|
behavior or a crash.
|
||||||
|
|
||||||
\section aabb_tree_examples Examples
|
\section aabb_tree_examples Examples
|
||||||
|
|
@ -197,8 +197,8 @@ The AABB tree example folder contains three examples of trees
|
||||||
constructed with custom primitives. In \ref AABB_tree/AABB_custom_example.cpp "AABB_custom_example.cpp"
|
constructed with custom primitives. In \ref AABB_tree/AABB_custom_example.cpp "AABB_custom_example.cpp"
|
||||||
the primitive contains triangles which are defined by three pointers
|
the primitive contains triangles which are defined by three pointers
|
||||||
to custom points. In \ref AABB_tree/AABB_custom_triangle_soup_example.cpp "AABB_custom_triangle_soup_example.cpp" all input
|
to custom points. In \ref AABB_tree/AABB_custom_triangle_soup_example.cpp "AABB_custom_triangle_soup_example.cpp" all input
|
||||||
triangles are stored into a single array so as to form a triangle
|
triangles are stored into a single array to form a triangle
|
||||||
soup. The primitive internally uses a `boost::iterator_adaptor` so as
|
soup. The primitive internally uses a `boost::iterator_adaptor`
|
||||||
to provide the three functions `AABBPrimitive::id()`, `AABBPrimitive::datum()`,
|
to provide the three functions `AABBPrimitive::id()`, `AABBPrimitive::datum()`,
|
||||||
and `AABBPrimitive::reference_point()`) required by the primitive concept. In
|
and `AABBPrimitive::reference_point()`) required by the primitive concept. In
|
||||||
\ref AABB_tree/AABB_custom_indexed_triangle_set_example.cpp "AABB_custom_indexed_triangle_set_example.cpp" the input is an indexed
|
\ref AABB_tree/AABB_custom_indexed_triangle_set_example.cpp "AABB_custom_indexed_triangle_set_example.cpp" the input is an indexed
|
||||||
|
|
@ -213,7 +213,7 @@ contains a set of polyhedron triangle facets. We measure the tree
|
||||||
construction time, the memory occupancy and the number of queries per
|
construction time, the memory occupancy and the number of queries per
|
||||||
second for a variety of intersection and distance queries. The machine
|
second for a variety of intersection and distance queries. The machine
|
||||||
used is a PC running Windows XP64 with an Intel CPU Core2 Extreme
|
used is a PC running Windows XP64 with an Intel CPU Core2 Extreme
|
||||||
clocked at 3.06 GHz with 4GB of RAM. By default the kernel used is
|
clocked at 3.06 GHz with 4GB of RAM. By default, the kernel used is
|
||||||
`Simple_cartesian<double>` (the fastest in our experiments). The
|
`Simple_cartesian<double>` (the fastest in our experiments). The
|
||||||
program has been compiled with Visual C++ 2005 compiler with the O2
|
program has been compiled with Visual C++ 2005 compiler with the O2
|
||||||
option which maximizes speed.
|
option which maximizes speed.
|
||||||
|
|
@ -244,7 +244,7 @@ internal KD-tree). It increases to approximately 150 bytes per
|
||||||
primitive when constructing the internal KD-tree with one reference
|
primitive when constructing the internal KD-tree with one reference
|
||||||
point per primitive (the default mode when calling the function
|
point per primitive (the default mode when calling the function
|
||||||
`AABB_tree::accelerate_distance_queries()`). Note that the polyhedron
|
`AABB_tree::accelerate_distance_queries()`). Note that the polyhedron
|
||||||
facet primitive primitive stores only one facet handle as primitive id
|
facet primitive stores only one facet handle as primitive id
|
||||||
and computes on the fly a 3D triangle from the facet handle stored
|
and computes on the fly a 3D triangle from the facet handle stored
|
||||||
internally. When explicitly storing a 3D triangle in the primitive the
|
internally. When explicitly storing a 3D triangle in the primitive the
|
||||||
tree occupies approximately 140 bytes per primitive instead of 60
|
tree occupies approximately 140 bytes per primitive instead of 60
|
||||||
|
|
@ -340,7 +340,7 @@ inside the bounding box.
|
||||||
|
|
||||||
The experiments described above are neither exhaustive nor conclusive
|
The experiments described above are neither exhaustive nor conclusive
|
||||||
as we have chosen one specific case where the input primitives are the
|
as we have chosen one specific case where the input primitives are the
|
||||||
facets of a triangle surface polyhedron. Nevertheless we now provide
|
facets of a triangle surface polyhedron. Nevertheless, we now provide
|
||||||
some general observations and advises about how to put the AABB tree
|
some general observations and advises about how to put the AABB tree
|
||||||
to use with satisfactory performances. While the tree construction
|
to use with satisfactory performances. While the tree construction
|
||||||
times and memory occupancy do not fluctuate much in our experiments
|
times and memory occupancy do not fluctuate much in our experiments
|
||||||
|
|
|
||||||
|
|
@ -15,7 +15,7 @@ As a consequence types representing polynomials, algebraic extensions and
|
||||||
finite fields play a more important role in related implementations.
|
finite fields play a more important role in related implementations.
|
||||||
This package has been introduced to stay abreast of these changes.
|
This package has been introduced to stay abreast of these changes.
|
||||||
Since in particular polynomials must be supported by the introduced framework
|
Since in particular polynomials must be supported by the introduced framework
|
||||||
the package avoids the term <I>number type</I>. Instead the package distinguishes
|
the package avoids the term <I>number type</I>. Instead, the package distinguishes
|
||||||
between the <I>algebraic structure</I> of a type and whether a type is embeddable on
|
between the <I>algebraic structure</I> of a type and whether a type is embeddable on
|
||||||
the real axis, or <I>real embeddable</I> for short.
|
the real axis, or <I>real embeddable</I> for short.
|
||||||
Moreover, the package introduces the notion of <I>interoperable</I> types which
|
Moreover, the package introduces the notion of <I>interoperable</I> types which
|
||||||
|
|
@ -45,11 +45,11 @@ the operations 'sqrt', 'k-th root' and 'real root of a polynomial',
|
||||||
respectively. The concept `IntegralDomainWithoutDivision` also
|
respectively. The concept `IntegralDomainWithoutDivision` also
|
||||||
corresponds to integral domains in the algebraic sense, the
|
corresponds to integral domains in the algebraic sense, the
|
||||||
distinction results from the fact that some implementations of
|
distinction results from the fact that some implementations of
|
||||||
integral domains lack the (algebraically always well defined) integral
|
integral domains lack the integral division,
|
||||||
division.
|
which is always well-defined algebraically.
|
||||||
Note that `Field` refines `IntegralDomain`. This is because
|
Note that `Field` refines `IntegralDomain`. This is because
|
||||||
most ring-theoretic notions like greatest common divisors become trivial for
|
most ring-theoretic notions like greatest common divisors become trivial for
|
||||||
`Field`s. Hence we see `Field` as a refinement of
|
`Field`s. Hence, we see `Field` as a refinement of
|
||||||
`IntegralDomain` and not as a
|
`IntegralDomain` and not as a
|
||||||
refinement of one of the more advanced ring concepts.
|
refinement of one of the more advanced ring concepts.
|
||||||
If an algorithm wants to rely on gcd or remainder computation, it is trying
|
If an algorithm wants to rely on gcd or remainder computation, it is trying
|
||||||
|
|
@ -119,7 +119,7 @@ Conversely, types as `leda_real` or `CORE::Expr` are exact but sensitive
|
||||||
to numerical issues due to the internal use of multi precision floating point
|
to numerical issues due to the internal use of multi precision floating point
|
||||||
arithmetic. We expect that `Is_numerical_sensitive` is used for dispatching
|
arithmetic. We expect that `Is_numerical_sensitive` is used for dispatching
|
||||||
of algorithms, while `Is_exact` is useful to enable assertions that can be
|
of algorithms, while `Is_exact` is useful to enable assertions that can be
|
||||||
check for exact types only.
|
checked for exact types only.
|
||||||
|
|
||||||
Tags are very useful to dispatch between alternative implementations.
|
Tags are very useful to dispatch between alternative implementations.
|
||||||
The following example illustrates a dispatch for `Field`s using overloaded
|
The following example illustrates a dispatch for `Field`s using overloaded
|
||||||
|
|
@ -134,7 +134,7 @@ category tags reflect the algebraic structure hierarchy.
|
||||||
|
|
||||||
Most number types represent some subset of the real numbers. From those types
|
Most number types represent some subset of the real numbers. From those types
|
||||||
we expect functionality to compute the sign, absolute value or double
|
we expect functionality to compute the sign, absolute value or double
|
||||||
approximations. In particular we can expect an order on such a type that
|
approximations. In particular, we can expect an order on such a type that
|
||||||
reflects the order along the real axis.
|
reflects the order along the real axis.
|
||||||
All these properties are gathered in the concept `::RealEmbeddable`.
|
All these properties are gathered in the concept `::RealEmbeddable`.
|
||||||
The concept is orthogonal to the algebraic structure concepts,
|
The concept is orthogonal to the algebraic structure concepts,
|
||||||
|
|
@ -190,12 +190,12 @@ In general mixed operations are provided by overloaded operators and
|
||||||
functions or just via implicit constructor calls.
|
functions or just via implicit constructor calls.
|
||||||
This level of interoperability is reflected by the concept
|
This level of interoperability is reflected by the concept
|
||||||
`ImplicitInteroperable`. However, within template code the result type,
|
`ImplicitInteroperable`. However, within template code the result type,
|
||||||
or so called coercion type, of a mixed arithmetic operation may be unclear.
|
or so-called coercion type, of a mixed arithmetic operation may be unclear.
|
||||||
Therefore, the package introduces `Coercion_traits`
|
Therefore, the package introduces `Coercion_traits`
|
||||||
giving access to the coercion type via \link Coercion_traits::Type `Coercion_traits<A,B>::Type` \endlink
|
giving access to the coercion type via \link Coercion_traits::Type `Coercion_traits<A,B>::Type` \endlink
|
||||||
for two interoperable types `A` and `B`.
|
for two interoperable types `A` and `B`.
|
||||||
|
|
||||||
Some trivial example are `int` and `double` with coercion type double
|
Some trivial examples are `int` and `double` with coercion type double
|
||||||
or `Gmpz` and `Gmpq` with coercion type `Gmpq`.
|
or `Gmpz` and `Gmpq` with coercion type `Gmpq`.
|
||||||
However, the coercion type is not necessarily one of the input types,
|
However, the coercion type is not necessarily one of the input types,
|
||||||
e.g. the coercion type of a polynomial
|
e.g. the coercion type of a polynomial
|
||||||
|
|
|
||||||
|
|
@ -146,8 +146,8 @@ polynomial is not computed yet.
|
||||||
This is in particular relevant in relation to the `AlgebraicKernel_d_2`,
|
This is in particular relevant in relation to the `AlgebraicKernel_d_2`,
|
||||||
where `AlgebraicKernel_d_1::Algebraic_real_1` is used to represent coordinates of solutions of bivariate systems.
|
where `AlgebraicKernel_d_1::Algebraic_real_1` is used to represent coordinates of solutions of bivariate systems.
|
||||||
Hence, the design does
|
Hence, the design does
|
||||||
not allow a direct access to any, seemingly obvious, members of an
|
not allow direct access to any, seemingly obvious, members of an
|
||||||
`AlgebraicKernel_d_1::Algebraic_real_1`. Instead there is, e.g.,
|
`AlgebraicKernel_d_1::Algebraic_real_1`. Instead, there is, e.g.,
|
||||||
`AlgebraicKernel_d_1::Compute_polynomial_1` which emphasizes
|
`AlgebraicKernel_d_1::Compute_polynomial_1` which emphasizes
|
||||||
that the requested polynomial may not be computed yet. Similarly,
|
that the requested polynomial may not be computed yet. Similarly,
|
||||||
there is no way to directly ask for the refinement of the current
|
there is no way to directly ask for the refinement of the current
|
||||||
|
|
|
||||||
|
|
@ -35,8 +35,8 @@ of this process in 2D (where our ice-cream spoon is simply a circle).
|
||||||
|
|
||||||
Alpha shapes depend on a parameter \f$ \alpha\f$ after which they are named.
|
Alpha shapes depend on a parameter \f$ \alpha\f$ after which they are named.
|
||||||
In the ice-cream analogy above, \f$ \alpha\f$ is the squared radius of the
|
In the ice-cream analogy above, \f$ \alpha\f$ is the squared radius of the
|
||||||
carving spoon. A very small value will allow us to eat up all of the
|
carving spoon. A very small value will allow us to eat up all the
|
||||||
ice-cream except the chocolate points themselves. Thus we already see
|
ice-cream except the chocolate points themselves. Thus, we already see
|
||||||
that the \f$ \alpha\f$-shape degenerates to the point-set \f$ S\f$ for
|
that the \f$ \alpha\f$-shape degenerates to the point-set \f$ S\f$ for
|
||||||
\f$ \alpha \rightarrow 0\f$. On the other hand, a huge value of \f$ \alpha\f$
|
\f$ \alpha \rightarrow 0\f$. On the other hand, a huge value of \f$ \alpha\f$
|
||||||
will prevent us even from moving the spoon between two points since
|
will prevent us even from moving the spoon between two points since
|
||||||
|
|
@ -53,7 +53,7 @@ We distinguish two versions of alpha shapes. <I>Basic alpha shapes</I>
|
||||||
are based on the Delaunay triangulation. <I>Weighted alpha shapes</I>
|
are based on the Delaunay triangulation. <I>Weighted alpha shapes</I>
|
||||||
are based on its generalization, the regular triangulation
|
are based on its generalization, the regular triangulation
|
||||||
(cf. Section \ref Section_2D_Triangulations_Regular "Regular Triangulations"),
|
(cf. Section \ref Section_2D_Triangulations_Regular "Regular Triangulations"),
|
||||||
replacing the euclidean distance by the power to weighted points.
|
replacing the Euclidean distance by the power to weighted points.
|
||||||
|
|
||||||
There is a close connection between alpha shapes and the underlying
|
There is a close connection between alpha shapes and the underlying
|
||||||
triangulations. More precisely, the \f$ \alpha\f$-complex of \f$ S\f$ is a
|
triangulations. More precisely, the \f$ \alpha\f$-complex of \f$ S\f$ is a
|
||||||
|
|
@ -100,7 +100,7 @@ It provides iterators to enumerate the vertices and edges that are in
|
||||||
the \f$ \alpha\f$-shape, and functions that allow to classify vertices,
|
the \f$ \alpha\f$-shape, and functions that allow to classify vertices,
|
||||||
edges and faces with respect to the \f$ \alpha\f$-shape. They can be in
|
edges and faces with respect to the \f$ \alpha\f$-shape. They can be in
|
||||||
the interior of a face that belongs or does not belong to the \f$ \alpha\f$-shape.
|
the interior of a face that belongs or does not belong to the \f$ \alpha\f$-shape.
|
||||||
They can be singular/regular, that is be on the boundary of the \f$ \alpha\f$-shape,
|
They can be singular/regular, that is, they can be on the boundary of the \f$ \alpha\f$-shape,
|
||||||
but not incident/incident to a triangle of the \f$ \alpha\f$-complex.
|
but not incident/incident to a triangle of the \f$ \alpha\f$-complex.
|
||||||
|
|
||||||
Finally, it provides a function to determine the \f$ \alpha\f$-value
|
Finally, it provides a function to determine the \f$ \alpha\f$-value
|
||||||
|
|
@ -213,7 +213,7 @@ cube will be chosen and no optimizations will be used.
|
||||||
It is also recommended to switch the triangulation to 1-sheeted
|
It is also recommended to switch the triangulation to 1-sheeted
|
||||||
covering if possible. Note that a periodic triangulation in 9-sheeted
|
covering if possible. Note that a periodic triangulation in 9-sheeted
|
||||||
covering space is degenerate. In this case, an exact constructions
|
covering space is degenerate. In this case, an exact constructions
|
||||||
kernel needs to be used to compute the alpha shapes. Otherwise the
|
kernel needs to be used to compute the alpha shapes. Otherwise, the
|
||||||
results will suffer from round-off problems.
|
results will suffer from round-off problems.
|
||||||
|
|
||||||
\cgalExample{Alpha_shapes_2/ex_periodic_alpha_shapes_2.cpp}
|
\cgalExample{Alpha_shapes_2/ex_periodic_alpha_shapes_2.cpp}
|
||||||
|
|
|
||||||
|
|
@ -34,8 +34,8 @@ of this process in 2D (where our ice-cream spoon is simply a circle).
|
||||||
|
|
||||||
Alpha shapes depend on a parameter \f$ \alpha\f$ after which they are named.
|
Alpha shapes depend on a parameter \f$ \alpha\f$ after which they are named.
|
||||||
In the ice-cream analogy above, \f$ \alpha\f$ is the squared radius of the
|
In the ice-cream analogy above, \f$ \alpha\f$ is the squared radius of the
|
||||||
carving spoon. A very small value will allow us to eat up all of the
|
carving spoon. A very small value will allow us to eat up all the
|
||||||
ice-cream except the chocolate points themselves. Thus we already see
|
ice-cream except the chocolate points themselves. Thus, we already see
|
||||||
that the alpha shape degenerates to the point-set \f$ S\f$ for
|
that the alpha shape degenerates to the point-set \f$ S\f$ for
|
||||||
\f$ \alpha \rightarrow 0\f$. On the other hand, a huge value of \f$ \alpha\f$
|
\f$ \alpha \rightarrow 0\f$. On the other hand, a huge value of \f$ \alpha\f$
|
||||||
will prevent us even from moving the spoon between two points since
|
will prevent us even from moving the spoon between two points since
|
||||||
|
|
@ -53,7 +53,7 @@ We distinguish two versions of alpha shapes. <I>Basic alpha shapes</I>
|
||||||
are based on the Delaunay triangulation. <I>Weighted alpha shapes</I>
|
are based on the Delaunay triangulation. <I>Weighted alpha shapes</I>
|
||||||
are based on its generalization, the regular triangulation
|
are based on its generalization, the regular triangulation
|
||||||
(cf. Section \ref Triangulation3secclassRegulartriangulation "Regular Triangulations"),
|
(cf. Section \ref Triangulation3secclassRegulartriangulation "Regular Triangulations"),
|
||||||
replacing the euclidean distance by the power to weighted points.
|
replacing the Euclidean distance by the power to weighted points.
|
||||||
|
|
||||||
Let us consider the basic case with a Delaunay triangulation.
|
Let us consider the basic case with a Delaunay triangulation.
|
||||||
We first define the alpha complex of the set of points \f$ S\f$.
|
We first define the alpha complex of the set of points \f$ S\f$.
|
||||||
|
|
@ -79,7 +79,7 @@ of the alpha complex where singular faces are removed
|
||||||
(See \cgalFigureRef{figgenregex} for an example).
|
(See \cgalFigureRef{figgenregex} for an example).
|
||||||
|
|
||||||
\cgalFigureBegin{figgenregex,gen-reg-ex.png}
|
\cgalFigureBegin{figgenregex,gen-reg-ex.png}
|
||||||
Comparison of general and regularized alpha-shape. <B>Left:</B> Some points are taken on the surface of a torus, three points being taken relatively far from the surface of the torus; <B>Middle:</B> The general alpha-shape (for a large enough alpha value) contains the singular triangle facet of the three isolated points; <B>Right:</B> The regularized version (for the same value of alpha) does not contains any singular facet.
|
Comparison of general and regularized alpha-shape. <B>Left:</B> Some points are taken on the surface of a torus, three points being taken relatively far from the surface of the torus; <B>Middle:</B> The general alpha-shape (for a large enough alpha value) contains the singular triangle facet of the three isolated points; <B>Right:</B> The regularized version (for the same value of alpha) does not contain any singular facet.
|
||||||
\cgalFigureEnd
|
\cgalFigureEnd
|
||||||
|
|
||||||
The alpha shapes of a set of points
|
The alpha shapes of a set of points
|
||||||
|
|
@ -112,11 +112,11 @@ and radii \f$ r_1, r_2 \f$ are said to be orthogonal iff
|
||||||
iff \f$ C_1C_2 ^2 < r_1^2 + r_2^2\f$.
|
iff \f$ C_1C_2 ^2 < r_1^2 + r_2^2\f$.
|
||||||
For a given value of \f$ \alpha\f$,
|
For a given value of \f$ \alpha\f$,
|
||||||
the weighted alpha complex is formed with the simplices of the
|
the weighted alpha complex is formed with the simplices of the
|
||||||
regular triangulation triangulation
|
regular triangulation such that there is a sphere
|
||||||
such that there is a sphere orthogonal to the weighted points associated
|
orthogonal to the weighted points associated
|
||||||
with the vertices of the simplex and suborthogonal to all the other
|
with the vertices of the simplex and suborthogonal to all the other
|
||||||
input weighted points. Once again the alpha shape is then defined as
|
input weighted points. Once again the alpha shape is then defined as
|
||||||
the domain covered by a the alpha complex and comes in general and
|
the domain covered by the alpha complex and comes in general and
|
||||||
regularized versions.
|
regularized versions.
|
||||||
|
|
||||||
\section Alpha_Shape_3Functionality Functionality
|
\section Alpha_Shape_3Functionality Functionality
|
||||||
|
|
@ -273,7 +273,7 @@ alpha-shape, using the `Alpha_shape_3<Dt,ExactAlphaComparisonTag>` requires a ke
|
||||||
with exact predicates and exact constructions (or setting `ExactAlphaComparisonTag` to `Tag_true`)
|
with exact predicates and exact constructions (or setting `ExactAlphaComparisonTag` to `Tag_true`)
|
||||||
while using a kernel with exact predicates is sufficient for the class `Fixed_alpha_shape_3<Dt>`.
|
while using a kernel with exact predicates is sufficient for the class `Fixed_alpha_shape_3<Dt>`.
|
||||||
This makes the class `Fixed_alpha_shape_3<Dt>` even more efficient in this setting.
|
This makes the class `Fixed_alpha_shape_3<Dt>` even more efficient in this setting.
|
||||||
In addition, note that the `Fixed` version is the only of the
|
In addition, note that the `Fixed` version is the only one of the
|
||||||
two that supports incremental insertion and removal of points.
|
two that supports incremental insertion and removal of points.
|
||||||
|
|
||||||
We give the time spent while computing the alpha shape of a protein (considered
|
We give the time spent while computing the alpha shape of a protein (considered
|
||||||
|
|
@ -345,7 +345,7 @@ cube will be chosen and no optimizations will be used.
|
||||||
It is also recommended to switch the triangulation to 1-sheeted
|
It is also recommended to switch the triangulation to 1-sheeted
|
||||||
covering if possible. Note that a periodic triangulation in 27-sheeted
|
covering if possible. Note that a periodic triangulation in 27-sheeted
|
||||||
covering space is degenerate. In this case, an exact constructions
|
covering space is degenerate. In this case, an exact constructions
|
||||||
kernel needs to be used to compute the alpha shapes. Otherwise the
|
kernel needs to be used to compute the alpha shapes. Otherwise, the
|
||||||
results will suffer from round-off problems.
|
results will suffer from round-off problems.
|
||||||
|
|
||||||
\cgalExample{Alpha_shapes_3/ex_periodic_alpha_shapes_3.cpp}
|
\cgalExample{Alpha_shapes_3/ex_periodic_alpha_shapes_3.cpp}
|
||||||
|
|
|
||||||
|
|
@ -264,7 +264,7 @@ Secondly, the farther the isosurface is from the input, the more new points are
|
||||||
through the first criterion (i.e., through intersection with dual Voronoi edge, see Section \ref aw3_algorithm);
|
through the first criterion (i.e., through intersection with dual Voronoi edge, see Section \ref aw3_algorithm);
|
||||||
thus, the quality of the output improves in terms of angles of the triangle elements.
|
thus, the quality of the output improves in terms of angles of the triangle elements.
|
||||||
Finally, and depending on the value of the alpha parameter, a large offset can also offer defeaturing capabilities.
|
Finally, and depending on the value of the alpha parameter, a large offset can also offer defeaturing capabilities.
|
||||||
However using a small offset parameter will tend to better preserve sharp features as projection
|
However, using a small offset parameter will tend to better preserve sharp features as projection
|
||||||
Steiner points tend to project onto convex sharp features.
|
Steiner points tend to project onto convex sharp features.
|
||||||
|
|
||||||
\cgalFigureAnchor{6}
|
\cgalFigureAnchor{6}
|
||||||
|
|
@ -278,7 +278,7 @@ Impact of the offset parameter on the output.
|
||||||
The offset parameter is decreasing from left to right, to respectively 1/50, 1/200 and 1/1000 of the longest diagonal of the input bounding box.
|
The offset parameter is decreasing from left to right, to respectively 1/50, 1/200 and 1/1000 of the longest diagonal of the input bounding box.
|
||||||
The alpha parameter is equal to 1/50 of the longest diagonal of the input bounding box for all level of details.
|
The alpha parameter is equal to 1/50 of the longest diagonal of the input bounding box for all level of details.
|
||||||
A larger offset will produce an output less complex with better triangle quality.
|
A larger offset will produce an output less complex with better triangle quality.
|
||||||
However the sharp features (red edges) are well preserved when the offset parameter is small.
|
However, the sharp features (red edges) are well-preserved when the offset parameter is small.
|
||||||
\cgalFigureCaptionEnd
|
\cgalFigureCaptionEnd
|
||||||
|
|
||||||
\cgalFigureAnchor{7}
|
\cgalFigureAnchor{7}
|
||||||
|
|
@ -346,15 +346,15 @@ The charts below plots the computation times of the wrapping algorithm on the Th
|
||||||
\cgalFigureCaptionBegin{9}
|
\cgalFigureCaptionBegin{9}
|
||||||
Execution times and output complexity for different values of alpha on the Thingi10k data set.
|
Execution times and output complexity for different values of alpha on the Thingi10k data set.
|
||||||
Alpha increases from 1/20 to 1/200 of the length of bounding box diagonal.
|
Alpha increases from 1/20 to 1/200 of the length of bounding box diagonal.
|
||||||
The x axis represents the complexity of the output wrap mesh in number of triangle facets.
|
The x-axis represents the complexity of the output wrap mesh in number of triangle facets.
|
||||||
The y axis represents the total computation time, in seconds.
|
The y-axis represents the total computation time, in seconds.
|
||||||
The color and diameter of the dots represent the number of faces in the input triangle soup,
|
The color and diameter of the dots represent the number of faces in the input triangle soup,
|
||||||
ranging from 10 (green) to 3154000 (blue).
|
ranging from 10 (green) to 3154000 (blue).
|
||||||
\cgalFigureCaptionEnd
|
\cgalFigureCaptionEnd
|
||||||
|
|
||||||
\section aw3_examples Examples
|
\section aw3_examples Examples
|
||||||
|
|
||||||
Here is an example with an input triangle mesh, with alpha set to 1/20 of the bounding box longest diagonal edge length,
|
Here is an example with an input triangle mesh, with alpha set to 1/20 of the bounding box's longest diagonal edge length,
|
||||||
and offset set to 1/30 of alpha (i.e., 1/600 of the bounding box diagonal edge length).
|
and offset set to 1/30 of alpha (i.e., 1/600 of the bounding box diagonal edge length).
|
||||||
|
|
||||||
\cgalExample{Alpha_wrap_3/triangle_mesh_wrap.cpp}
|
\cgalExample{Alpha_wrap_3/triangle_mesh_wrap.cpp}
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue