CGAL users discussion list

[Philipp Moeller <>]

Jeffrey Bush 
<>
 writes:

> Hi,

Hi,

thanks for contributing.

>
>
> I noticed that they is no Polygon_3 class currently. I needed one to help
> represent the cross-section of a mesh with a plane. I modeled it after
> Polygon_2 (in the idea that most properties are not cached). It has many
> functions from Polygon_2 exception some of the orientation functions which
> would be ambiguous for outside polygon on same plane or off plane and
> removal of top/left/right/bottom since they are less useful in 3D. I
> added plane() and to_2d() and which retrieve the plane of the polygon and
> the 2D projection of the polygon onto that plane. The plane and 2D
> projection are cached. Whenever points are added/changed they are checked
> to make sure they are coplanar.

I'm wondering why this can't be achieved with Projection_traits? It
generally seems useful.

On the other hand, there are a lot of other things that are missing from
Polygon. It should be possible to just use a standard container as a
polygon, the basic polygon should support holes and edges shouldn't be
limited to segments. That way we could also make things more consistent
with Boolean_set_operation_2.

I don't know if we want to include extensions right away or if we want
to think over what to do with Polygon first.

>
>
> I would love to see this class integrated into CGAL. I have attached the
> necessary source files. They would need to be checked by someone for
> robustness, changed to your coding style (which I tried to follow for main
> things), and have the #include "..." changed to #include <...>.
>
> Additionally I found some fixes for the Polygon_2 code. The
> Polygon_2_edge_circulator has no operator->. This operator can be copied
> from Polygon_2_edge_iterator. Additionally there is a function at the end
> of each of Polygon_2_edge_iterator and Polygon_2_edge_circulator document
> that is commented out because someone didn't know how to implement. The
> solution is to just uncomment it add the keyword "typename" in the first
> parameter (e.g. "operator+(typename _Container::difference_type n, ").

That's not as easy as one would think. operator+ is only available on
the container type and it should be protected by enable_if on the
iterator_category.

> One last thing is that Polygon_2_edge_iterator contains
> a Polygon_2__Segment_ptr class. This is not specific to either of those
> except that it is only used for those. I suggest either making a global
> pointer class that can be used for the operator-> functions or to include
> the Segment_ptr as a nested class in the necessary classes.

It is not really clear to me if this is the right way to implement
iterators that generate values. A better approach seems to me to store
the value inside the iterator and hand out a reference to it.