DensePillarNet: Lightweight LiDAR Detector

Updated 7 July 2026

The paper replaces PillarNet-18's ResNet-based sparse convolution backbone with a dense-layer architecture tailored for sparse LiDAR data, achieving near-identical accuracy with fewer parameters.
DensePillarNet employs dense blocks with one-shot concatenation and stagewise growth rates, enhancing multi-scale feature reuse while lowering computational overhead.
It delivers a substantial reduction in model parameters and latency, positioning itself as a plug-and-play, efficiency-oriented backbone for real-time LiDAR detection.

Searching arXiv for the cited DensePillarNet paper and related pillar-based LiDAR detection work. DensePillarNet is a pillar-based 3D detector for LiDAR obtained by replacing the SpConv-ResNet-18 backbone of PillarNet-18 with the proposed Dense Backbone, while keeping the pillar encoder, multi-scale neck, and detection head unchanged. The method was introduced in “Rethinking Backbone Design for Lightweight 3D Object Detection in LiDAR” and is presented as a plug-and-play backbone substitution tailored to sparse point cloud data rather than dense image tensors. On nuScenes, the reported effect is a substantial reduction in model parameters and latency, with validation accuracy that is nearly identical to PillarNet and a test-set drop of about $2\%$ relative in NDS (Chandorkar et al., 1 Aug 2025).

1. Origin and problem setting

DensePillarNet is motivated by a structural limitation in many LiDAR 3D detectors that use 2D backbones: they often reuse VGG-based or ResNet-based image backbones, sometimes converted to sparse convolutions, even though these designs were not developed for sparse and irregular point-cloud-derived feature maps. In the PillarNet-18 baseline on nuScenes, the backbone alone has 1.78M parameters and 6.47 G FLOPs, and the broader concern is that on-board autonomous-driving stacks must allocate compute across detection, tracking, planning, and control under tight latency constraints (Chandorkar et al., 1 Aug 2025).

The DensePillarNet proposal addresses this by targeting the backbone rather than the full detector pipeline. The stated premise is that simply increasing stride harms fine details, while simply reducing channels weakens representational capacity. The alternative adopted here is to reduce output channels and compensate through feature reuse across layers. The paper further argues that this is particularly suitable for sparse LiDAR because each point can carry high information content and multiple receptive fields can help recover object structure under limited sampling (Chandorkar et al., 1 Aug 2025).

Within that framing, DensePillarNet is not a new encoder–neck–head design. It is a specific adaptation of PillarNet in which the backbone is replaced by a dense-layer-based architecture designed explicitly for LiDAR pseudo-images or voxel grids. The authors describe it as the first dense-layer-based backbone tailored specifically for 3D object detection from point cloud data (Chandorkar et al., 1 Aug 2025).

2. Dense Backbone: dense blocks, transition layers, and growth rate

The Dense Backbone is inspired by DenseNet, PeleeNet, and VoVNet, but modifies the aggregation pattern for 3D detection. Its basic unit is a Dense Block consisting of a stack of $3 \times 3$ convolutions, or sparse convolutions in the sparse case, followed by one-shot concatenation at the end rather than DenseNet-style layerwise concatenation. For an input $x_0$ , the block applies sequential convolutions

$x_1=f_1(x_0), \quad x_2=f_2(x_1), \dots, \quad x_L=f_L(x_{L-1}),$

and then aggregates them as

$x_{\text{concat}}=\operatorname{Concat}(x_0, x_1, \dots, x_L).$

This design preserves feature reuse and exposes deeper layers to multi-scale information, while reducing memory access cost relative to full DenseNet concatenation. The paper attributes three functions to this arrangement: multiple receptive fields through cascaded convolutions, reuse of features originating from the block input, and lower memory overhead than layerwise concatenation (Chandorkar et al., 1 Aug 2025).

Between dense blocks, a Transition Layer first compresses and blends the concatenated features with a $1 \times 1$ convolution,

