CGAL::Voronoi_diagram_2 rounding to integers incorrectly - c++

I am attempting to create a Voronoi diagram from line segments with the following code.
#include <iostream>
#include <CGAL/Exact_predicates_inexact_constructions_kernel.h>
#include <CGAL/Segment_Delaunay_graph_Linf_filtered_traits_2.h>
#include <CGAL/Segment_Delaunay_graph_Linf_2.h>
#include <CGAL/Voronoi_diagram_2.h>
#include <CGAL/Segment_Delaunay_graph_adaptation_traits_2.h>
#include <CGAL/Segment_Delaunay_graph_adaptation_policies_2.h>
using Traits=CGAL::Segment_Delaunay_graph_Linf_filtered_traits_2<CGAL::Exact_predicates_inexact_constructions_kernel>;
using DelaunayGraph=CGAL::Segment_Delaunay_graph_Linf_2<Traits>;
using AdaptationTraits=CGAL::Segment_Delaunay_graph_adaptation_traits_2<DelaunayGraph>;
using AdaptationPolicy=CGAL::Segment_Delaunay_graph_degeneracy_removal_policy_2<DelaunayGraph>;
using VoronoiDiagram=CGAL::Voronoi_diagram_2<DelaunayGraph,AdaptationTraits,AdaptationPolicy>;
using VoronoiSite=AdaptationTraits::Site_2;
using VoronoiPoint=VoronoiSite::Point_2;
int main(int argc, char** argv)
{
VoronoiDiagram vd;
VoronoiPoint pt0(0.0, 0.0), pt1(5.0, 0.0), pt2(2.0, 2.0), pt3(4.0, 4.0);
vd.insert(VoronoiSite::construct_site_2(pt0, pt1));
vd.insert(VoronoiSite::construct_site_2(pt2, pt3));
int c = 0;
for (auto it = vd.edges_begin(); it != vd.edges_end(); it++)
{
std::cout << "Edge #" << c++ << std::endl;
if (it->has_source())
std::cout << "\t" << it->source()->point();
else
std::cout << "\tInfinity";
std::cout << std::endl;
if (it->has_target())
std::cout << "\t" << it->target()->point();
else
std::cout << "\tInfinity";
std::cout << std::endl;
}
return 0;
}
The output starts with
Edge #0
0 2
Infinity
Edge #1
6 2
Infinity
Edge #2
5 1.66667
Infinity
...
This is my custom visualization of what it looks like.
I expect Edge #1 to be the edge that is equidistant to (4, 4) and (5, 0), however the point (6, 2) is NOT equidistant to those two points. I expect that point to be roughly (5.7, 2.3).
Based on edge 2, I know that ALL the numbers are not integers, but it seems like some of them are being rounded or something. To be clear, I very likely lack some very basic CGAL/Kernel knowledge. I tried swapping in the Cartesian<double> kernel, but that did not change the result.

To follow up on Marc's comment, I needed to change the definitions at the top. The result that works is
#include <iostream>
#include <CGAL/Simple_cartesian.h>
#include <CGAL/Segment_Delaunay_graph_filtered_traits_2.h>
#include <CGAL/Segment_Delaunay_graph_2.h>
#include <CGAL/Voronoi_diagram_2.h>
#include <CGAL/Segment_Delaunay_graph_adaptation_traits_2.h>
#include <CGAL/Segment_Delaunay_graph_adaptation_policies_2.h>
using CartesianKernel=CGAL::Simple_cartesian<double>;
using Traits=CGAL::Segment_Delaunay_graph_filtered_traits_2<CartesianKernel,CGAL::Field_with_sqrt_tag>;
using DelaunayGraph=CGAL::Segment_Delaunay_graph_2<Traits>;
using AdaptationTraits=CGAL::Segment_Delaunay_graph_adaptation_traits_2<DelaunayGraph>;
using AdaptationPolicy=CGAL::Segment_Delaunay_graph_degeneracy_removal_policy_2<DelaunayGraph>;
using VoronoiDiagram=CGAL::Voronoi_diagram_2<DelaunayGraph,AdaptationTraits,AdaptationPolicy>;
using VoronoiSite=AdaptationTraits::Site_2;
using VoronoiPoint=VoronoiSite::Point_2;

