ambiguous behaviour of point_pool

[AIBluefisher]

Hi, @chrischoy

I checked the code of the method point_pool in warpconvnet.nn.functional.point_pool.py. The behaviour of this method looks ambiguous to me. From the code:

    pc: "Points",  # noqa: F821
    reduction: Union[REDUCTIONS | REDUCTION_TYPES_STR],
    downsample_max_num_points: Optional[int] = None,
    downsample_voxel_size: Optional[float] = None,
    return_type: Literal["point", "voxel"] = "point",
    avereage_pooled_coordinates: bool = False,
    return_neighbor_search_result: bool = False,
    return_to_unique: bool = False,
    unique_method: Literal["torch", "ravel", "morton"] = "torch",
) -> Geometry:
    """
    Pool points in a point cloud.
    When downsample_max_num_points is provided, the point cloud will be downsampled to the number of points.
    When downsample_voxel_size is provided, the point cloud will be downsampled to the voxel size.
    When both are provided, the point cloud will be downsampled to the voxel size.

    Args:
        pc: Points
        reduction: Reduction type
        downsample_max_num_points: Number of points to downsample to
        downsample_voxel_size: Voxel size to downsample to
        return_type: Return type
        return_neighbor_search_result: Return neighbor search result
        return_to_unique: Return to unique object
    Returns:
        Points or Voxels
    """

I'm wondering if both downsample_max_num_points and downsample_voxel_size have the same priority, or if one would take precedence over the other.
Moreover, in the implementation of PointMinkUNetBase, the return_type for the point_pool method is sparse. However, sparse mode is not supported in the current implementation of point_pool.

[AIBluefisher]

Oh, from the code, downsample_max_num_points has a higher priority over downsample_voxel_size .