$x_{\text{out}}=\operatorname{Conv}_{1\times 1}(x_{\text{concat}}),$

and then downsamples spatially. In DensePointPillars this uses average pooling with stride 2, whereas in DensePillarNet it uses strided sparse convolution because pooling is not well supported in SpConv libraries. This ordering is intended to aggregate before downsampling so that receptive field is preserved while spatial resolution is reduced for efficiency (Chandorkar et al., 1 Aug 2025).

Channel allocation is controlled by a growth rate $k$ , defined as the number of output channels of each $3 \times 3$ convolution inside a Dense Block. The backbone does not use the fixed $k=32$ convention of classic DenseNet. Instead it uses a stagewise growth-rate policy: initialize $3 \times 3$ 0 in the first Dense Block and double $3 \times 3$ 1 in each subsequent block. The ablation reported on nuScenes compares fixed $3 \times 3$ 2 to stagewise growth, and the stagewise setting is used in DensePillarNet because it improves NDS with only marginal overhead. The paper reports $3 \times 3$ 3 at NDS 67.38, 10.24M parameters, and 96.22G FLOPs, whereas stagewise $3 \times 3$ 4 yields NDS 67.81, 10.35M parameters, and 97.71G FLOPs (Chandorkar et al., 1 Aug 2025).

3. From PillarNet-18 to DensePillarNet

PillarNet is a pillar-based LiDAR detector whose pipeline consists of a pillar encoder, a sparse-convolutional 2D backbone, a high-capacity multi-scale neck, and a detection head. In the nuScenes configuration discussed for DensePillarNet, the head is a CenterPoint-style CenterHead. PillarNet had already become a strong real-time baseline and is identified in the source paper as widely used in follow-up works such as PillarNext, PillarNeSt, and FastPillars (Chandorkar et al., 1 Aug 2025).

DensePillarNet keeps the original PillarNet pipeline intact except for the backbone. The encoder remains identical to PillarNet’s pillar encoder, including voxelization or pillarization and per-pillar feature extraction. The ResNet-18-style sparse backbone is replaced by the Dense Backbone implemented with SpConv. The overall stage pattern and feature-map resolutions are kept aligned with the original network so that the interface to the neck is unchanged. The neck is the same multi-scale aggregation neck as in PillarNet-18, and the detection head is the same as the original PillarNet-18; for nuScenes, this means the CenterHead configuration used in CenterPoint, following the PillarNet paper (Chandorkar et al., 1 Aug 2025).

A consequence of this design is that DensePillarNet is explicitly plug-and-play. No changes are made to the pillar encoder, loss formulation, training pipeline, neck, or head. The same input–output shapes are maintained at each stage. The “dense” aspect therefore refers to dense-layer-based feature reuse inside the backbone, not to a redesign of the rest of the detector (Chandorkar et al., 1 Aug 2025).

The implementation details reported for nuScenes are also inherited with minimal alteration. The detection range is $3 \times 3$ 5 m in $3 \times 3$ 6 and $3 \times 3$ 7 m in $3 \times 3$ 8, with pillar size $3 \times 3$ 9 m in $x_0$ 0. Training uses PyTorch and mmdetection3d for 20 epochs on $x_0$ 1 Tesla A100 GPUs, with batch size 2, AdamW, initial learning rate $x_0$ 2, Cosine Annealing, and NMS threshold 0.1 for DensePillarNet. Data augmentation follows mmdetection3d and PillarNet defaults, and loss functions are standard for CenterHead rather than modified specifically for DensePillarNet (Chandorkar et al., 1 Aug 2025).

4. Computational profile and latency

The primary quantitative effect of the backbone replacement is concentrated in the backbone itself. On nuScenes, the reported backbone complexity changes from 1.78M parameters and 6.47G FLOPs in PillarNet to 0.69M parameters and 2.52G FLOPs in DensePillarNet. The neck and head remain unchanged at 7.51M / 69.93G and 1.75M / 25.21G respectively, so the backbone replacement accounts for most of the reduction in model size and runtime (Chandorkar et al., 1 Aug 2025).

