lidar.ply
The cloud in a format most viewers open without asking questions. Position and intensity per point.
LiDAR
Raycast LiDAR
Rays are traced from the sensor into the scene and the points that come back are written as a cloud, labelled per instance, from the same frame as the picture and the depth. It is a geometric sensor model, not a physical one, and this page says which parts of a real LiDAR it does and does not reproduce before it says anything else.
- Method
- Ray traced, one ray per sample
- Returns
- First hit only
- Labels
- Per point, per instance
- Status
- Experimental
What it is
The sensor sweeps a set of rings, each ring a set of directions, and casts a line trace along every one of them. Where the trace hits geometry, the distance to the hit becomes a point in the cloud. Nothing here is derived from the depth buffer: the rays are traced against the world, so the cloud sees what a ray sees rather than what the camera saw.
That distinction matters for the thing people usually want a point cloud for. A depth buffer only contains what the camera can see. A ray from a sensor mounted somewhere else sees around a corner the camera cannot, and hits surfaces that face away from the lens.
Every point carries the identity of the object it hit, taken from the same target list the images use, so a point cloud and an image from the same frame agree about which object is which.
What is simulated
| Modelled | How |
|---|---|
| Geometry and range | A line trace per ray, hit distance clamped to the sensor range |
| Rings and rotation | Channel count and points per rotation are both settings |
| Range noise | Gaussian, with the standard deviation set in metres |
| Intensity | From the angle the ray meets the surface at, falling off with range, plus its own Gaussian noise |
| Per-point labels | The instance id of the object hit, matched to the image labels |
| Consistency | An optional gate that fails a run when an object visible in the image has no returns |
What is not simulated
This is the half of the page that decides whether the feature is any use to you, so it is stated rather than implied.
| Not modelled | What that means for you |
|---|---|
| Material reflectance | Intensity comes from geometry alone. A black car and a white wall at the same angle and range return the same intensity, which a real sensor would not do |
| Multiple returns | Each ray stops at the first thing it hits, so foliage, glass, rain and dust do not produce the second and third returns real sensors use |
| Beam divergence | A ray is a line, not a widening cone, so no partial hits at object edges |
| Dropouts | No missing returns from dark, wet or retroreflective surfaces, and no blooming from road signs |
| Atmospheric attenuation | Fog, rain and snow do not weaken or scatter the beam |
| Motion during the sweep | The whole cloud is sampled from one instant, so there is none of the skew a rotating sensor on a moving vehicle produces |
So it is not a substitute for a sensor model when the thing you are studying is the sensor. If your model is meant to learn that wet asphalt returns nothing, this will teach it the opposite.
It is useful when the thing you are studying is the geometry: shape, position, occlusion, how many points land on a target at a given range, and whether a detector can find an object in a cloud at all. It is also useful for building the plumbing of a pipeline before the real data exists.
What a run writes
lidar.bin
KITTI binary layout, for training code that already reads that and does not want to learn a new one.
lidar.labels.bin
The instance id per point, in the same order as the cloud, so the two files line up index for index.
lidar.json
The sensor settings the frame actually used, the point count, and the registry that maps ids to labels.
These sit in the same frame folder as the picture, the identity mask and the depth, written from the same instant. Whatever else the point cloud is, it is synchronised with the image beside it.
Why it says experimental
Because of the second table. Calling this LiDAR without saying what is missing would be the kind of claim somebody discovers three weeks into a project, and the gap between a geometric ray cast and a physical sensor model is wide enough that the word on its own is misleading.
It is also newer and less exercised than the image path. The image side has a published capture, a grade, a validation report and an experiment that trained a model. The LiDAR side has none of those yet. When it does, this page will say so and the word experimental will come off.