Point-to-grid interpolation (trilinear gridding)

Overview

A point cloud has no order and no fixed grid, so convolutions cannot read it directly. Point-to-grid interpolation places each point on a regular grid of vertices. The point adds a weight to the eight vertices of the cell that contains it, and the weight falls off with distance along each axis 2006.03761 §3.2 2006.03761 eq. 3. The result is a dense array that a 3D CNN can process 2006.03761 §3.3.

The GRNet authors argue against the simpler alternative. Voxelising a cloud into binary cells loses geometric information, and the paper says the result is not a differentiable reconstruction target 2006.03761 §1 2006.03761 §3.2. Trilinear weights keep each point's contribution continuous in its position.

Only one paper card lists this concept, so the variants below are the forms found in that paper. They are not a survey of point-to-grid methods. The reverse step, grid to points, is a different operation (Gridding Reverse, then Cubic Feature Sampling) and is not covered here 2006.03761 §3.4 2006.03761 §3.5.

Variants

Trilinear splat, averaged over neighbours (as written)

Each vertex value is the sum of the trilinear weights of the points that neighbour it, divided by the number of those neighbours 2006.03761 §3.2 2006.03761 eq. 2. A vertex with no neighbour gets 0 [arxiv:2006.03761 §3.2]. Card: GRNet.

The division makes the vertex value an average, so it does not depend on how many points fall near that vertex. The paper's stated grid resolution is 64 vertices per axis 2006.03761 §4.7 2006.03761 tab. 5.

Trilinear splat, summed (as released)

The released CUDA kernel adds each trilinear product to its vertex and does not divide by the neighbour count gridding.cu. The vertex value therefore grows with local point density. The card records this as a difference between the paper and the code, and does not say which form produced the reported numbers 2006.03761 §3.2 2006.03761 eq. 2.

When to use which

Implementation sketch

Pseudocode for the forward splat, with the averaging step as a flag. The paper does not state the map from coordinates to vertex units, so that step is left to the implementer.

# Trilinear splat of a point cloud onto an n^3 grid  [§3.2] [eq. 2] [eq. 3]
# Input:  points (P, 3) in [-1, 1]^3, n vertices per axis
# Output: grid (n, n, n)

def point_to_grid(points, n, average=True):
    grid = zeros(n, n, n)
    count = zeros(n, n, n)
    for p in points:
        # Position in vertex units; the paper does not state this map  [§3.2]
        x = to_vertex_units(p, n)
        # The point's cell has eight corner vertices  [§3.2]
        for v in cell_vertices(x):
            # Product over the three axes of 1 - |v - x|  [eq. 3]
            w = prod(1 - abs(v - x))
            grid[v] += w
            count[v] += 1
    if average:
        # Eq. 2: divide each sum by its neighbour count; empty vertices stay 0  [§3.2]
        grid = where(count > 0, grid / count, 0)
    return grid

Contradictions

• Averaging. The paper divides each vertex sum by the number of neighbours 2006.03761 §3.2 2006.03761 eq. 2. The released kernel does not gridding.cu. Both are stated; this page does not choose between them.

Papers

• GRNet: Gridding Residual Network for Dense Point Cloud Completion: defines the trilinear gridding step and the grid-to-point step that follows it.