Metric	PillarNet	DensePillarNet
Params (M)	14.57	10.35
FLOPs (G)	101.66	97.71
Latency (ms)	117	85
NDS (val)	67.39	67.81
mAP (val)	59.90	60.33

These numbers clarify an important point. Total FLOPs decrease only modestly because the neck dominates the computation, but latency still falls substantially, from 117 ms to 85 ms, corresponding to the reported $x_0$ 3 speedup. Parameter count falls from 14.57M to 10.35M, corresponding to the reported $x_0$ 4 reduction. The stated architectural reasons are narrower per-layer channels, strong feature reuse, one-shot aggregation instead of full DenseNet concatenation, and removal of redundancy in ResNet-style stages while preserving the spatial downsampling pattern (Chandorkar et al., 1 Aug 2025).

This also explains why additional backbone lightening alone has diminishing returns. The paper explicitly notes that for DensePillarNet the neck dominates FLOPs, so further reductions in full-model complexity would likely require modifications beyond the backbone (Chandorkar et al., 1 Aug 2025).

5. Detection accuracy and efficiency trade-offs

On the nuScenes validation set, DensePillarNet slightly improves on PillarNet: mAP rises from 59.90 to 60.33 and NDS rises from 67.39 to 67.81. On the nuScenes test set, however, the paper reports a moderate decrease: PillarNet-18 achieves mAP 65.0 and NDS 70.8, while DensePillarNet achieves mAP 63.13 and NDS 69.4. The source text characterizes this as about a 1.4-point NDS drop, or roughly $x_0$ 5 relative (Chandorkar et al., 1 Aug 2025).

The class-wise test-set AP values show that the degradation is not uniform. DensePillarNet versus PillarNet-18 is reported as 86.9 vs 87.4 for Car, 55.8 vs 56.7 for Truck, 65.0 vs 60.9 for Bus, 61.0 vs 61.8 for Trailer, 23.4 vs 30.4 for Construction Vehicle, 85.6 vs 87.2 for Pedestrian, 63.6 vs 67.4 for Motorcycle, 36.6 vs 40.3 for Bicycle, 80.0 vs 82.1 for Traffic cone, and 73.7 vs 76.0 for Barrier. The most notable gain is on Bus, whereas the largest drop occurs on Construction Vehicle (Chandorkar et al., 1 Aug 2025).

Relative to other pillar-based detectors on nuScenes validation, DensePillarNet occupies an efficiency-oriented position. The paper reports the following comparisons: PillarNeSt at NDS 69.2 and mAP 63.2 with 8.9M parameters and 132.71G FLOPs; PillarNext at NDS 68.8 and mAP 62.5 with 14M parameters, 100G FLOPs, and 103 ms latency; FastPillars at NDS 68.2 and mAP 61.3 with 23.28M parameters, 136.81G FLOPs, and 113 ms latency; DensePillarNet at NDS 67.81 and mAP 60.33 with 10.35M parameters, 97.71G FLOPs, and 85 ms latency. The paper’s summary is that DensePillarNet has the lowest FLOPs and the lowest latency among the compared pillar-based SoTA methods, while conceding some accuracy to the strongest pillar models (Chandorkar et al., 1 Aug 2025).

A plausible implication is that DensePillarNet is positioned for regimes where real-time constraints and power budgets are prioritized over the last increment of NDS. That interpretation is consistent with the source text’s emphasis on edge devices and multi-task autonomous-driving stacks (Chandorkar et al., 1 Aug 2025).

6. Plug-and-play generalization and surrounding research context

