| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| ece4580:module_pcd:bridgeproblem [2017/04/15 17:09] – [2.2 Inter-Partition Cluster Merging] pvela | ece4580:module_pcd:bridgeproblem [2024/08/20 21:38] (current) – external edit 127.0.0.1 |
|---|
| - Continue merging clusters across partitions until there is no more to merge. | - Continue merging clusters across partitions until there is no more to merge. |
| |
| Let's review each of the steps. | Let's review each of the steps, each of which should be some kind of function that gets invoked. There should be a master function that organizes it all and executes the overall sequence. It should be called from a script that performs all of the other activities (loading data into point cloud, meshing, visualization). |
| |
| ==== 2.1 Partitioning and clustering the cloud ==== | ==== 2.1 Partitioning and clustering the cloud ==== |
| This activity combines some of the prior work and will require some book-keeping to get working proper. For example, each partition will have cluster labels. Since they are partitioned separately, the labels should be redone when merging with a pre-existing partition. Suppose a pre-existing, master point cloud had labels {1, 2, 3, 4, 5} and the one to merge had labels {1, 2, 3}. First, the three new partitions are tested and cluster 2 is found to match with cluster 4 from the master set. All of its labels should be set to 4, then properly added to the master point cloud (if the points are appended to the point array, then the labels should be appended to the label array). The remaining two labels {2, 3} should be changed to be {6, 7} and then their points and labels appended to the master partition. You gotta be careful to not mess up the ordering of the data. | This activity combines some of the prior work and will require some book-keeping to get working proper. For example, each partition will have cluster labels. Since they are partitioned separately, the labels should be redone when merging with a pre-existing partition. Suppose a pre-existing, master point cloud had labels {1, 2, 3, 4, 5} and the one to merge had labels {1, 2, 3}. First, the three new partitions are tested and cluster 2 is found to match with cluster 4 from the master set. All of its labels should be set to 4, then properly added to the master point cloud (if the points are appended to the point array, then the labels should be appended to the label array). The remaining two labels {2, 3} should be changed to be {6, 7} and then their points and labels appended to the master partition. You gotta be careful to not mess up the ordering of the data. |
| |
| | **Merging Two Partitions:** Since the merging of clusters basically tries to seam together point clouds that a close enough, the only points that need to be tested for merging are the points that would have been connected had the two partitions been one. Therefore, only the points in both partitions that are near to each other need to be tested. The basic idea is to create a connected component matrix only for those points, then using the cluster normals and unique labels for the two clusters, apply the same clustering process to see if the two different components are sufficiently close enough to be merged. If so, then merge the clusters. |
| ==== 2.3 Visualization ==== | ==== 2.3 Visualization ==== |
| |
| When the above is done, then the resulting master point cloud should contain all of the pre-partition points in one object, plus their cluster labels. Use the clustering to plot the triangulated surfaces. So, rather than a difference point cloud, we should see a difference surface. | When the above is done, then the resulting master point cloud should contain all of the original points in one point cloud object again, plus their cluster labels. Use the clustering to plot the triangulated surfaces. So, rather than a difference point cloud, we should see a difference surface. |
| |
| |