Related

How do you access the individual vertices inside of a pcl::PolygonMesh?

I'm currently using visual studio 2022
I'm using vcpkg pcl:x64 library install.
pcl version: 1.9.1-12
I'm expecting to be able to access 3 vertices per polygon.
Unfortunately, I can't seem to access the vertices associated with each triangle.
#include <Eigen/Dense>
#include <pcl/common/io.h>
#include <pcl/filters/extract_indices.h>
#include <pcl/filters/passthrough.h>
#include <pcl/point_cloud.h>
#include <pcl/point_types.h>
#include <pcl/PolygonMesh.h>
#include <pcl/TextureMesh.h>
int main
{
pcl::PolygonMesh mesh;
pcl::io::loadPolygonFileOBJ("pathtomesh.meshfile.obj", mesh);
pcl::PointXYZ v = mesh.polygons[0].vertices[0];
}
the error i recieve is:
no suitable constructor exists to convert from "boost::random::seed_seq::result_type" to "pcl::PointXYZ"
It seems as though vertices is an unsigned int and not a pcl::PointXYZ. This is kinda weird to me because I was expecting a double or a floating point to store the vertices coordinates. It turns out that mesh.polygons[0].vertices[0] returns the indices of each point in the mesh that are stored in the point cloud. So i was able to find the points that the function mesh.polygons[0].vertices[0] were pointing at by using converting the mesh to a pcl::PointCloudpcl::PointXYZ and putting the indexes into that function.
pcl::PolygonMesh mesh;
pcl::io::loadPolygonFileOBJ("D:\\testOBJs\\cube.obj", mesh);
pcl::PointCloud<pcl::PointXYZ>::Ptr allVertices(new pcl::PointCloud<pcl::PointXYZ>);
pcl::fromPCLPointCloud2(mesh.cloud, *allVertices);
std::cout << "All Vertices" << std::endl;
for (int i = 0; i < allVertices->size(); i++)
{
std::cout << std::to_string(i) + " " << allVertices->points[i] << std::endl;
}
std::cout << "All Polygons" << std::endl;
for (int i = 0; i < mesh.polygons.size(); i++)
{
std::cout << std::endl;
std::cout << mesh.polygons[i].vertices[0] << std::endl;
std::cout << mesh.polygons[i].vertices[1] << std::endl;
std::cout << mesh.polygons[i].vertices[2] << std::endl;
std::cout << std::endl;
}

Cgal - Point_set_3 object, functions fails to process?

