RTX LiDAR baked point deformation appears reversed within scan

[JBOMB86]

Update — minimal cross-brand reproduction on Isaac Sim 6.1

I reduced the issue to a simple constant-velocity plane test and reproduced the same representation-dependent timing behaviour with two different NVIDIA-native LiDAR configurations.

Isaac Sim: 6.1.0-rc.26+release.49347.2d230af4.gl

Motion BVH: enabled

The plane follows the same analytic world-space motion in both moving cases:

x(t) = -1 + 0.8t

The only intended difference is representation:

rigid Xform translation
time-varying point/vertex deformation

For each return I infer geometry time directly from measured plane position:

t_inferred = (x_measured + 1) / 0.8

and fit:

t_inferred = A + Bscan_start + Cfiring_offset

where correct forward within-scan timing predicts C ≈ +1, while reversed timing predicts C ≈ -1.

Ouster OS0

Native NVIDIA config:

OS0_REV7_128ch20hz1024res

STATIC

224,280 / 224,280 within 50 µm
range RMSE: 0.309591 µm

Rigid Xform

C = +0.9999975461
fit RMSE: 0.269076 µs
native: 400,559 / 400,559 within 50 µm
reversed: 0 / 400,559

Point deformation

C = -1.0000025167
fit RMSE: 0.259177 µs
native: 0 / 401,576 within 50 µm
reversed: 401,576 / 401,576
SICK multiScan100

Native NVIDIA config:

Product=multiScan136, Profile=Profile01_20Hz_0p125deg

STATIC

9,254 / 9,254 within 50 µm

Rigid Xform

C = +1.0000046404
fit RMSE: 0.301244 µs
native: 1,058 / 1,058 within 50 µm
reversed: 2 / 1,058

Point deformation

C = -0.9999942090
fit RMSE: 0.293700 µs
native: 2 / 1,070 within 50 µm
reversed: 1,070 / 1,070
Interpretation

The same representation split now reproduces across both Ouster and SICK:

rigid Xform motion follows forward/native firing time
point-deformed geometry follows the reversed within-scan relation

This makes an Ouster-specific profile/scheduler explanation much less likely.

Native GMO timestamps, timeOffsetNs, ranges, firing order and validity data were not rewritten. The reversed relation is evaluator-side scoring only.

I still do not want to claim a specific internal cause such as a buffer swap without NVIDIA-side instrumentation.

The remaining likely area appears to be the deformation-history / endpoint-order / per-ray interpolation convention used by the RTX/Motion-BVH path for deforming geometry.

A particularly useful NVIDIA-side diagnostic would be to expose, for two non-midpoint rays from the constant-velocity plane:

the actual FSD deformation sample times/states,
the two deformation endpoint buffers and their time convention,
the interpolation weight consumed by RTX for each ray.

That would distinguish whether the wrong states enter the submission path, the endpoints are interpreted in the wrong temporal order, or the reversal occurs later during traversal/output association.

[vick-yu]

Thank you for the rigorous analysis. We are checking this with our team, and we will
update this thread once we have an update.

If you can share your reproduction USD pair and evaluator script, that would be useful.

[JBOMB86]

Haha no worries! Attached is a minimal reproduction package you asked for. It contains the matched rigid-Xform and point-deformation USDs plus the evaluator script. Both assets implement the same constant-velocity plane motion, x(t) = -1 + 0.8t; the observed difference is that rigid Xform follows native firing time while point deformation follows the reversed within-scan relation.

…

On Tue, Sep 22, 2026 at 9:24 AM vyu-nv ***@***.***> wrote: Thank you for the rigorous analysis. We are checking this with our team, and we will update this thread once we have an update. If you can share your reproduction USD pair and evaluator script, that would be useful. — Reply to this email directly, view it on GitHub <#844?email_source=notifications&email_token=B3YTVXGFTPL7TAVDYS6C6FL5QGMBXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGQ2TEOBXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18545287>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B3YTVXANKVYU2SDKMI3SMGT5QGMBXAVCNFSNUABIKJSXA33TNF2G64TZHM4TSMRRG44TSMJWHNCGS43DOVZXG2LPNY5TCMBYGQ2TONRTUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/B3YTVXHG2FHE7NJSJIVH4DD5QGMBXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGQ2TEOBXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/B3YTVXAQK5UOTUXSXY2UWTL5QGMBXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGQ2TEOBXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[vick-yu]

The issue has been resolved internally via an internal ticket (5832939). This fix is scheduled to be released with Isaac Sim 6.2.0. Thanks for reporting!

[JBOMB86]

Absolute Legends!!!

[JBOMB86]

Hi I’ve been testing the Ouster OS0 REV7 sensor models in Isaac Sim 6.1 and wanted to ask whether there are any plans to add support for Ouster’s new REV8 range in the upcoming Isaac Sim 6.2 release. In particular, I’d be very interested in support for the new REV8 OS0/OS1/OS2 sensors, including their updated scan modes and native RGB LiDAR capabilities. The new colour LiDAR functionality looks especially relevant for robotics, environmental scanning, dynamic scene reconstruction, and sensor-fusion research, so it would be great to know whether official REV8 RTX LiDAR profiles are on the roadmap. Thanks for all the work on Isaac Sim 6.1 — the recent sensor and point-cloud updates have already been very useful. Kind regards, Jeremy

…

On Wed, Sep 23, 2026 at 5:47 AM vyu-nv ***@***.***> wrote: The issue has been resolved internally via an internal ticket (5832939). This fix is scheduled to be released with Isaac Sim 6.2.0. Thanks for reporting! — Reply to this email directly, view it on GitHub <#844?email_source=notifications&email_token=B3YTVXGKJKKI7H7PDZCISNL5QK3KZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGU3DQMBYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18556808>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B3YTVXFQIK3WVSZ7IRDVSTT5QK3KZAVCNFSNUABIKJSXA33TNF2G64TZHM4TSMRRG44TSMJWHNCGS43DOVZXG2LPNY5TCMBYGQ2TONRTUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/B3YTVXBKOFPYOOASAVZS77L5QK3KZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGU3DQMBYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/B3YTVXBG4KBWVEY32PDEKJT5QK3KZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGU3DQMBYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>