---
kind: concept
slug: bev-representation
title: Bird's-eye-view (BEV) representation
summary: >-
  A top-down grid of the scene that 3D detectors read and driving world models roll forward. Detector designs differ in how camera features reach it: lifted with predicted depth, written by camera attention, cropped per proposal, or kept as interacting maps. Trade-offs: compute, calibration and sensors. Numbers are author-reported.
tags: [bird-eye-view, lidar-camera-fusion, 3d-object-detection, autonomous-driving, polar-grid, cross-modal-attention, temporal-fusion, point-cloud, monocular-3d-detection, lane-topology, world-model, occupancy-forecasting, model-based-rl]
papers: ["1712.02294", "1903.08701", "2103.01100", "2104.10330", "2106.10823", "2203.17270", "2205.13790", "2206.09474", "2206.15398", "2208.11112", "2404.00717", "2408.10618", "2408.14197", "2510.16729", "2511.12590", "2512.02417"]
related: [object-detection, image-fusion, bird-eye-view-perception, object-queries, monocular-depth-estimation, graph-neural-network, multi-scale-feature-fusion, attention-mechanism, focal-loss, world-model, model-based-reinforcement-learning, collaborative-perception, bipartite-matching, semantic-segmentation, state-space-model, a-star-search, uncertainty-estimation, gaussian-mixture-model, multimodal-fusion]
status: draft
updated_at: 2026-11-01
---

## Overview

A bird's-eye-view (BEV) representation is a 2D map seen from above, in the
ego vehicle's frame. A detection head reads it to place objects on the road
[arxiv:2205.13790 §3]. Seven cards use it for 3D object detection on driving
data, and BEVFormer also feeds a map head [arxiv:2203.17270 §3.1]. The survey
card places these methods in a taxonomy and adds no variant of its own. A
second survey lists BEV as one grid-based LiDAR representation among several
[arxiv:2206.09474 §3.1]. LaserNet is the contrast: it detects on the LiDAR
range image and builds no BEV grid [arxiv:1903.08701 §3.1]. One card uses the BEV map for lane topology rather than boxes [arxiv:2511.12590
§3.2]. Two world-model cards keep a BEV state, forecast its change, and read
occupancy and a plan from it [arxiv:2408.14197 §3.2] [arxiv:2510.16729 §3.2].
One reinforcement-learning card feeds a two-channel BEV raster to its world
model as the observation, and the BEV is not built inside the method
[arxiv:2512.02417 §5.1.1]. Two more cards use BEV in other roles. A LiDAR
occupancy network fuses a semantic and a geometric BEV branch
[arxiv:2408.10618 § Method]. A cooperative driving model builds a BEV on each
side of a vehicle-roadside link, but sends only sparse queries and one
occupancy map over the link, not the BEV itself [arxiv:2404.00717 § Data
generation].

The cards differ in what they put on the map:

- **Single camera, depth distribution.** One front camera predicts a depth
  distribution per pixel, lifts its features into a voxel grid and collapses
  it to BEV. No LiDAR is needed at run time. CaDDN does this from a monocular
  image [arxiv:2103.01100 §3.1] [arxiv:2103.01100 §1].
- **Shared grid.** Every stream writes into one common grid in ego
  coordinates, and one head reads the result. BEVFusion does this with a
  camera stream and a LiDAR stream [arxiv:2205.13790 §3].
- **Camera-only polar grid.** Six cameras write a grid of distance and angle,
  not a square grid. PolarFormer learns the distance by attention, without
  predicting depth [arxiv:2206.15398 §1] [arxiv:2206.15398 §3.1].
- **Camera-only learned grid with history.** Learnable queries on a square
  grid read the six cameras through deformable attention, and the previous
  grid is carried forward after an ego-motion shift. BEVFormer does this
  [arxiv:2203.17270 §3.1] [arxiv:2203.17270 §3.3] [arxiv:2203.17270 §3.4].
- **Lane masks on a camera BEV grid.** Learnable lane queries each predict a
  BEV mask. The masks weight a grid encoding that is added back into the
  queries, so each lane is tied to a region of the map. The output is lane
  topology, not boxes [arxiv:2511.12590 §3.2] [arxiv:2511.12590 §3.3].
- **Forecast of the BEV state.** The BEV state is an input to a predictor that
  rolls it forward in time, and occupancy and a plan are read from the state.
  Drive-OccWorld conditions its memory on ego motion, and IR-WM adds a predicted
  change to the previous state [arxiv:2408.14197 §3.2] [arxiv:2510.16729 §3.2].
- **Per-proposal crops of a LiDAR map and an image.** AVOD keeps the LiDAR BEV
  map and the image as two feature maps. It crops both at each anchor or
  proposal and averages the crops, so no camera data is written onto the BEV
  map [arxiv:1712.02294 §3.3] [arxiv:1712.02294 §3.4].
- **Separate maps with interaction.** The LiDAR BEV map and the image features
  stay as two representations. They exchange information through the known
  calibration between points and pixels, and the decoder reads them in turn
  [arxiv:2208.11112 §3.1] [arxiv:2208.11112 §3.2].
- **One BEV map among several LiDAR inputs.** BADet keeps a LiDAR BEV map as
  one of three feature sources for each proposal, next to voxel and raw-point
  features, and refines proposals with a graph [arxiv:2104.10330 §3.2]
  [arxiv:2104.10330 §3.3].

Among the cards, only the shared-grid design needs every stream to produce a
feature map of the same height and width in the same ego coordinates
[arxiv:2205.13790 §3]. The polar, learned-grid and interaction designs do not
need it, BADet samples one BEV map at each proposal's footprint, and AVOD
crops its two maps to one size per anchor [arxiv:1712.02294 §3.3].

A survey places these methods in a wider taxonomy. It groups voxel-based LiDAR
detectors, which often collapse points into a BEV map, and camera methods
that lift image features into 3D [arxiv:2106.10823 §3.1] [arxiv:2106.10823
§3.2]. It is a taxonomy, not a method, so it adds no variant below.

## Variants

### Camera lift into a shared LiDAR-sized grid

What it is: an independent camera stream that builds a BEV map by predicting
depth per pixel, then fuses with a LiDAR BEV map at the feature level
[arxiv:2205.13790 §3]. At inference it needs the images and the
camera-to-LiDAR matrices only. The LiDAR points enter through the LiDAR stream
and the fusion module [arxiv:2205.13790 §3]. Key results, measured against
the LiDAR-only row of each setting [arxiv:2205.13790 tab. 1]:

- Fused with TransFusion-L on nuScenes validation: 67.9 mAP against 64.9 for
  LiDAR alone, and 71.0 NDS against 69.9 [arxiv:2205.13790 tab. 1].
