Update documentation, for the 5th round submission.

This commit is contained in:
Ning Xu 2014-07-29 07:22:16 -04:00
parent a226815f9e
commit 4d75b68e75
4 changed files with 7 additions and 6 deletions

View File

@ -10,7 +10,7 @@ namespace CGAL {
\tparam Arrangement_2_ is the type used to represent the input environment.
It must be an instance of CGAL::Arrangement_2, where its CGAL::Arrangement_2::Traits_2 must be an instance of
CGAL::Arr_segment_traits_2.
CGAL::Arr_segment_traits_2, or of CGAL::Arr_non_caching_segment_traits_2.
\tparam RegularizationTag indicates whether the output should be regularized. It can be
specified by one of the following: ::Tag_true or ::Tag_false, where ::Tag_false is the default value.

View File

@ -17,7 +17,7 @@ is the number of the vertices of the polygon.
\tparam Arrangement_2_ is the type used to represent the input environment.
It must be an instance of CGAL::Arrangement_2, where its CGAL::Arrangement_2::Traits_2 must be an instance of
CGAL::Arr_segment_traits_2.
CGAL::Arr_segment_traits_2, or of CGAL::Arr_non_caching_segment_traits_2.
\tparam RegularizationTag indicates whether the output should be regularized. It can be
specified by one of the following: ::Tag_true or ::Tag_false, where ::Tag_false is the default value.

View File

@ -12,7 +12,7 @@ The query time is \f$ O(nh)\f$, where \f$ h \f$ is the number of holes+1 of inpu
\tparam Arrangement_2_ is the type used to represent the input environment.
It must be an instance of CGAL::Arrangement_2, where its CGAL::Arrangement_2::Traits_2 must be an instance of
CGAL::Arr_segment_traits_2.
CGAL::Arr_segment_traits_2, or of CGAL::Arr_non_caching_segment_traits_2.
\tparam RegularizationTag indicates whether the output should be regularized. It can be
specified by one of the following: ::Tag_true or ::Tag_false, where ::Tag_false is the default value.

View File

@ -71,7 +71,7 @@ However, this should be avoided as this also requires an update of the auxiliary
data structures in the attached object.
An actual query is then performed by giving the view point \f$ p \f$ and its containing face \f$ f \f$,
which must represent a valid \cgalFootnote{See the package \ref PkgBooleanSetOperations2Summary for the precise definition}
polygon (\f$ f \f$ has no isolated vertices and each boundary edge of \f$ f \f$ separates it from another face).
polygon. Namely, in the face \f$ f \f$, there is no isolated vertex, and any edge of the face separates \f$ f \f$ with another face.
For this purpose every model of the Visibility_2 concept provides two overloaded member functions, called `Visibility_2::compute_visibility()`
, that compute the visibility region of \f$ p \f$ in a bounded polygonal face \f$ f \f$: one is for the case where
\f$ p \f$ is in the interior of \f$ f \f$; the other one is for the case where \f$ p \f$ is on the boundary of \f$ f \f$.
@ -116,8 +116,9 @@ Complete Cathedral | total preprocessing time | total query time
Thus, in general we recommend to use `Triangular_expansion_visibility_2` even if the polygon is simple. The main advantage
of the algorithm is its locality. After the triangle that contains the query point is located in the triangulation,
the algorithm explores neighboring triangles, but only those that are actually seen. In this sense the algorithm can be
considered as output sensitive. However, if the simple polygon is rather convex (i.e., nearly all boundary is seen) or
the algorithm explores neighboring triangles, but only those that are actually seen.In this sense the algorithm can be considered as output sensitive.
Note that the `Triangular_expansion_visibility_2` algorithm performs better on the full cathedral by the fact that the additional pillars block the view early in many cases.
However, if the simple polygon is rather convex (i.e., nearly all boundary is seen) or
if only one (or very little) queries are required, using one of the algorithms that does not require preprocessing is advantageous.