When applying crop hull on a 3D concave hull, I get missing points and extra points in the filtered result.
Context
I am using a sphere hull and the point cloud of an arm as input of the algorithm. setCropOutside is
set to true as I want to get the points of the cloud that are inside the hull.
Current Behavior
The resulting filtered cloud has missing points and extra points. On the picture below is the hull made from the sphere point cloud and the arm point cloud with points outside the hull in green and points inside the hull in red.
Here is a link to the files used to reproduce the issue :
polygon.ply contains the hull information
test_hand_downsampled_1000_2.obj is the input point cloud we want to test
expected_filtered_result.obj is the result we wish to obtain (acquired through manual cropping with Blender).
filtered_result.ply contains the result of the algorithm
I compared the obtained result with the desired result made from cropping the arm point cloud with Blender. As can be seen on the above image, some points that are not supposed to be part of the intersection are still considered to be inside the hull.
Numerically:
237 points are expected in the intersection (see expected_filtered_result.obj)
236 points are common
1 point is missing (237-236)
there are 42 extra points
hence 278 points are in resulting point cloud (see filtered_result.ply
NB : Please note there is one minor difference between the expected and given points of the clouds after 3 decimals. For exemple, the point with coordinate (-118.585701, -163.048050, 138.409943) in the expected result is (-118.5857, -163.04803, 138.40997) in obtained result.
Related
I would like to calculate the Horizontal and Vertical field of view from the camera intrinsic matrix for the cameras used in the KITTI dataset. The reason I need the Field of view is to convert a depth map into 3D point clouds.
Though this question has been asked quite a long time ago, I felt it needed an answer as I ran into the same issue and was unable to find any info on it.
I have however solved it using the information available in this document and some more general camera calibration documents
Firstly, we need to convert the supplied disparity into distance. This can be done through fist converting the disp map into floats through the method in the dev_kit where they state:
disp(u,v) = ((float)I(u,v))/256.0;
This disparity can then be converted into a distance through the default stereo vision equation:
Depth = Baseline * focal length/ Disparity
Now come some tricky parts. I searched high and low for the focal length and was unable to find it in documentation.
I realised just now when writing that the baseline is documented in the aforementioned source however from section IV.B we can see that it can be found in P(i)rect indirectly.
The P_rects can be found in the calibration files and will be used for both calculating the baseline and the translation from uv in the image to xyz in the real world.
The steps are as follows:
For pixel in depthmap:
xyz_normalised = P_rect \ [u,v,1]
where u and v are the x and y coordinates of the pixel respectively
which will give you a xyz_normalised of shape [x,y,z,0] with z = 1
You can then multiply it with the depth that is given at that pixel to result in a xyz coordinate.
For completeness, as P_rect is the depth map here, you need to use P_3 from the cam_cam calibration txt files to get the baseline (as it contains the baseline between the colour cameras) and the P_2 belongs to the left camera which is used as a reference for occ_0 files.
thanks for reading this question. My title is basically what I'm trying to achieve. I did a poisson surface mesh generation using Poisson_surface_reconstruction_3(cgal). I can't figure out how to map the node identities of my resulting surface mesh into my starting point sets?
The output of my poisson surface generation is produced by the following lines:
CGAL::facets_in_complex_2_to_triangle_mesh(c2t3, output_mesh);
out << output_mesh;
In my output file, there are some x y z coordinates, followed by a set of 3 integers each line, I think they indicates which nodes form a delaunay triangle. The problem is that the output points do not correspond to my initial point set, since not any x y z value match to any of my original points. Yet I'm trying to figure out which points are forming a delaunay triangles in my original point set.
Could someone suggest me how can I do this in cgal?
Many thanks.
The poisson recontruction algorithm consist in meshing an implicit function that somehow fits you input points. In practice, it means that you input point will no belong to the set of points of the output surface, and won't even lie exactly on triangles of the output surface. However, they should not be too far from the output surface (except if you have some really sparse sampling parts).
What you can do to locate your input points with the output surface is to use the function closest_point_and_primitive() from the AABB-tree class.
Here is an example of how to build the tree from a mesh.
I'm currently implementing a mesh extrusion algorithm for plane shapes, let's assume for a rectangle.
When I extrude this rectangle I create four new sides (resulting in 8 new triangles) and a new bottom for the 3d shape.
This works fine when I duplicate all vertices so that my final cube has 24 of them. But I'd like to avoid these extra vertices now so that I have only 8 vertices. Unfortunately, in this case I do not know how to calculate the UV coordinates and I keep getting wrong results as shown in the image below.
The correct result would look like this (with duplicated faces):
My first question is: Is it possible to generate a good uv map with just 8 vertices (and hence 8 uv coordinates) for a cube?
Second is: How? :)
Thanks for your help.
In my meshing application I will have to specify fix points within a domain. The idea is that, the fix points must also be the element points after the domain is being meshed.
Furthermore, the elements around the fix points should be more dense. The general concept is that for the fix points, there should exist a radius r around those points, such that the mesh size inside r is of different sizes than outside of the r. The mesh sizes inside and outside of the r should be specifiable.
Are these two things doable in CGAL 2D Mesh algorithm?
Using your wording, all the input point of the initial constrained Delaunay triangulation will be fix points, because the 2D mesh generator only insert new points in the triangulation: it never removes any point.
As for the density, you can copy, paste, and modify a criteria class, such as CGAL::Delaunay_mesh_size_criteria_2<CDT> so that the local size upper bound is smaller around the fix points.
Now, the difficulty is how to implement that new size policy. Your criteria class could store a const reference to another Delaunay_triangulation_2, that contains only the fixed points you want. Then, for each triangle query, you can call nearest_vertex and then actually check if the distance between the query point is smaller that the radius bound of your circles. For a triangle, you can either verify that for only its barycenter, or for all three points of the triangle. Then, according to the result of that/those query(s), you can modify the size bound, in the code of your copy of CGAL::Delaunay_mesh_size_criteria_2<CDT>.
Yes, no points will be removed from the triangulation by the mesher.
Note however that if you insert points too close to a constraint this will induce a refinement of the constraint while it is not Gabriel.
I (relatively new to CGAL and not a C++ expert) am trying to extract the index of the nearest-neighbor 3D points returned from CGAL's surface_neighbor_coordinates_3 (which searches a 2D mesh comprised of 3D points to find natural-neighbors of a provided query-point) in this CGAL example. In other examples (3D interpolation with 3D meshes), I have been able to do this by adding info to vertex handles in the triangulation data structure. In the linked example, I simply wish to retrieve the indices of returned coords with respect to where the points in coords reside index-wise within the input list of points.
The other call-options for surface_neighbor_coordinates_3 seem to suggest this may be possible by passing-in an existing triangulation (with perhaps its info-augmented triangulation-data-structure). However, I'm not sure how to specify the info-augmented Delaunay_triangulation_3 for the case of a 2D mesh consisting of 3D points. I'm experimenting with it (using advancing-front triangulations to 2D-mesh my 3D points) but would like to know if there's some easier way to use the native capabilities of surface_neighbor_coordinates_3 if one only seeks to also have an info field associated with the returned points.
Any help would be greatly appreciated ... this has stumped me for a week.