- With the field of view cut to plus or minus 60 degrees, the fused
  TransFusion-L reaches 41.5 mAP against 19.0 for LiDAR alone
  [arxiv:2205.13790 tab. 3].

Card: [BEVFusion: A Simple and Robust LiDAR-Camera Fusion Framework](/papers/2205.13790).

### Monocular lift with a depth distribution (CaDDN)

What it is: a single camera and no LiDAR at inference. A ResNet-101 backbone
gives image features at 1/4 of the input resolution [arxiv:2103.01100 §3.1].
A depth head predicts a softmax over depth bins for each pixel, and each pixel's
reduced features are multiplied by these probabilities to form a frustum
volume [arxiv:2103.01100 §3.1] [arxiv:2103.01100 eq. 1]. The frustum is sampled
into a voxel grid with the camera projection, height is folded into channels,
and a PointPillars-style backbone and head read the resulting BEV map
[arxiv:2103.01100 §3.1] [arxiv:2103.01100 §3.2]. Bin spacing is linear in the
increasing discretisation (LID) [arxiv:2103.01100 §3.3] [arxiv:2103.01100
eq. 2]. LiDAR points, projected into the image, supervise the depth bins during
training only [arxiv:2103.01100 §3.4]. Key results, author-reported on KITTI
test, Car, one frame, AP|R40 [arxiv:2103.01100 tab. 1]:

- Car moderate 13.41 AP, against 11.72 for D4LCN. Among the single-frame rows,
  that is the highest other than this one [arxiv:2103.01100 tab. 1].
- Ablation on KITTI val, Car moderate: depth distribution without depth
  supervision gives 6.43 AP. Adding supervision gives 14.03, and LID
  discretisation gives 16.31 [arxiv:2103.01100 tab. 3] [arxiv:2103.01100
  tab. 6].
- Waymo validation, Vehicle, front camera only: 17.54 mAP at IoU 0.5 for
  Level 1, against 3.79 for M3D-RPN. The M3D-RPN baseline is the authors' own
  extension [arxiv:2103.01100 tab. 2] [arxiv:2103.01100 §4].

The results give no runtime or memory figure, so measure before choosing it.
The frustum holds 64 channels over every depth bin at each feature pixel
[arxiv:2103.01100 §3.1].

Card: [Categorical Depth Distribution Network for Monocular 3D Object Detection](/papers/2103.01100).

### LiDAR-only BEV heads (baseline in the same paper)

The LiDAR stream alone, with PointPillars, CenterPoint or TransFusion-L, is
the reference point for every gain above [arxiv:2205.13790 tab. 1]. It has
no camera stream, so it has no depth prediction or lift. Latency and memory
are lower: on a V100 at batch size 1, TransFusion-L with LiDAR only takes
263.61 ms and 12536 MB [arxiv:2205.13790 tab. 13].

### LiDAR BEV map as one feature source for a graph refiner

What it is: a LiDAR-only two-stage detector. A 2D network runs on the BEV
map, and its proposals are refined in a second stage [arxiv:2104.10330 §3.1.2].
Each proposal's node state joins three sources: BEV features sampled on a small
grid over the proposal's footprint, voxel features interpolated from the 3D
backbone, and point features from a PointNet++-style branch [arxiv:2104.10330
§3.2]. A radius graph links nearby proposals, and message passing lets each
box take the boundary cues of its neighbours [arxiv:2104.10330 §3.3]. The
camera is not used. Key results, author-reported:

- KITTI test, Car moderate: 81.61 AP3D and 91.32 APBEV, against 81.62 AP3D and
  88.83 APBEV for Voxel R-CNN. The 3D score is on par, and the BEV score is
  higher [arxiv:2104.10330 tab. 1]. The authors say the BEV score was first on
  the leaderboard at submission [arxiv:2104.10330 §4.2.2].
- KITTI validation, Car moderate, ablation: BEV features alone give 79.93 AP3D,
  and all three sources give 85.77 [arxiv:2104.10330 tab. 6]. The refiner
  itself gives most of the gain: 79.94 to 85.77 with the refiner added to the
  same backbone [arxiv:2104.10330 tab. 5].
- nuScenes validation: 47.65 mAP and 58.84 NDS [arxiv:2104.10330 tab. 4].

Card: [BADet: Boundary-Aware 3D Object Detection from Point Clouds](/papers/2104.10330).

### Two-view proposal crops (AVOD)

What it is: a two-stage detector for cars, pedestrians and cyclists. Its LiDAR
input is a six-channel BEV map at 0.1 m per cell, with five height slices and
a density channel [arxiv:1712.02294 §3.1]. An image branch runs alongside it
[arxiv:1712.02294 §3.2]. Each anchor on a 0.5 m BEV grid is cropped from both
maps to 3 x 3 and averaged before the region proposal network
[arxiv:1712.02294 §3.3]. The second stage crops each proposal from both maps to
7 x 7 and averages again. The box is coded with four BEV corners and two
heights, and an angle vector gives the heading [arxiv:1712.02294 §3.4]. The
camera enters only through these crops. Key results, author-reported on KITTI:

- Test, car 3D AP at easy, moderate and hard: 81.94, 71.88 and 66.38 for the
  feature-pyramid model, at about 0.1 s per frame [arxiv:1712.02294 tab. 2]
  [arxiv:1712.02294 §4].
- Proposal recall for pedestrians and cyclists at 1024 proposals is higher
  with the image fused into the proposal network than with BEV features alone:
  by 10.1% and 8.6% in the authors' figure, without the feature pyramid
  [arxiv:1712.02294 §4] [arxiv:1712.02294 fig. 5].

Card: [Joint 3D Proposal Generation and Object Detection from View Aggregation](/papers/1712.02294).

### Object-point dropping as a training choice

This is a training-time augmentation for the LiDAR stream, not a separate
representation. It removes all points inside ground-truth boxes with a
probability, to mimic an object that returns no laser light [arxiv:2205.13790
§4.4.1]. Its effect depends on the model: it lifts the fused models, but it
lowers the vanilla TransFusion LiDAR-camera baseline from 38.1 to 37.2 mAP
[arxiv:2205.13790 tab. 4]. The paper suggests missing foreground points give
wrong supervision for that model [arxiv:2205.13790 §4.4.1].

### Camera-only polar grid without depth prediction

What it is: six surround cameras feed a polar BEV grid indexed by radius and
azimuth. Each image column is turned into polar rays by cross-plane
attention, at three scales. A deformable-attention encoder mixes the cells,
and a decoder with learned queries predicts boxes. Heading and velocity are
measured relative to the object's azimuth [arxiv:2206.15398 §3] [arxiv:2206.15398
§3.4]. The radius is not computed from an estimated depth; the model learns it
through attention [arxiv:2206.15398 §3.1]. Key results, author-reported on
nuScenes validation:

