The application had a problem with some standard point cloud dataset testing.
SHIZHIYOUYI opened this issue · comments
Thank you for coming up with a very good algorithm.
When I applied the point cloud standard dataset test, I found that in some planar areas, the curvature color representation is not entirely correct. To make it easier for you to reproduce this phenomenon for reference, I submit the point cloud and effect I used for testing here. It can be seen that in the two planar and workpiece point cloud data, blue and red overlap in the planar area, and even the planar area point cloud is all red. I guessed if it was due to the poor Delaunay triangulation, so I imported this point cloud into meshlab and found that there were no serious structural errors in the point cloud.
I would appreciate it if you could give an answer to the curvature of this planar region, and thank you again for your interest and look forward to your reply.
0133_test.zip
two_plane_test.zip
I'm not sure if this is due to the direction of the normal vector, but I observed that the planes with completely red curvature were perpendicular to the X-axis of the point cloud's own coordinate system.
(1)Your concern about Delaunay triangulation is true for this data. This data is different from organic models like the cow or the bunny. It has planar surfaces and sharp edges, which could have co-linear case that cause Delaunay triangulation to fall apart. This has a easy fix though. To ensure the robustness for this kind of data, I recommend you add a pre-processing step, adding small Gaussian noise to point position values before calculating the curvature. (2) The confusing color problem you observed is not caused by Delaunay triangulation though. It is a visualization problem caused by numerical error. The result saved in text file is correct. At planar regions, your curvature should be 0. But the code would use a small float number to represent that, which could be positive or negative. If you observe the output txt file, you might see numbers like -2.62382e-13 or 2.95437e-14. They are all 0. When it's negative, it could mess up the colormap. The easy fix would be change line 150 in Draw.cpp from Eigen::VectorXd k_S_PCD_vis = k_S_PCD.array().pow(0.0425); to Eigen::VectorXd k_S_PCD_vis = k_S_PCD.array().abs().pow(0.0425);. I tried that and got a visualization that seems reasonable. Therefore, updated that line in my codebase accordingly. Thank you for sharing this helpful observation!
