[GT Generation] Negative-x voxel wrapping bug and clarification on mesh reconstruction

[miaozhang97]

Hi authors,

Thank you for releasing RadarOcc. I believe there is a bug in the released occupancy GT-generation code.

The configured range is:

pc_range = [0, -25.6, -5.0, 51.2, 25.6, 3.0]

so the valid x range is [0, 51.2). However, process_kradar.py uses:

np.abs(scene_points[:, 0]) < pc_range[3]

which also keeps negative-x points. After voxelization, these become negative NumPy indices. For example, x = -0.4 m becomes index -1, which is interpreted as index 127, placing the point near x = 51 m.

Although each LiDAR frame is initially filtered by the radar FOV, the static points from multiple frames are stitched and then transformed into each target-frame coordinate system. A point that was in front when captured may therefore have x < 0 in a later target frame. The current abs(x) filter retains it, causing it to wrap into the far front region.

The later filter_kradar_fov.py cannot remove these artifacts because the negative-x points have already been converted into valid positive-x voxels.

Relevant code:

https://github.com/Toytiny/RadarOcc/blob/main/tools/process_kradar.py#L487-L521

I suggest filtering with the actual bounds before voxelization:

(scene_points[:, 0] >= pc_range[0]) & \
(scene_points[:, 0] < pc_range[3])

Could you also confirm whether the GT used in the paper was generated with --to_mesh or --whole_scene_to_mesh? The README runs python process_kradar.py, for which both options default to False, whereas SurroundOcc uses Poisson reconstruction for GT generation.

Thank you!