- Prototype setting, ResNet-101 initialised from FCOS3D: 39.6 mAP and 45.8
  NDS, against 37.5 and 44.8 for BEVFormer-S [arxiv:2206.15398 tab. 3].
- Improved setting, VoVNet-V2-99 with DD3D pretraining and extra data: 50.0
  mAP and 56.2 NDS, against 47.8 and 53.4 for Ego3RT [arxiv:2206.15398 tab. 3]
  [arxiv:2206.15398 §4].
- The authors' own ablation: polar features with a Cartesian head give 38.5
  mAP, against 38.1 for Cartesian features [arxiv:2206.15398 tab. 2a]. Three
  polar scales add 0.5 mAP over one scale, from 39.1 to 39.6 [arxiv:2206.15398
  tab. 2c].

Card: [PolarFormer: Multi-camera 3D Object Detection with Polar Transformer](/papers/2206.15398).

### Camera-only learned grid with temporal history

What it is: six surround cameras and no LiDAR. A 200 x 200 grid of learnable
queries, each cell 0.512 m, is updated by six encoder layers [arxiv:2203.17270
§3.1] [arxiv:2203.17270 §4.2]. Each layer runs temporal self-attention over the
current queries and the previous grid, then spatial cross-attention into the
camera features, then a feed-forward block [arxiv:2203.17270 §3.1]. Spatial
cross-attention projects a column of fixed reference heights above each cell
into the cameras, and samples features only in the views where a point lands
[arxiv:2203.17270 §3.3]. The previous grid is shifted
by ego motion before use [arxiv:2203.17270 §3.4]. Key results, author-reported
on nuScenes:

- Test, ResNet-101 backbone: 53.5 NDS, against 46.2 for the BEVFormer-S
  variant [arxiv:2203.17270 tab. 1]. Test, with a VoVNet-99 backbone
  pre-trained on depth estimation with extra data: 56.9 NDS
  [arxiv:2203.17270 tab. 1]. The like-for-like comparison is the ResNet-101
  row.
- Velocity error on test: mAVE 0.435 for the full model, against 0.925 for
  BEVFormer-S, both ResNet-101 [arxiv:2203.17270 tab. 1].
- Validation, ResNet-101: 51.7 NDS and 41.6 mAP [arxiv:2203.17270 tab. 2].
- Frames in training: NDS 0.448 with one frame and 0.517 with four
  [arxiv:2203.17270 tab. 7].