Currently trying to build upon the surface reconstruction tutorial and noticed a potential major issue in the tutorial which, in my experience do generalised outside of it:
In the following tutorial: https://doc.cgal.org/latest/Manual/tuto_reconstruction.html (cgal 5.3), the author do some pre-processing before going into the mesh reconstruction, stuffs like outlier_removal, grid_simplify etc.
However I noticed that no points are being removed during these steps. So I tried multiple parameters in the outlier_removal/grid_simplify and still, everytime, no points gets removed.
However when working with a vector of point instead of a Point_set_3 object, I do manage to get points removed with the same parameters.
Am I the only one who is unable to remove a point with outlier_removal/grid_simplify on a Point_set_3 object?
If yes, can you show me an example how to make it work?
If no, should I avoid using Point_set_3 objects? Or should I convert into a std::vector before doing the pre-processing steps? And how so?
Issue Details
The code runs fine. No errors.
Source Code
This code subset comes straight out of the tutorial.
https://doc.cgal.org/latest/Manual/tuto_reconstruction.html
#include <CGAL/Exact_predicates_inexact_constructions_kernel.h>
#include <CGAL/Point_set_3.h>
#include <CGAL/Point_set_3/IO.h>
#include <CGAL/remove_outliers.h>
#include <CGAL/grid_simplify_point_set.h>
#include <CGAL/jet_smooth_point_set.h>
#include <CGAL/jet_estimate_normals.h>
#include <CGAL/mst_orient_normals.h>
#include <CGAL/poisson_surface_reconstruction.h>
#include <CGAL/Advancing_front_surface_reconstruction.h>
#include <CGAL/Scale_space_surface_reconstruction_3.h>
#include <CGAL/Scale_space_reconstruction_3/Jet_smoother.h>
#include <CGAL/Scale_space_reconstruction_3/Advancing_front_mesher.h>
#include <CGAL/Surface_mesh.h>
#include <CGAL/Polygon_mesh_processing/polygon_soup_to_polygon_mesh.h>
#include <cstdlib>
#include <vector>
#include <fstream>
// types
typedef CGAL::Exact_predicates_inexact_constructions_kernel Kernel;
typedef Kernel::FT FT;
typedef Kernel::Point_3 Point_3;
typedef Kernel::Vector_3 Vector_3;
typedef Kernel::Sphere_3 Sphere_3;
typedef CGAL::Point_set_3<Point_3, Vector_3> Point_set;
int main(int argc, char*argv[])
{
Point_set points;
if (argc < 2)
{
std::cerr << "Usage: " << argv[0] << " [input.xyz/off/ply/las]" << std::endl;
return EXIT_FAILURE;
}
const char* input_file = argv[1];
std::ifstream stream (input_file, std::ios_base::binary);
if (!stream)
{
std::cerr << "Error: cannot read file " << input_file << std::endl;
return EXIT_FAILURE;
}
stream >> points;
std::cout << "Read " << points.size () << " point(s)" << std::endl;
if (points.empty())
return EXIT_FAILURE;
CGAL::remove_outliers<CGAL::Sequential_tag>
(points,
24, // Number of neighbors considered for evaluation
points.parameters().threshold_percent (5.0)); // Percentage of points to remove
std::cout << points.number_of_removed_points()
<< " point(s) are outliers." << std::endl;
// Applying point set processing algorithm to a CGAL::Point_set_3
// object does not erase the points from memory but place them in
// the garbage of the object: memory can be freeed by the user.
points.collect_garbage();
// Compute average spacing using neighborhood of 6 points
double spacing = CGAL::compute_average_spacing<CGAL::Sequential_tag> (points, 6);
// Simplify using a grid of size 2 * average spacing
CGAL::grid_simplify_point_set (points, 2. * spacing);
std::cout << points.number_of_removed_points()
<< " point(s) removed after simplification." << std::endl;
points.collect_garbage();
CGAL::jet_smooth_point_set<CGAL::Sequential_tag> (points, 24);
unsigned int reconstruction_choice
= (argc < 3 ? 0 : atoi(argv[2]));
if (reconstruction_choice == 0) // Poisson
{
CGAL::jet_estimate_normals<CGAL::Sequential_tag>
(points, 24); // Use 24 neighbors
// Orientation of normals, returns iterator to first unoriented point
typename Point_set::iterator unoriented_points_begin =
CGAL::mst_orient_normals(points, 24); // Use 24 neighbors
points.remove (unoriented_points_begin, points.end());
return EXIT_SUCCESS;
}
Environment
I've replicated that issue in a debian VM as well as in a docker environment in macos (debian based as well).
Pretty standard stuffs, I'm using the CMakeLists.txt already available in the tutorial_example.cpp folder and running:
Creates files that will show the compiler how to behave
cmake -DCGAL_DIR=/app/cgal -DCMAKE_BUILD_TYPE=Release .
Build the exe
make
I'm a self taught Python programmer so quite new to the C++ stuffs.

Operating on slices of Cube in armadillo

I am trying to get used to armadillo linear algebra library for c++ and I cannot figure out hot to operate on slices(matrices) of a cube. Whenever I try to operate on a slice, the program compiles but does not give any output, not even the outputs of statement before the slice operation.
Here's the code:
#include <armadillo>
#include <iostream>
using namespace arma;
using namespace std;
int main()
{
Cube<double> A(3 , 5 ,1, fill::randu);
Cube<double>B(5,3,1,fill::randu);
Mat<double>x =A.slice(0);
Mat<double>y = B.slice(0);
cout << x << "\n" << y << endl;
cout << x*y << endl; //code works fine if this line is removed
}
the problem is that the code works fine if the last line is removed. Why does this happen? Is there a better way to operate on matrices inside a cube ?
Use directions given in the accepted answer to this question, to install Armadillo on Windows using Visual Studio.
If you have asked the Linker to use blas_win64_MT.lib and lapack_win64_MT.lib libraries, make sure to add the respective .dll's in the same directory as your .exe file. Then using this code, I get the desired output.
#include <armadillo>
#include <iostream>
using namespace std;
using namespace arma;
int main()
{
Cube<double> A(3, 5, 1, fill::randu);
Cube<double> B(5, 3, 1, fill::randu);
Mat<double> x = A.slice(0);
Mat<double> y = B.slice(0);
std::cout << "x:\n" << x << "\ny:\n" << y << std::endl;
std::cout << "x*y:\n" << x*y << std::endl;
}
Output in command window:
Hope that helps!

How to compare if two tensors are equal in Eigen?

There is this:
https://codeyarns.com/2016/02/16/how-to-compare-eigen-matrices-for-equality/
But there is no isApprox for tensors.
The following doesn't do what I want:
#include <Eigen/Core>
#include <unsupported/Eigen/CXX11/Tensor>
#include <array>
#include <iostream>
using namespace Eigen;
using namespace std;
int main()
{
// Create 2 matrices using tensors of rank 2
Eigen::Tensor<int, 2> a(2, 3);
Eigen::Tensor<int, 2>* b = &a;
cerr<<(*b==*b)<<endl;
}
because it does coordinate wise comparison and returns a tensor of the same dimension instead of a true/false vale.
How do I check if two tensors are identical? No isApprox for tensors.
I could write my own function, but I want to be able to use GPU power when available, and it seems like Eigen has built-in GPU support.
For an exact comparison of 2 tensors A and B, you can use the comparison operator followed by a boolean reduction:
Tensor<bool, 0> eq = (A==B).all();
This will return a tensor of rank 0 (i.e. a scalar) that contains a boolean value that's true iff each coefficient of A is equal to the corresponding coefficient of B.
There is no approximate comparison at the moment, although it wouldn't be difficult to add.
You can always use a couple of Eigen::Maps to do the isApprox checks.
#include <iostream>
#include <unsupported/Eigen/CXX11/Tensor>
using namespace Eigen;
int main()
{
Tensor<double, 3> t(2, 3, 4);
Tensor<double, 3> r(2, 3, 4);
t.setConstant(2.1);
r.setConstant(2.1);
t(1, 2, 3) = 2.2;
std::cout << "Size: " << r.size() << "\n";
std::cout << "t: " << t << "\n";
std::cout << "r: " << r << "\n";
Map<VectorXd> mt(t.data(), t.size());
Map<VectorXd> mr(r.data(), r.size());
std::cout << "Default isApprox: " << mt.isApprox(mr) << "\n";
std::cout << "Coarse isApprox: " << mt.isApprox(mr, 0.11) << "\n";
return 0;
}
P.S./N.B. Regarding Eigen's built in GPU support... Last I checked it is fairly limited and with good reason. It is/was limited to fixed size matrices as dynamic allocation on a GPU is really something you want to avoid like the common cold (if not like the plague). I take it back. It looks like the Tensor module supports GPUs pretty well.

Boost Polygon: Issue with euclidean_distance

I have the following code which is supposed to compute the Euclidean distance between two rectangles. I compiled using GCC 4.7.3 and Boost v1.58.0
#include <iostream>
#include <cmath>
#include <boost/polygon/polygon.hpp>
#include <boost/geometry.hpp>
namespace gtl = boost::polygon;
using namespace boost::polygon::operators;
typedef gtl::rectangle_data<int> LayoutRectangle;
int main(int argc, char** argv)
{
LayoutRectangle t(16740130,29759232,16740350,29760652);
LayoutRectangle n(16808130,29980632,16808350,29982052);
std::cout << gtl::euclidean_distance(t, n) << std::endl;
std::cout << gtl::euclidean_distance(t, n, gtl::HORIZONTAL) << " "
<< gtl::euclidean_distance(t, n, gtl::VERTICAL) << std::endl;
std::cout << gtl::square_euclidean_distance(t, n) << std::endl;
std::cout << std::sqrt(gtl::square_euclidean_distance(t, n)) << std::endl;
std::cout << (int) std::sqrt(gtl::square_euclidean_distance(t, n)) << std::endl;
return 0;
}
The code above produced the following output:
38022.6
67780 219980
52985328800
230185
230185
The correct answer is 230185. Now if I go look at the implementation of euclidean_distance() in the boost polygon library, I see this:
template <typename rectangle_type, typename rectangle_type_2>
typename enable_if< typename gtl_and_3<y_r_edist2, typename is_rectangle_concept<typename geometry_concept<rectangle_type>::type>::type,
typename is_rectangle_concept<typename geometry_concept<rectangle_type_2>::type>::type>::type,
typename rectangle_distance_type<rectangle_type>::type>::type
euclidean_distance(const rectangle_type& lvalue, const rectangle_type_2& rvalue) {
double val = (int)square_euclidean_distance(lvalue, rvalue);
return std::sqrt(val);
}
This looks identical to the std::sqrt(gtl::square_eclidean_distance(t,n)) line in my code which gives the correct answer (230185). So why am I getting 38022.6 with gtl::euclidean_distance()? What am I not seeing here?
Looks like the internal computation is overflowing.
I don't think this is a library bug, the library is used incorrectly with the underlying (unchecked) int type.
(However, there is a different bug in the library that I mention at the end.)
Try using a smaller "integer representation" of the problem:
For example:
LayoutRectangle t(167402,297592,167404,297607);
LayoutRectangle n(168082,299806,168084,299821);
Unfortunately there is no general solution of the problem in integer arithmetic, except 0) using higher precision can buy you something, 1) scaling the problem 2) using multiprecision, 3) using rational arithmetic and integer part
(For floating point the solution is simply normalizing the components, this is how std::abs for std::complex<double> works to avoid floating point overflow)
It is good to use large integers to represent a geometric problem BUT
for this reason, as a workaround, use coordinates that span distance of at most (int)std::sqrt((double)std::numeric_limits<int>::max()/2) = 2^15 = 32768.
Which is a surprisingly small number.
Complete code:
#include <iostream>
#include <cmath>
#include <boost/polygon/polygon.hpp>
#include <boost/geometry.hpp>
int main(){
namespace gtl = boost::polygon;
using namespace boost::polygon::operators;
typedef gtl::rectangle_data<int> LayoutRectangle;
LayoutRectangle t(167401,297592,167403,297606);
LayoutRectangle n(168081,299806,168083,299820);
std::cout << gtl::euclidean_distance(t, n) << std::endl;
std::cout << gtl::euclidean_distance(t, n, gtl::HORIZONTAL) << " "
<< gtl::euclidean_distance(t, n, gtl::VERTICAL) << std::endl;
std::cout << gtl::square_euclidean_distance(t, n) << std::endl;
std::cout << std::sqrt(gtl::square_euclidean_distance(t, n)) << std::endl;
std::cout << (int) std::sqrt(gtl::square_euclidean_distance(t, n)) << std::endl;
}
Output:
2302.1
678 2200
5299684
2302.1
2302
Which is the expected result.
Looking at the code, it seems that there is a bug in the library, not because it gives overflow but because an internal computation is casted to int and not the the underlying generic integer data type. This means that probably even if you use multiprecision integers the results will overflow.