|
Geometry : |
Subject: Re: [geometry] vtk output beta ready for polygon, ring and multi_polygon
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2013-05-22 05:11:33
Hi Tomislav,
Good point, I hadn't realized you were merely using the existing
multipolygon concept. I think it makes sense. Moving forward we should also
propose validation functions to check it's actually is a polyhedron (as a
polygon soup can be anything) but this can be done later.
Implementing the Separating Axis Collision test is one of the first thing I
wanted to do when started to handle real £D stuff so I'm glad you're
looking into this. The algorithm indeed relies on the polyhedron being
convex. Which essentially means that our concepts are going to need a way
to express that (i.e. to say "I am convex" so optimal algorithms like this
one can be selected). Long ago I simply thought there would be a Polyheron
and a ConvexPolyhedron concept but things are much more complicated that
there are tons of ways to represent polyhedrons (not just the ones you
described), all valid in some situations. I can see 2 solutions:
- ConvexPolyhedron could be a concept on its own, which a model can fulfill
in addition to another one (e.g. it can be a AdjacencyGraph and a
ConvexPolyhedron) - however this require changes to our current design I
think.
- We could have a is_convex<Geometry> metafunction that algorithms would
call when they're interested in whether a geometry is convex (could be used
also with polygon and plenty other stuff - could be hardcoded to true for
concepts like box).
So all in all, starting with your P1 is a valid approach. It terms of the
IO stuff you've written it looks right since the format seems to be
representing exactly that (a set of polygons without any strong guarantee
about their spatial disposition). And you can try to work on other
algorithms with this concept as well to see what it gives.
Regards
Bruno
Geometry list run by mateusz at loskot.net