Card: [BEVFormer: Learning Bird's-Eye-View Representation from Multi-Camera Images via Spatiotemporal Transformers](/papers/2203.17270).

### Separate maps with cross-modal interaction

What it is: the LiDAR BEV map and the image features are kept as two
representations for the whole network [arxiv:2208.11112 §3]. The encoder has
two layers. In each, a LiDAR cell attends to the camera pixels its pillar
projects to, and the BEV map is warped into each camera with a depth map
completed from LiDAR points [arxiv:2208.11112 §3.1]. Each modality also
attends to its own neighbourhood [arxiv:2208.11112 §3.1]. The decoder refines
200 object queries, and alternate layers pool a 7 x 7 region from the camera
image and from the LiDAR BEV map [arxiv:2208.11112 §3.2] [arxiv:2208.11112
§4.2]. Key results, author-reported:

- Validation, base model with ResNet-50: 69.9 mAP and 72.6 NDS against 65.1
  and 70.1 for TransFusion-L, and 67.9 and 71.0 for BEVFusion (Liang et al.)
  [arxiv:2208.11112 tab. 1].
- Test, base model: 70.8 mAP and 73.4 NDS. The paper lists BEVFusion (Liang et
  al.) at 69.2 and 71.8 with Swin-Tiny [arxiv:2208.11112 tab. 1]. The backbones
  differ, so this comparison mixes two factors.
- Decoder alternating image and LiDAR layers gives 69.9 mAP on validation,
  against 69.2 when every layer reads only the LiDAR map [arxiv:2208.11112
  tab. 3].
- Encoder with two layers gives 69.9 mAP, against 66.4 with no encoder
  [arxiv:2208.11112 tab. 4].

Card: [DeepInteraction: 3D Object Detection via Modality Interaction](/papers/2208.11112).

### BEV lane masks for lane topology (TopoFG)

What it is: a camera-only model for which lanes connect, not a detector. Six
or seven cameras feed a BEVFormer-style encoder that produces the BEV features
[arxiv:2511.12590 §3.1]. Each lane query predicts one BEV lane mask, and a
mask-weighted sine-cosine grid encoding is added to the query as a spatial
prior [arxiv:2511.12590 §3.2] [arxiv:2511.12590 eq. 2]. The decoder's
deformable attention takes its reference points from that mask
[arxiv:2511.12590 §3.3]. The released config uses a 100 x 200 BEV grid, which
the paper does not state [code: projects/configs/topofg_r50_8x1_24e_olv2_subset_A.py#L42-L43].
Key results, author-reported on OpenLane-V2 subset_A with ResNet-50
[arxiv:2511.12590 tab. 1]:

- OLS 48.0, against 44.1 for TopoLogic. Adding the three modules in turn gives
  45.4, 45.8 and 48.0 [arxiv:2511.12590 tab. 3].
- The mask-based global spatial prior alone gives OLS 45.2, against 44.1 for
  the baseline, and the full prior module gives 45.4 [arxiv:2511.12590 tab. 4].
- The paper reports no seeds or variance, so a gap of a few tenths of a point
  is not reliable [arxiv:2511.12590 tab. 4].

Card: [Fine-Grained Representation for Lane Topology Reasoning](/papers/2511.12590).

### Autoregressive BEV forecast with ego-motion memory (Drive-OccWorld)

What it is: a camera-only world model that forecasts 4D occupancy and flow.
A BEVFormer-style encoder turns the multi-view images into BEV embeddings
[arxiv:2408.14197 §3.2]. Each embedding in the memory is layer-normalised
without learned affine terms, then rescaled and shifted by parameters derived
from a condition [arxiv:2408.14197 eq. 5] [arxiv:2408.14197 §3.2]. The paper
names three conditions: semantic labels, ego motion and agent motion. The
released configs turn on ego motion only [code:
projects/configs/inflated/action_condition_GMO.py#L164-L175]. A decoder with
learnable BEV queries reads the memory, and a 200 x 200 grid with 16 height
bins is decoded into occupancy [arxiv:2408.14197 app. C.3]. The action enters
through cross-attention. The paper lists velocity, steering, trajectory and
command as action types [arxiv:2408.14197 §3.3]. Key results, author-reported
on nuScenes [arxiv:2408.14197 tab. 1]:

- Inflated occupancy, mIoU at 2 s: 36.3 for Drive-OccWorld, against 26.8 for
  Cam4DOcc.
- Open-loop planning, NoAvg protocol, average L2: 0.85 m, against 1.03 m for
  UniAD [arxiv:2408.14197 tab. 5]. The planning rows are not reproducible from
  the released configs (see Contradictions).

Card: [Driving in the Occupancy World: Vision-Centric 4D Occupancy Forecasting and Planning via World Models for Autonomous Driving](/papers/2408.14197).

### Residual BEV forecast with feature alignment (IR-WM)

What it is: a camera-only world model with the same encoder family. A
BEVFormer-based encoder builds the BEV state from the past and current frames
[arxiv:2510.16729 §3.2.1]. The future predictor does not output the next state.
It outputs a change, which is added to the previous state [arxiv:2510.16729
eq. 6] [arxiv:2510.16729 §3.2.2]. Before the state goes back into memory, an
alignment module rescales its features with parameters from a predicted
semantic occupancy map and from the ego transform [arxiv:2510.16729 §3.2.2].
The authors say this slightly reduces error build-up over time [arxiv:2510.16729
§4.4] [arxiv:2510.16729 tab. 8]. The planner reads the un-aligned state
[arxiv:2510.16729 §3.2.3]. The default coupling uses only the generated BEV
features for planning, and occupancy is an auxiliary output [arxiv:2510.16729
§3.2.4]. Key results, author-reported on nuScenes:

- Inflated occupancy, IoU at 2 s: 37.2 against 36.3 for Drive-OccWorld
  [arxiv:2510.16729 tab. 1].
- Fine-grained occupancy on nuScenes-Occupancy, IoU at 2 s: 14.5 against 12.0
  [arxiv:2510.16729 tab. 1].
- Open-loop planning, average L2: 0.53 m against 0.85 m for Drive-OccWorld
  [arxiv:2510.16729 tab. 4].
- Feature alignment, per-class IoU on four classes: gains of 0.2 to 0.4
  [arxiv:2510.16729 tab. 8].

Card: [Vision-Centric 4D Occupancy Forecasting and Planning via Implicit Residual World Models](/papers/2510.16729).

### BEV raster as observation for a model-based RL agent (VDD)

What it is: a reinforcement-learning agent, not a detector. Its observation is
two channels of 128 x 128 cells, one for road geometry and navigation, one for
surrounding vehicles [arxiv:2512.02417 §5.1.1]. The encoder turns each frame
into a discrete latent, and a recurrent state is updated from the previous
latent and the previous ego state [arxiv:2512.02417 §4.1.1]. The paper assumes the BEV raster is available from
perception and does not model how it is produced [arxiv:2512.02417 §5.1.1].
The ego vehicle's dynamics are a separate model, and the policy outputs a goal
that a fixed controller turns into an action [arxiv:2512.02417 §4.2.1]. Key
results, author-reported in MetaDrive with traffic density 0.35
[arxiv:2512.02417 tab. 1]:

- Roundabout, success rate: 0.70 against 0.53 for DreamerV3. The roundabout
  reward is 163.82 against 150.64 [arxiv:2512.02417 tab. 1].
- Intersection, success rate: 0.88 against 0.91 for DreamerV3, so this variant
  is slightly lower there [arxiv:2512.02417 tab. 1].
- Changed mass and maximum steering: the robustness study is figure-only, and
  the text says VDD is stable across mass changes [arxiv:2512.02417 fig. 9]
  [arxiv:2512.02417 §5.2.4].

Card: [Vehicle Dynamics Embedded World Models for Autonomous Driving](/papers/2512.02417).

### Roadside BEV summary sent over a link (UniV2X)

What it is: a cooperative camera-only planner. The roadside unit runs a
BEVFormer-style encoder, then sends four items: agent queries with ids and
reference points, lane queries after low-score removal, and one occupancy map
with a flow that gives its future values [arxiv:2404.00717 § Data generation].
The vehicle does not receive the BEV feature. It matches roadside agent
queries to its own with the Hungarian method on reference-point distance,
keeps unmatched roadside queries, and takes the maximum of the two occupancy
maps [arxiv:2404.00717 § Cross-view query matching] [arxiv:2404.00717 §
Cross-view occupancy fusion]. The paper's latency compensation uses a
predicted query flow, which the released code does not contain
[arxiv:2404.00717 § Paper vs code]. Key results, author-reported on DAIR-V2X,
averaged over 2.5, 3.5 and 4.5 s [arxiv:2404.00717 tab. 2]:

- Collision rate 0.34%, against 0.89% with no fusion.
- Planning L2 3.48 m, against 3.44 m with no fusion and 3.30 m for BEV feature
  fusion. The paper does not claim an L2 win.
- Transmission 8.09e5 BPS, against 8.19e7 for BEV feature fusion. The paper
  does not define the unit in the table.

Card: [End-to-End Autonomous Driving through V2X Cooperation](/papers/2404.00717).

### Two-branch BEV fusion for LiDAR occupancy (OccMamba)

What it is: a LiDAR-only network that predicts voxel semantics on a 256 x 256
x 32 grid, with 0.2 m voxels [arxiv:2408.10618 §5.1]. A semantic branch runs
sparse 3D convolutions and projects its voxels to BEV after each stage, with a
Mamba block on the BEV map [arxiv:2408.10618 §3.1]. A geometric branch runs
dense 3D convolutions with a Mamba block after each stage, then flattens height
into channels to form BEV features. A BEV U-Net fuses the three scales of both
branches and outputs the voxel classes [arxiv:2408.10618 §3.1]. The code uses
sparse convolutions for the semantic branch [code:
networks/semantic_segmentation.py#L119-L126]. Key results, author-reported on
SemanticKITTI:

- Hidden test: IoU 59.9 and mIoU 25.0, against 56.6 and 24.4 for Co-Occ, and
  59.7 IoU and 24.2 mIoU for SSC-RS [arxiv:2408.10618 tab. 2]. The throughput
  is 22.1 FPS, and the paper does not name the hardware [arxiv:2408.10618 tab. 2].
- Validation: IoU 58.6 and mIoU 25.2, with 23.8 M parameters and 3.5 GB of
  memory [arxiv:2408.10618 tab. 3].
- Ablation on validation mIoU: 24.1 without the semantic Mamba block, 24.7
  without the geometric one, and 25.2 for the full model [arxiv:2408.10618 tab. 4].

Card: [OMEGA: Efficient Occlusion-Aware Navigation for Air-Ground Robot in Dynamic Environments via State Space Model](/papers/2408.10618).

### Range-image detector with no BEV grid (LaserNet)

What it is: a LiDAR-only, single-stage detector that runs on the sensor's own
range image, with one row per laser and one column per azimuth bin
[arxiv:1903.08701 §3.1]. Each cell carries range, height, azimuth, intensity
and a valid flag [arxiv:1903.08701 §3.1]. A fully convolutional backbone keeps
the vertical resolution and downsamples only horizontally [arxiv:1903.08701
§3.2]. Each point predicts class probabilities and a mixture of box
distributions, each with a spread [arxiv:1903.08701 §3.3]. Mean-shift
clustering on a 0.5 m bin grid merges the boxes per class and per component
[arxiv:1903.08701 §3.4], and an NMS threshold set by the predicted spread
prunes duplicates [arxiv:1903.08701 §3.6]. Key results, author-reported:

- ATG4D validation, vehicle AP0.7 over 0 to 70 m: 85.34, against 85.17 for
  ContFuse with LiDAR and RGB, and 83.13 for ContFuse with LiDAR alone
  [arxiv:1903.08701 tab. 1]. The paper does not say how to obtain ATG4D
  [arxiv:1903.08701 §4.1].
- Ablation on ATG4D: a mixture of boxes gives 81.80 against 80.92 for a single
  box, with the same fixed threshold and hard NMS. The adaptive threshold with
  soft NMS gives 85.34 [arxiv:1903.08701 tab. 2].
- KITTI runtime on a 1080 Ti: 30 ms total and 12 ms forward, against 62 ms
  total for PIXOR [arxiv:1903.08701 tab. 3]. The total includes pre- and
  post-processing, and the source of the baseline timings is not stated
  [arxiv:1903.08701 §4.3].
- KITTI validation, BEV vehicle AP0.7 at moderate difficulty: 73.77, against
  83.70 for PIXOR++ [arxiv:1903.08701 tab. 4]. The authors say it trails BEV
  detectors there [arxiv:1903.08701 §4.4].

Card: [LaserNet: An Efficient Probabilistic 3D Object Detector for Autonomous Driving](/papers/1903.08701).

## When to use which

| Situation | Use | Why |
|---|---|---|
| LiDAR is reliable, full 360 degree view, and latency or memory is tight | LiDAR-only BEV head | Fusion adds 3.0 mAP to TransFusion-L on validation [arxiv:2205.13790 tab. 1], and the camera branch costs roughly 1.2 to 1.3 s more per frame on the paper's hardware [arxiv:2205.13790 tab. 13] |
| LiDAR has a limited field of view, or drops points on dark or low-reflectance objects | Camera lift plus LiDAR fusion | Fused models score well above LiDAR alone when points are cropped or dropped: 41.5 against 19.0 mAP at plus or minus 60 degrees [arxiv:2205.13790 tab. 3] [arxiv:2205.13790 tab. 4] |
| Weak LiDAR, but the model must still work when the camera fails | Camera lift plus LiDAR fusion | With a front camera removed or frozen, the fused model stays close to clean accuracy [arxiv:2205.13790 tab. 5] |
| LiDAR only, and the box must cover the whole object even when proposals are off | LiDAR BEV map in a graph refiner (BADet) | Reports 81.61 AP3D against 81.62 for Voxel R-CNN on KITTI test, Car moderate, with a higher BEV score [arxiv:2104.10330 tab. 1]. The paper reports 140.36 ms per frame on a GTX 1080 Ti, with the graph step at 61.98 ms of that [arxiv:2104.10330 tab. 8] |
| One camera at run time, no LiDAR on the vehicle, and LiDAR available to make depth labels for training | Monocular lift with a depth distribution (CaDDN) | Car moderate 13.41 AP on KITTI test, one frame, against 11.72 for D4LCN [arxiv:2103.01100 tab. 1]. The depth labels come from LiDAR, and the released code reads precomputed depth maps rather than building them [code: docs/GETTING_STARTED.md#L12]. The results give no runtime figure |
| Two sensors on KITTI-style data, and the official TensorFlow 1.x code is acceptable | Two-view proposal crops (AVOD) | Car AP3D 71.88 at moderate difficulty on KITTI test, at about 0.1 s per frame [arxiv:1712.02294 tab. 2]. The official code is TensorFlow 1.x and will not run unmodified on TensorFlow 2 [code: avod/core/feature_extractors/bev_vgg_pyramid.py#L5] |
| The output must feed one standard detection head | Shared grid (BEVFusion) | Both streams end on one BEV map that a standard head reads [arxiv:2205.13790 §3.3] |
| No LiDAR on the vehicle, six cameras | Camera-only polar grid (PolarFormer) | The only input is the cameras. Validation prototype: 39.6 mAP against 37.5 for BEVFormer-S [arxiv:2206.15398 tab. 3]. The paper reports no runtime or memory figures, so measure before choosing it. The improved setting needs extra pretraining data whose licence this card does not state |
| No LiDAR, six cameras, and velocity or frame-to-frame context matters | Camera-only learned grid with temporal history (BEVFormer) | Test NDS 53.5 with ResNet-101 [arxiv:2203.17270 tab. 1]. Velocity error (mAVE) 0.435 for the full model, against 0.925 for the static BEVFormer-S [arxiv:2203.17270 tab. 1]. Default latency on a V100 at 900 x 1600 is 391 ms backbone, 130 ms BEV encoder and 19 ms head [arxiv:2203.17270 tab. 6]. The 56.9 test result uses extra pre-training, so compare the ResNet-101 row |
| Accuracy matters most, LiDAR and cameras both available, and calibration and slow depth completion are acceptable | Separate maps with interaction (DeepInteraction) | Base test score 70.8 mAP and 73.4 NDS [arxiv:2208.11112 tab. 1]. It runs at 2.6 FPS on a V100 and 4.9 FPS on an A100 [arxiv:2208.11112 tab. 2]. The authors name calibration dependence and efficiency as limitations [arxiv:2208.11112 app. A.3] |
| Choosing the LiDAR stream inside the fused model | TransFusion-L, then CenterPoint, then PointPillars | Fused mAP on validation: 67.9, 64.2, 53.5 [arxiv:2205.13790 tab. 1]. PointPillars gains most from the camera, but still ends lowest |
| Lane connectivity matters, for example at intersections, with six or seven cameras and no LiDAR | BEV lane masks for lane topology (TopoFG) | OLS 48.0 on OpenLane-V2 subset_A against 44.1 for TopoLogic [arxiv:2511.12590 tab. 1]. The paper gives no runtime or memory figure, and the released config uses 200 lane queries, so the connectivity head scores 200 x 200 pairs [code: projects/configs/topofg_r50_8x1_24e_olv2_subset_A.py#L144] |
| LiDAR only, the range image is the natural input, and a large labelled dataset is available to train a distribution head | Range-image detector with no BEV grid (LaserNet) | Reports 30 ms total on KITTI, against 62 ms for PIXOR [arxiv:1903.08701 tab. 3]. On KITTI it trails BEV detectors: 73.77 moderate AP0.7, against 83.70 for PIXOR++ [arxiv:1903.08701 tab. 4]. The authors tie this to data size [arxiv:1903.08701 §4.5] [arxiv:1903.08701 §5] |
| Memory budget is tight | LiDAR-only, or check the fused memory first | Fused TransFusion-L uses 18086 MB against 12536 MB for LiDAR only, on the paper's V100 test [arxiv:2205.13790 tab. 13] |
| Camera-only occupancy forecast, and the released occupancy configs are enough | Autoregressive BEV forecast (Drive-OccWorld) | Inflated occupancy mIoU at 2 s is 36.3, against 26.8 for Cam4DOcc [arxiv:2408.14197 tab. 1]. The released configs cover occupancy only, with no planning config [code: projects/configs/inflated/action_condition_GMO.py#L43] |
| Camera-only planning on a forecast, with the best reported plan error | Residual BEV forecast with feature alignment (IR-WM) | Average planning L2 0.53 m, against 0.85 m for Drive-OccWorld [arxiv:2510.16729 tab. 4]. As read, the default training path on the `ir-wm` branch raises a KeyError, and the V2 class returns the missing key [code: projects/mmdet3d_plugin/bevformer/detectors/drive_occworld.py#L639] [code: projects/mmdet3d_plugin/bevformer/detectors/drive_occworldV2.py#L397-L400] |
| Future features are too costly at inference | IR-WM with the fully decoupled planner | The planner reads only the current BEV state. Average L2 is 0.87 m, against 0.53 m for the default, with latency 558 ms against 706 ms, on a device the paper does not name [arxiv:2510.16729 tab. 5] |
| Compute is tight, and a smaller BEV grid is acceptable | IR-WM at 128 x 128 | Fine-grained IoU at 2 s falls from 14.5 at 200 x 200 to 10.8 at 128 x 128 [arxiv:2510.16729 tab. 9]. The paper gives no speed figure for the smaller grid |
| Reinforcement learning on a top-down observation, and the vehicle's mass or steering limit may change after training | BEV raster with a model-based RL agent (VDD) | Roundabout success 0.70 against 0.53 for DreamerV3, but intersection success is 0.88 against 0.91 [arxiv:2512.02417 tab. 1]. The robustness study is figure-only [arxiv:2512.02417 §5.2.4], and the paper gives no wall-clock or memory figure. The paper leaves real-world performance open [arxiv:2512.02417 §6]. No official code was found |
| Cooperative driving over a link too narrow for dense BEV features, with roadside cameras and the vehicle's own cameras | Roadside BEV summary over a link (UniV2X) | Collision 0.34% against 0.89% with no fusion, at 8.09e5 BPS against 8.19e7 for BEV feature fusion [arxiv:2404.00717 tab. 2]. Planning L2 is 3.48 m, worse than 3.30 m for BEV feature fusion [arxiv:2404.00717 tab. 2]. The latency compensation step is not in the released code [arxiv:2404.00717 § Paper vs code] |
| LiDAR-only semantic occupancy on a voxel grid, and a published network is enough without the planner | Two-branch BEV fusion (OccMamba) | IoU 59.9 and mIoU 25.0 on the SemanticKITTI hidden test [arxiv:2408.10618 tab. 2]. The repository has no LICENSE file, so its code cannot be reused as is [arxiv:2408.10618 § Paper vs code]. The planner is not in the repository |

The latency figures are not comparable across cards. BEVFusion's are batch
size 1 on one V100 with a CPU, including the projection step, and
DeepInteraction's are throughput on several GPUs. Drive-OccWorld's are on one
A6000 [arxiv:2408.14197 tab. 9], and IR-WM's device is not stated
[arxiv:2510.16729 tab. 5]. Measure on your own hardware before deciding.

## Implementation sketch

Language-agnostic outline of the camera-lift core, with its fusion step. It
follows the shared-grid design, the one with a camera stream that differs
from a LiDAR-only pipeline. Polar and interaction designs replace the splat
step, as the notes below say.

```pseudocode
# Camera lift into a BEV grid  [arxiv:2205.13790 §3.1]
def camera_bev(images, lidar2img):
    # Per-pixel depth distribution over bins, plus context features
    depth_probs = softmax(depth_head(feats), dim=depth_bins)
    context = context_head(feats)
    # Frustum: depth-weighted features, one slice per depth bin
    frustum = depth_probs[:, None] * context[:, :, None]
    # Project each frustum cell to ego coordinates, sum into the grid
    grid = splat_sum(frustum, lidar2img)  # (C, Z, H_bev, W_bev)
    # Fold height into channels; keeps full horizontal resolution
    bev = reshape(grid, (C * Z, H_bev, W_bev))
    return bev_encoder(bev)

# Fusion on the shared grid  [arxiv:2205.13790 §3.3] [arxiv:2205.13790 eq. 2]
def fuse(cam_bev, lidar_bev):
    x = conv3x3(concat([cam_bev, lidar_bev], dim=channels))
    gate = sigmoid(linear(global_avg_pool(x)))
    return gate * x
```

Notes on where the common core varies:

- The camera and LiDAR BEV grids must agree in size. In BEVFusion the camera
  grid uses 0.6 m cells and the LiDAR voxels are 0.075 m, but the two BEV
  maps end up the same size, so re-tuning one stream without the other
  changes the BEV size [arxiv:2205.13790 tab. 3] [arxiv:2205.13790 §4.1].
- The depth range (4 to 44 m in 1 m bins) and the grid extent are code
  defaults, not paper values. The paper does not say what happens beyond the
  depth range [arxiv:2205.13790 app. B.1].
- The camera frustum is built on the original 900 x 1600 frame while the
  network input is 448 x 800. The `lidar2img` matrices are not rescaled with
  the resize, so changing the input scale without also changing the
  downsampling breaks the match [arxiv:2205.13790 §4.1].
- PolarFormer replaces the frustum splat with cross-plane attention. Each
  polar ray queries the features of one image column, and three polar scales
  are kept [arxiv:2206.15398 §3.1] [arxiv:2206.15398 §4].
- DeepInteraction does not build a camera BEV map. It keeps image features in
  image space and reads them with projected 7 x 7 regions, and it warps the
  LiDAR BEV map into the cameras using completed depth [arxiv:2208.11112
  §3.1] [arxiv:2208.11112 §3.2]. Calibration errors propagate into both
  directions [arxiv:2208.11112 app. A.3].
- BEVFormer writes no splat. Its grid is learned queries, and camera features
  are read by deformable attention at fixed reference heights above each cell
  [arxiv:2203.17270 §3.3]. The previous grid is rotated by the change in yaw and
  shifted by ego translation before use [code:
  projects/mmdet3d_plugin/bevformer/modules/transformer.py#L143-L156]. Inference
  is stateful: frames must run in time order [code:
  projects/mmdet3d_plugin/bevformer/detectors/bevformer.py#L243-L251].
- AVOD keeps the LiDAR map at 0.1 m per cell. Each anchor and proposal is
  cropped from both views and averaged, so the image never reaches the grid
  [arxiv:1712.02294 §3.1] [arxiv:1712.02294 §3.3]. Its height bands differ
  between paper and code, so check them before reusing the input
  [code: avod/configs/pyramid_cars_example.config#L157-L159].
- CaDDN's depth head outputs D+1 values. The extra out-of-range bin is
  supervised but dropped before the frustum, so the in-range weights do not sum
  to 1 for each pixel. The paper's appendix describes it this way
  [arxiv:2103.01100 app. B] [code: pcdet/models/backbones_3d/ffe/depth_ffe.py#L86-L88].
- The paper describes depth labels from LiDAR projection followed by depth
  completion [arxiv:2103.01100 §3.4]. The released code loads precomputed
  depth maps and does not contain the completion step [code:
  pcdet/datasets/kitti/kitti_dataset.py#L98-L113]. Label generation is
  therefore not reproducible from that repository alone.
- TopoFG's spatial prior is a mask-weighted grid encoding, and the paper
  leaves its normalisation undefined. The released code divides by the largest
  absolute value across the whole batch, so one sample's prior depends on the
  others in the batch [arxiv:2511.12590 eq. 2] [code:
  projects/topofg/models/dense_heads/topofg_head.py#L287]. Reproduce the
  batch-level scaling only if you need the paper's numbers.
- BADet has no camera lift. Its BEV map comes from the LiDAR stream alone
  [arxiv:2104.10330 §3.1.2], and it samples that map at each proposal's
  footprint [arxiv:2104.10330 §3.2.2]. The radius of the graph and the cap on
  neighbours are not in the paper; the code uses 0.1 m and 256 neighbours
  [code: mmdet/models/gnns/gnn.py#L100]. Treat them as code defaults, not
  paper values.
- Drive-OccWorld's memory is normalised by ego motion, and its released
  configs take the action from the CAN bus, not from the predicted trajectory
  the paper describes [arxiv:2408.14197 §3.2] [code:
  projects/mmdet3d_plugin/bevformer/dense_heads/world_head_base.py#L309-L317].
  The predicted-trajectory action therefore has no released path.
- IR-WM's state update is the previous state plus a predicted change, and the
  planner reads the state before alignment [arxiv:2510.16729 §3.2.2] [arxiv:2510.16729
  §3.2.3]. The code's planning loss takes a Euclidean distance, not a squared
  one [code: projects/mmdet3d_plugin/bevformer/losses/planning_loss.py#L21-L27].
- VDD has no camera lift and no splat. The BEV raster is a fixed two-channel
  input to an encoder, so the camera-lift core above does not apply
  [arxiv:2512.02417 §5.1.1]. Its CARLA run replaces the BEV input with a route
  map and a front camera, and the decoder then reconstructs a BEV image of the
  surrounding vehicles [arxiv:2512.02417 §5.1.1].

## Contradictions

Papers disagree on a few numbers and design choices. Each side is cited, and
none is resolved here.

- **LiDAR baseline on validation.** BEVFusion reports TransFusion-L at 64.9
  mAP and 69.9 NDS [arxiv:2205.13790 tab. 1]. DeepInteraction reports the same
  model at 65.1 mAP and 70.1 NDS in its main table [arxiv:2208.11112 tab. 1],
  and 70.2 NDS in its per-class table [arxiv:2208.11112 tab. 6]. The gain from
  fusion therefore depends on which paper's baseline you use.
- **Depth from images.** BEVFusion predicts a depth distribution for each
  pixel and uses it to lift features into the grid [arxiv:2205.13790 §3.1].
  PolarFormer argues that dense depth estimation is costly and error-prone,
  and learns the radius through attention instead [arxiv:2206.15398 §1]
  [arxiv:2206.15398 §3.1]. DeepInteraction predicts no depth from images. Its
  depth comes from LiDAR points [arxiv:2208.11112 §3.1]. BEVFormer samples
  camera features at fixed reference heights rather than at predicted depths
  [arxiv:2203.17270 §3.3]. CaDDN predicts a depth distribution from the image
  and trains it jointly with the detector, using LiDAR-derived labels. On KITTI
  val, Car moderate, a separately trained CaDDN depth network gives 12.26 AP and
  joint training gives 13.71 [arxiv:2103.01100 tab. 4]. The same table gives
  10.18 and 11.04 for separately trained BTS and DORN depth [arxiv:2103.01100
  tab. 4]. These are the paper's own runs in one pipeline, and they do not test
  a design without depth. These are design positions, and no single experiment
  in the cards settles them.
- **Within CaDDN.** The paper gives a focal alpha of 3.25 for foreground and
  0.25 for background [arxiv:2103.01100 §3.5]. The code uses a single alpha of
  0.25 and multiplies the loss by 13 for foreground and 1 for background
  [code: tools/cfgs/kitti_models/CaDDN.yaml#L58-L61]. The paper does not say
  which form produced its reported numbers.
- **Polar grid versus Cartesian.** PolarFormer argues a polar grid matches the
  imaging geometry better [arxiv:2206.15398 §1]. The gain it reports over a
  Cartesian baseline is small: 0.4 mAP for polar features with a Cartesian
  head [arxiv:2206.15398 tab. 2a], and 1.1 mAP for the full model against
  CenterPoint on a Cartesian grid [arxiv:2206.15398 tab. 2a]. These are the
  paper's own ablations on one backbone, so they do not show how much of the
  gain the polar grid alone accounts for.
- **Within BEVFusion.** The main text says the fusion stage runs 9 epochs,
  while the appendix gives 6 epochs for TransFusion-L and CenterPoint
  [arxiv:2205.13790 §4.1] [arxiv:2205.13790 app. B.1]. The paper describes a
  per-object draw for object-point dropping, while the code makes one draw per
  frame and drops all points in every ground-truth box [arxiv:2205.13790
  §4.4.1] [code: mmdet3d/datasets/pipelines/transforms_3d.py#L990-L994]. The
  code also adds a depth loss from projected LiDAR points, which the paper
  does not describe [code: mmdet3d/models/detectors/bevf_transfusion.py#L157-L159].
  The card records these in full under "Paper vs code".
- **Within DeepInteraction.** The paper says its two-stage training freezes
  only the image branch in the second stage, while the code also freezes most
  LiDAR modules [arxiv:2208.11112 §4.2] [code: Fusion_0075_refactor.py#L130-L131]. The
  reproduced numbers depend on which freezing rule is used. The paper's
  decoder depth also differs from the released configuration
  [arxiv:2208.11112 §4.2].
- **Fusion against LiDAR alone.** The survey's summary, drawn from KITTI
  results, says multimodal fusion still trails point cloud methods
  [arxiv:2106.10823 §3.3] [arxiv:2106.10823 tab. 6]. BEVFusion reports that
  fusion beats its LiDAR-only baseline on nuScenes validation [arxiv:2205.13790
  tab. 1]. The survey is from 2021 and BEVFusion from 2022, and the two use
  different benchmarks, so the statements may not be about the same setting.
  No single experiment in the cards settles it.
- **Within TopoFG.** The text says the global spatial prior improves all
  metrics [arxiv:2511.12590 §4.4]. Table 4 shows lower lane-topology scores
  for the full prior than for the local prior alone: 26.1 against 26.7 on
  TOP_ll and 26.6 against 27.3 on TOP_lt [arxiv:2511.12590 tab. 4]. The overall
  score still rises, so the text overstates the table on these two metrics.
- **Drive-OccWorld's planning baseline.** Both world-model cards report
  Drive-OccWorld at 0.85 m average planning L2 under the NoAvg protocol
  [arxiv:2408.14197 tab. 5] [arxiv:2510.16729 tab. 4]. The Drive-OccWorld
  card finds that the released configs cannot reproduce that row [code:
  projects/configs/inflated/action_condition_GMO.py#L43]. IR-WM does not say
  whether it re-ran the baseline or copied it [arxiv:2510.16729 tab. 4].
- **Real-time claim in Drive-OccWorld.** The card records that the paper
  calls its lowest configuration real-time. The same paper's Table 9 gives
  140 ms of encoder time and 190 ms of decoder time for that configuration on
  an A6000 [arxiv:2408.14197 tab. 9]. In that row the decoder takes longer
  than the encoder.
- **Horizon in IR-WM.** The text says four future timestamps. The fine-grained
  tables label the horizon 2 s, and the end-to-end tables label it 2.5 s
  [arxiv:2510.16729 §4.1.1] [arxiv:2510.16729 tab. 2] [arxiv:2510.16729 tab. 3].
  Compare numbers only within one table.

## Papers

- [BEVFusion: A Simple and Robust LiDAR-Camera Fusion Framework](/papers/2205.13790):
  a camera stream lifted into a BEV grid with predicted depth, fused with a
  LiDAR BEV map, and robust to LiDAR loss in author-reported tests.
- [PolarFormer: Multi-camera 3D Object Detection with Polar Transformer](/papers/2206.15398):
  camera-only detection on a polar BEV grid, with cross-plane attention and no
  dense depth estimation.
- [DeepInteraction: 3D Object Detection via Modality Interaction](/papers/2208.11112):
  separate LiDAR BEV and image representations that interact in an encoder and
  a decoder.
- [Joint 3D Proposal Generation and Object Detection from View Aggregation](/papers/1712.02294):
  AVOD, a LiDAR BEV map and an image cropped and averaged at each anchor and
  proposal, for cars, pedestrians and cyclists.
- [BEVFormer: Learning Bird's-Eye-View Representation from Multi-Camera Images via Spatiotemporal Transformers](/papers/2203.17270):
  camera-only learned BEV queries, with deformable spatial attention and a
  temporal grid carried over from earlier frames.
- [Categorical Depth Distribution Network for Monocular 3D Object Detection](/papers/2103.01100):
  a single camera lifted into a voxel grid with a predicted depth distribution,
  collapsed to BEV, with LiDAR-derived depth labels used only in training.
- [BADet: Boundary-Aware 3D Object Detection from Point Clouds](/papers/2104.10330):
  a LiDAR BEV map as one of three node sources in a graph refiner for
  two-stage detection.
- [Fine-Grained Representation for Lane Topology Reasoning](/papers/2511.12590):
  a BEV lane mask prior with one query per lane point, and a connectivity head
  on the first and last point of each lane.
- [3D Object Detection for Autonomous Driving: A Survey](/papers/2106.10823):
  a taxonomy of camera, LiDAR and fusion detectors, with the BEV collapse and
  the camera lift placed among them.
- [Driving in the Occupancy World: Vision-Centric 4D Occupancy Forecasting and Planning via World Models for Autonomous Driving](/papers/2408.14197):
  a camera-only world model whose BEV memory is normalised by ego motion, with
  occupancy forecasting and a planner that scores sampled trajectories.
- [Vision-Centric 4D Occupancy Forecasting and Planning via Implicit Residual World Models](/papers/2510.16729):
  a camera-only world model that predicts a residual BEV change per step, with
  feature alignment and a planner on the generated BEV features.
- [Vehicle Dynamics Embedded World Models for Autonomous Driving](/papers/2512.02417):
  a two-channel BEV raster as the observation of a Dreamer-style agent, with
  the ego dynamics modelled apart from the environment.
- [End-to-End Autonomous Driving through V2X Cooperation](/papers/2404.00717):
  a roadside BEV encoder whose output is sent as sparse queries and one
  occupancy map with flow, fused into the vehicle's planner.
- [OMEGA: Efficient Occlusion-Aware Navigation for Air-Ground Robot in Dynamic Environments via State Space Model](/papers/2408.10618):
  a LiDAR occupancy network with semantic and geometric BEV branches fused by
  a U-Net, using Mamba blocks in both branches.
- [LaserNet: An Efficient Probabilistic 3D Object Detector for Autonomous Driving](/papers/1903.08701):
  a LiDAR detector on the range image, with a mixture of box distributions per
  point, mean-shift merging and an adaptive NMS. It builds no BEV grid.
- [3D Object Detection for Autonomous Driving: A Comprehensive Survey](/papers/2206.09474):
  a 2022 survey that sorts LiDAR, camera and fusion detectors and compiles
  author-reported scores on KITTI, nuScenes and Waymo, with mixed splits.