You know that moment when your code is clearly correct but the output is garbage — and after two days you discover the CSV was tab-delimited, not comma-delimited? This paper is eight pages of that, except the stakes are a self-driving car's ability to see pedestrians, and the delimiter problems are coordinate frames, suppression thresholds, and phantom zero-points in real sensor data. The result: first place in the V2X-Real track of the UrbanTwin Sim2Real LiDAR Challenge at ECCV 2026. The committed claim is this: when training a 3D object detector entirely on synthetic data and deploying it on real roadside Ouster OS1-64 LiDAR, the dominant failure modes are diagnostic, not architectural. Three fixes — coordinate frame recovery, per-class non-maximum suppression, and null-return modeling — account for nearly all of the performance delta. The combined score lands at 0.7457 (0.4382 detection mAP + 0.9251 realism). The first fix is almost embarrassingly mundane and hugely consequential. A coordinate frame mismatch between predictions and ground truth was silently zeroing out detection AP. Recovering the correct frame jumped the score from 0.3520 to 0.5147 in a single submission — a 46% relative gain from what amounts to a units-of-measurement bug. If you've ever lost days to a y-up vs z-up mismatch in a graphics pipeline, you know the flavor. The second fix exposes a subtler problem. Standard NMS uses a single IoU threshold (typically 0.3) across all classes. But pedestrians are small (~0.7m bounding boxes) and cluster together. At a 0.3 IoU threshold, two distinct people standing a meter apart get merged into one detection. Switching to per-class NMS thresholds catapulted overall mAP from 0.0751 to 0.4295 — a 5.7× improvement. This is not a new idea in detection, but identifying it as the dominant failure mode in the sim2real pedestrian context is the contribution. The third fix addresses the realism score. Roughly 31% of the real reference point cloud consists of null returns encoded as literal (0, 0, 0) points — a sensor-specific format artifact completely absent from synthetic data. Until the synthetic clouds modeled this, Earth Mover's Distance was pinned near its floor. The fix is trivial once diagnosed; the diagnosis is the work. What makes this paper genuinely useful is the negative-results section, reported at equal length to the positive findings. The author commits to full data provenance and compliance accounting, and the code is public. This is the kind of unglamorous, replicable engineering work that actually moves sim2real transfer forward — not by proposing a new backbone or loss function, but by cataloguing exactly where the pipeline breaks and why. The field fight in sim2real is between architectural innovation (better domain adaptation networks, style transfer, learned augmentation) and diagnostic engineering (find and fix the actual failure modes in your specific sensor-pipeline-evaluation stack). This paper lands firmly on the diagnostic side, and it won. The limitation is scope. One sensor (Ouster OS1-64), one challenge track, one detector pipeline. The three fixes are individually well-known techniques; the contribution is identifying them as the binding constraints in this specific sim2real gap. Whether these same three diagnostics dominate on a Velodyne VLP-32C or a Hesai Pandar64 is an open question. But as a template for how to do sim2real debugging — measure everything, change one thing, report the delta — this is a model worth copying.
