Subject: CGAL users discussion list
List archive
- From: Jeffrey Bush <>
- To: Philipp Moeller <>
- Cc: "" <>
- Subject: Re: [cgal-discuss] Polygon_3
- Date: Fri, 8 Feb 2013 11:10:21 -0800
All good points. It is completely up to you guys to do what you want.
The only projection traits I know of are the xy, xz, yz ones so don't allow for arbitrary planes. However I found an example with Projection_traits<AABBTraits> which would apply to me (I am trying to take the intersection of a mesh and a plane) but I have no idea how to use it for this.
Jeff
On Fri, Feb 8, 2013 at 1:34 AM, Philipp Moeller <> wrote:
Jeffrey Bush <> writes:
> Hi,
Hi,
thanks for contributing.
I'm wondering why this can't be achieved with Projection_traits? It
>
>
> 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.
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.
That's not as easy as one would think. operator+ is only available on
>
>
> 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, ").
the container type and it should be protected by enable_if on the
iterator_category.
It is not really clear to me if this is the right way to implement
> 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.
iterators that generate values. A better approach seems to me to store
the value inside the iterator and hand out a reference to it.
- [cgal-discuss] Polygon_3, Jeffrey Bush, 02/07/2013
- Re: [cgal-discuss] Polygon_3, Sebastien Loriot (GeometryFactory), 02/08/2013
- Re: [cgal-discuss] Polygon_3, Philipp Moeller, 02/08/2013
- Re: [cgal-discuss] Polygon_3, Jeffrey Bush, 02/08/2013
Archive powered by MHonArc 2.6.18.