Problem
Padding/validity masks are currently computed with several different ad-hoc rules across the codebase, for example using :2, :3, :4, :6, :8, or the full last dimension depending on the local call site.
Some differences are legitimate because tensor schemas differ. However, the current approach makes it easy to accidentally apply an old schema assumption to a new tensor layout. One concrete example is neighbor future masking, where a 3-column (x, y, yaw) assumption can leak into a 4-column (x, y, cos, sin) trajectory pipeline.
Impact
This is a correctness and maintainability risk:
- train and validation paths can drift;
- old 3-column and new 4-column trajectory semantics can be mixed silently;
- metric, loss, augmentation, and visualization code can disagree about which timesteps are valid;
- future schema changes become risky because each call site must be audited manually.
Expected behavior
Introduce shared, typed validity-mask helpers for the main tensor schemas, such as:
- ego/neighbor trajectory pose masks;
- neighbor past state masks;
- lane/route/polyline masks;
- static object masks.
Training, validation, augmentation, metrics, and visualization should use the same helpers wherever possible. The helper names should encode the schema assumption explicitly so future changes are localized and reviewable.
Problem
Padding/validity masks are currently computed with several different ad-hoc rules across the codebase, for example using
:2,:3,:4,:6,:8, or the full last dimension depending on the local call site.Some differences are legitimate because tensor schemas differ. However, the current approach makes it easy to accidentally apply an old schema assumption to a new tensor layout. One concrete example is neighbor future masking, where a 3-column
(x, y, yaw)assumption can leak into a 4-column(x, y, cos, sin)trajectory pipeline.Impact
This is a correctness and maintainability risk:
Expected behavior
Introduce shared, typed validity-mask helpers for the main tensor schemas, such as:
Training, validation, augmentation, metrics, and visualization should use the same helpers wherever possible. The helper names should encode the schema assumption explicitly so future changes are localized and reviewable.