The Dense Backbone is not presented as a PillarNet-only modification. The authors demonstrate it in three detectors: PointPillars to DensePointPillars on KITTI, CenterPoint to DenseCenterPoint on nuScenes, and PillarNet to DensePillarNet on nuScenes. The reported results are heterogeneous but directionally consistent with the plug-and-play claim: DensePointPillars improves KITTI test mAP (3D) from 55.44 to 57.62 while reducing backbone parameters from 4.21M to 0.47M and backbone FLOPs from 29.71G to 19.86G; DenseCenterPoint improves nuScenes test NDS from 59.8 to 60.0 and mAP from 49.4 to 51.2 while lowering memory footprint and slightly increasing FPS on A100 and Jetson Orin Nano; DensePillarNet then provides the PillarNet-specific instantiation of the same design principle (Chandorkar et al., 1 Aug 2025).

This places DensePillarNet in a broader design space of pillar-based LiDAR detection. CADNet focuses on varying point-cloud density through point context, semantic context, and decomposable dynamic convolution rather than backbone replacement (Tian et al., 2019). “Improved Pillar with Fine-grained Feature for 3D Object Detection” increases information density through height-aware sub-pillars, tiny-pillars, and a sparsity-based CNN backbone, again addressing pillar limitations through representation granularity rather than a lightweight dense-layer backbone (Fu et al., 2021). Pillar R-CNN, by contrast, treats densified BEV pillar features as sufficient for a two-stage R-CNN-style detector in BEV space, showing a different route to increasing capability within the pillar paradigm (Shi et al., 2023).

The sparse-computation literature provides a complementary contrast. “Selectively Dilated Convolution for Accuracy-Preserving Sparse Pillar-based Embedded 3D Object Detection” argues that naive sparse pillar networks lose accuracy because SubM-Conv restricts fine-grained spatial information flow, and proposes SD-Conv to restore dense-like propagation selectively (Park et al., 2024). “SPADE: Sparse Pillar-based 3D Object Detection Accelerator for Autonomous Driving” targets the vector sparsity of pillar features in hardware, using dynamic vector pruning and a sparse coordinate management architecture to reduce computation and energy in PointPillars-, CenterPoint-, and PillarNet-style models (Lee et al., 2023). In that context, DensePillarNet represents a different efficiency strategy: it keeps the detector structure intact and reduces complexity primarily through backbone design rather than sparsification of the full BEV processing pipeline.

7. Limitations, misconceptions, and future directions

The main limitation identified for DensePillarNet arises from dense concatenation. Even with one-shot aggregation rather than DenseNet-style per-layer concatenation, dense blocks still require storing intermediate feature maps for final concatenation. The paper notes that this increases memory consumption and memory bandwidth usage, which can hurt latency on very constrained devices. This is presented as a genuine trade-off rather than a purely architectural benefit (Chandorkar et al., 1 Aug 2025).

A second limitation is that DensePillarNet attacks only one part of the detector. Because the neck dominates FLOPs, further backbone reductions alone provide diminishing returns. The authors therefore suggest future work that combines Dense Backbone with encoder and neck modifications, explicitly mentioning ideas from FastPillars. They also mention knowledge distillation as a way to improve the accuracy of lightweight dense-backbone models (Chandorkar et al., 1 Aug 2025).

A common misconception would be to interpret the model name as implying a wholesale densification of the pillar pipeline. The source material does not support that reading. DensePillarNet is specifically a PillarNet-18 variant in which the backbone becomes dense-layer-based and feature-reuse-oriented, while the encoder, neck, head, losses, and training pipeline remain unchanged. Another possible misconception is that it dominates the accuracy frontier among pillar methods. The reported nuScenes results do not support that either: it is competitive, but it trades some accuracy for lower FLOPs and lower latency relative to stronger but heavier pillar baselines (Chandorkar et al., 1 Aug 2025).

Taken together, the available evidence positions DensePillarNet as a lightweight backbone substitution inside the PillarNet framework, with the central claim that dense-layer-based feature reuse can replace a heavier residual sparse backbone with only limited impact on detection quality. This suggests a specific research direction inside pillar-based LiDAR detection: treating backbone specialization for sparse point-cloud structure as an independent design axis, rather than assuming that image-derived ResNet or VGG variants remain the default choice (Chandorkar et al., 1 Aug 2025).