There is a new `Mesher_level` package, that gathers the foundation
files (mesher levels and auxiliary files) for `Mesh_2`,
`Surface_mesher`, and `Mesh_3`.
For the moment, the manifold feature is no longer working.
Merge remote-tracking branch 'cgal-dev/Mesh_3-manifold_criterion-lrineau' into Mesh_3-manifold_criterion-lrineau
Conflicts:
Mesh_3/include/CGAL/Mesh_3/Mesh_complex_3_in_triangulation_3_base.h
Mesh_3/include/CGAL/Mesh_3/Mesher_3.h
Mesh_3/include/CGAL/Mesh_3/Refine_facets_3.h
Polyhedron/demo/Polyhedron/Polyhedron_3.cpp
Polyhedron/demo/Polyhedron/Polyhedron_demo_mesh_3_plugin.cpp
Polyhedron/demo/Polyhedron/Polyhedron_demo_mesh_3_plugin_cgal_code.cpp
This macro has to be larger than the default value
and it must be set before including <boost/parameter.hpp>
Instead of setting it to 12 in the packages that
need it, we do this in <CGAL/config.h> and produce
an error if a user has set it to a value < 12
+ add code to interpolate on finite vertices of an infinite face
they are not used by default because it's expensive, unless the macro
CGAL_MESH_2_SIZING_FIELD_USE_BARYCENTRIC_COORDINATES is defined.
Can be useful to be more precise about the sizing
to do so, use the Dispatch_output_iterator
- Constrained Voronoi diagram is now a class that has a pointer to a CDT
as member. We don't need an extra CDT anymore
- update examples
- also update the CDT 2 demo to see Voronoi cells, that are only valid when the
triangulation is Delaunay (constrained or not)
The Intel Compiler 14.0, with -O2 or -O3, triggers a bug in the old
version of the code. After the construction of the filtered circulator,
`test(*this)` was not guaranteed. I am not sure if the bug is in the
code or in the compiler, but the constructor was an ugly piece of
code! (*this) was used in the body of the constructor in non obvious
ways. An object is reputed constructed once the internalizers are
evaluated, as far as I know, so probably the previous version of the
code was valid. However, that sound strange to copy an object inside the
body of the constructor of that object. Maybe that confused the
compiler.
Anyway, I have modified the implementation of that constructor in a
cleaner way, and I have added an assertion (that was failing with the
old implementation).
Before, we were using the Mesher_level.h file of the Mesh_2 package,
but the parallel version introduced some changes and a
dependency from Mesh_2 to Mesh_3 that is not wished.
I restored the original Mesher_level.h file in Mesh_2.
Now, we add points on a far spheres by default in the parallel version, but not in the sequential version. So, two macros: CGAL_SEQUENTIAL_MESH_3_ADD_OUTSIDE_POINTS_ON_A_FAR_SPHERE and CGAL_PARALLEL_MESH_3_DO_NOT_ADD_OUTSIDE_POINTS_ON_A_FAR_SPHERE.
There is just one grid lock data structure class now, with several specialization.
Moreover, now the type of the lock data structure is only defined in the triangulation.
Added a better support for parallelism in Triangulation_3.
Simplified how to enable/disable concurrency in Mesh_3.
Moved the Compact_container stategies to a new file.
+ some bugfixes (most of them are related to the parallel version)
This version works (sequential and parallel) as long as the following macros are NOT defined:
* CGAL_COMPACT_MESH_VERTEX_CELL
* CGAL_INTRUSIVE_LIST
* FORCE_STRUCTURAL_FILTERING
I found out that way that <CGAL/Mesh_3/Refine_facets.h> and
<CGAL/Mesh_3/Protect_edges_sizing_field> were using global functions
instead of functors of the traits class.
Note also the funny bug that <CGAL/Regular_triangulation_cell_base_3.h> was
depending on <CGAL/Triangulation_vertex_base_3.h>!
That feature can be enabled with g++, clang++, and icpc (intel). It could
be implemented for MSVC, with the flag /Zs, but that is not yet done (and
probably will not).
The option is controlled by a CMake option, CGAL_ENABLE_CHECK_HEADERS, that
is disabled by default. If that option is enabled by the user, then CMake
will check if the compiler $CXX understand the syntax:
$CXX -x c++ -fsyntax-only CGAL/header.h
and send an error otherwise.
Then phony targets will be created:
- a target check_CGAL__header_h for each header <CGAL/header.h>,
- a target check_pkg_<pkg> for each package <pgk>,
- and a target check_headers for the whole CGAL.
Those new targets currently give a lot of compilation errors if
CGAL_ENABLE_CHECK_HEADERS is enabled!
+ fix several missing includes in Mesh_2.
-Wunused-local-typedefs is a new warning flag of gcc-4.7, and it will enabled
by -Wall since gcc-4.8 (not yet released).
The fix is a big set of removals of unused typedefs (or comments, or moves,
depending on the context).
Bug reported by a user against CGAL-4.0.2
A single triangle cannot be meshed!
The fault was a buggy assertion added in the following revision:
|-----------------------------------------------------------------------
|r66359 | lrineau | 2011-11-16 18:58:22 +0100 (Wed, 16 Nov 2011) | 3 lines
|
|Add an assertion that checks that a point constructed as the midpoint of an
|edge is located either on the edge or inside one of the two incident faces.
|
|-----------------------------------------------------------------------
And the assertion message was:
terminate called after throwing an instance of 'CGAL::Assertion_exception'
what(): CGAL ERROR: assertion violation!
Expr: zone.locate_type != Tr::FACE || zone.fh == f || zone.fh == n
File: /home/lrineau/wc/Mesh_2/test/Mesh_2/../../include/CGAL/Mesh_2/Refine_edges.h
Line: 430
Explanation: Your data set contains at least a vertex that is very close to
a constrained edge! Mesh_2 cannot mesh that sort of data set.
- New worksharing strategy, which groups tasks by batches and let TBB manage the load balancing => the results are slightly improved, compared to parallel_do
- New params in config file
- Function get_number_of_bad_elements in the mesher levels (for debugging)
- option CGAL_MESH_3_ADD_OUTSIDE_POINTS_ON_A_FAR_SPHERE to reduce contention on the infinite vertex
Anyway, now the refinement of the facets is parallel. The speedup is around 2-3 on a 12-core CPU. Can do better, but at least it shows it's not sequential.
The refinement of the cells is not parallel, yet.
One last thing: the program needs to be restarted between two refinements (should be fixed soon).
If one wants to use Mesh_2 with Triangulation_2_projection_traits_3 (a
projection traits constructed with a normal vector), one cannot use a
default constructed geom traits, but only one passed on argument. Then the
criteria class needs to be constructed with tr.geom_traits() as argument.
"New directory Mesh_2/include/CGAL/Meshes/ that aggregates several
non documented files that are common to Mesh_2, Mesh_3 and Surface_mesher."
I forgot to commit the removal of old files.
Boost.Bimap is a bit faster (150-190% faster), and less
memory-consumer. Whereas the old Double_map implementation does not seem to
be sensitive to caching effects, the Bimap implementation seems to be
faster when run twice or more.
See the measurements bellow. Three runs of ./bench_double_map.bimap and
./bench_double_map.cgal. They are both compiled with -O2, and
./bench_double_map.bimap is compiled with -DCGAL_USE_BOOST_BIMAP
-I<path_to_boost_bimap>.
lrineau@tsetse ~/CGAL/Packages/Mesh_2/test/Mesh_2 $ for in in 1 2 3; do
echo 'BIMAP';
./bench_double_map.bimap 200000 30;
echo 'OLD DOUBLE_MAP';
./bench_double_map.cgal 200000 30;
done
BIMAP
Total time: 4.41933
Time for 'insert': 3.15152
Time for 'pop_front': 1.26781
Resident memory: 14843904
Virtual memory: 26423296
OLD DOUBLE_MAP
Total time: 6.581
Time for 'insert': 4.5593
Time for 'pop_front': 2.0217
Resident memory: 18030592
Virtual memory: 29519872
BIMAP
Total time: 3.56746
Time for 'insert': 2.49262
Time for 'pop_front': 1.07484
Resident memory: 14843904
Virtual memory: 26427392
OLD DOUBLE_MAP
Total time: 6.76597
Time for 'insert': 4.70729
Time for 'pop_front': 2.05869
Resident memory: 18034688
Virtual memory: 29519872
BIMAP
Total time: 3.51347
Time for 'insert': 2.43964
Time for 'pop_front': 1.07383
Resident memory: 14856192
Virtual memory: 26427392
OLD DOUBLE_MAP
Total time: 6.74597
Time for 'insert': 4.6183
Time for 'pop_front': 2.12768
Resident memory: 17854464
Virtual memory: 29523968
The following (commented) line triggered the error:
direct_func[rit->second] = rit;
The new following line fixes the bug. Actually, it is even more
efficient.
direct_func.insert(std::make_pair(rit->second, rit));
- factorize code in Is_locally_conforming_Gabriel and
Is_locally_conforming_Delaunay.
- all triangulation references are now named "tr" (instead of "ct").
(Tests OK)
- CGAL_MESH_3_DIRTY_DEBUG_SPHERES,
- and CGAL_MESHES_DEBUG_REFINEMENT_POINTS.
- new macro CGAL_MESHES_OUTPUT_STREAM, which is set to std::cout by
default.
- in Mesh_2: new header <CGAL/Mesh_2/Output_stream.h>
- CGAL_MESH_3_DEBUG_INSERTION_RADIUS,
- CGAL_MESH_2_DEBUG_INSERTION_RADIUS,
- CGAL_MESHES_DEBUG_REFINEMENT_POINTS,
- and CGAL_MESH_3_DIRTY_DEBUG_SPHERES.
These are not activated by default, of course. The latter was to debug
test/Mesh_3/combined_spheres.cpp.
"cannot_wait_for_CGAL-3.2" to the trunk.
My idea: the branch is the real working version, and I want it to be joined
back to the trunk:
__________________________ cannot_wait_for_CGAL-3.2 branch
/ \
/ \
-------------------------------------------- trunk
S M
The modification of the trunk between the splitting point S and the merging
point M has already been merged into "cannot_wait_for_CGAL-3.2".
The trunk versions of these three packages have been removed already.
Do not worry: I will "svn cp" the branch "cannot_wait_for_CGAL-3.2" into the
trunk, and the trunk will inherit from the logs of the branch.
My idea: the branch is the real working version, and I want it to be joined
back to the trunk:
__________________________ cannot_wait_for_CGAL-3.2 branch
/ \
/ \
-------------------------------------------- trunk
S M
The modification of the trunk between the splitting point S and the merging
point M has already been merged into "cannot_wait_for_CGAL-3.2".
- rename test/Mesh_2/makefile to GNUmakefile, not submitted:
makefiles in the testsuite are generated.
- fix a BUG in Mesher_level: one_step() and try_to_insert_one_point(), in
Null_mesher_level must return false! This fix solves the "follow under
mouse" bug of mesh_demo.C!
- change some DEBUG macro names to:
CGAL_MESH_2_DEBUG_BAD_FACES
CGAL_MESH_2_DEBUG_CLUSTERS
CGAL_MESH_2_DEBUG_CONFLICTS_ZONE
CGAL_MESH_2_DEBUG_DRAW
CGAL_MESH_2_DEBUG_INSERTIONS
CGAL_MESH_2_VERBOSE
to please CGAL developer manual.
- add a seed in fish.poly
(Note to Andreas: this is the bug I was looking for. The added test file
helped me to find it cause.)
Sébastien Loriot
Andreas Fabri
Laurent Rineau
Simon Giraudot
Jane Tournois
Clement Jamin
Laurent Rineau
Sébastien Loriot
Stéphane Tayeb
Sylvain Pion
Laurent Saboret