Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.


The definition of group_distance is not very clear. This PR tries to improve it and it also changes the code to be more internally coherent. Feel free to reject the PR if the original intent of the function is the one currently implemented.
The current description of
group_distancesaysIf we accept overlapping groups the implementation is straightforward and it's sufficient to use a ball query search for every point to find the neighborhood of every point.
On the other hand, if the grouping is meant to create distinct and separate groups the task is more difficult to define because for the point A, B, C we can have ||A-B|| < distance; ||B-C|| < distance and ||A-C|| > distance.
In that case B can be both in the group of A and in the group of C and we could even decide to merge the two groups in a single group since the share a common element.
Merging the group would break any guarantee on the radius of the group so it's probably not the aim of this function, also
trimesh.grouping.clustersdoes exactly that.The current implementation in this situation assigns B to both the group of A and the group of C allowing for overlapping groups, but it avoids creating the group of B that could include all the points A, B, C. This design does not seem very coherent because overlapping groups are allowed only if the center is not part of an existing group.
The PR makes the group non-overlapping assigning B to the group of A and C in a separate group. The new implementation depends on the order of points like the previous one.
This example show the proposed change.
With the current implementation the result is
The new code would produce instead non-overlapping groups
Maybe to make the function permutation-invariant we could favor bigger groups and remove elements from the other groups. For example in this case a single group with all the 3 points could be preferable and closer to the intent of the user.
To implement that variant favoring big groups the function should compute all the neighborhoods and sort them by size before assigning every point to a single group.
I'm happy to hear your thoughts!