Fix a bug in OctreePointCloudAdjacency::computeNeighbors()
#454
Conversation
The `x`, `y`, and `z` fields of `OctreeKey` are unsigned integers, so in some cases unsigned integer underflow occurs and the tree is queried for non-existing leaves with huge keys. Due to the way `findLeaf()` is implemented, such queries occasionally succeed and return some random leaves.
|
It won't be correct to skip the iteration completely if, say, By the way, I have another pull request related to |
|
Closing this pull request in favor of #455 which has additional optimization. |
|
I don't think I did this in the proper way, because now we have two competing pull requests open. Anyway, what do you think of the version in my pull request? |
|
@jpapon Actually I am not sure what is the standard workflow in such situations. Perhaps you cloud let me know about the commit that you want to add and I cherry-pick it from your fork to my branch that I am proposing for pull request. |
|
Yeah, that would be better, I could have just put a link here to my branch, and you pull the commit into this request. |
The
x,y, andzfields ofOctreeKeyare unsigned integers, so in some cases unsigned integer underflow occurs and the tree is queried for non-existing leaves with huge keys. Due to the wayfindLeaf()is implemented, such queries occasionally succeed and return some random leaves.