Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix for issue #905. #912

Merged
merged 2 commits into from
Sep 18, 2014
Merged

Conversation

jpapon
Copy link
Contributor

@jpapon jpapon commented Sep 15, 2014

Fix for problem (issue #905) where leaves would not be found during seeding, and warning would show up - now we use leaf indices directly for seeding, instead of doing a reverse look up. This is faster and fixes the problem.

Changed OctreePointcloud Adjacency to use std::list instead of std::set.
Added comparator to SupervoxelHelper so that the internal set of voxels owned by a helper is sorted by index instead of memory location.

Supervoxels and OctreePointcloudAdjacency are now fully deterministic.

…p. Now we use leaf indices directly for seeding, instead of doing a look up

Changed OctreePointcloud Adjacency to use std::list instead of std::set, added comparator to SupervoxelHelper so that the internal set of voxels owned by a helper is sorted by index instead of memory location
Added brief comment explaining comparator
@@ -54,7 +54,7 @@ namespace pcl
class OctreePointCloudAdjacencyContainer : public OctreeContainerBase
{
public:
typedef std::set<OctreePointCloudAdjacencyContainer*> NeighborSetT;
typedef std::list<OctreePointCloudAdjacencyContainer*> NeighborSetT;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By switching from set to list you give up the invariant that there are no duplicate entries. Just to make sure: was this assumption used in code? And if so, do we now have checks to make sure it holds?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@taketwo No, there are no checks at the moment to make sure no duplicate neighbors are added.
Neighbors are added quite simply - we just check the 26 neighborhood by octree keys and add them if they exist.

There is no way to add new points into the octree after it is constructed, so the only function that modifies the list of neighbors is computeNeighbors in octree_pointcloud_adjacency - meaning that the only way to get duplicates is if a user manually adds in neighbors.

I'm thinking I should modify the OctreePointCloudAdjacencyContainer so that only const_iterators and getData() can be used from outside of OctreePointCloudAdjacency. It doesn't really make sense for users to be messing with anything else.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'll rename that typedef too...

…djacencyContainer. Neighbors can now only be added/removed from within OctreePointcloudAdjacency. This does *not* mean neighbors can't be modified, just that the list of neighbors itself can't be modified.
taketwo added a commit that referenced this pull request Sep 18, 2014
@taketwo taketwo merged commit 7769b65 into PointCloudLibrary:master Sep 18, 2014
@jpapon jpapon deleted the supervoxel_loop_problem branch September 22, 2014 08:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants