Memory efficient 3D mapping: voxels versus Gaussians

A compact map is useful only if it answers the questions your application actually asks. An inspection station may need surface distances, while a mobile system may need occupied, observed-free and unknown space. Those requirements can favor different representations even when both start from the same depth frames.

For memory-constrained 3D vision, compare the complete running system: map storage, incoming frames, update buffers, spatial indexes and query latency. The following estimates and tests help you choose between voxel occupancy and Gaussian-based mapping without confusing a small saved file with a small working-memory requirement.

Choose by query requirements first

Choose voxel occupancy when you need direct cell-state queries, explicit unknown-space handling and a straightforward resolution limit. Consider a Gaussian occupancy representation when adapting component size and orientation to scene geometry can reduce storage, and your implementation supports the required occupancy queries.

A Gaussian represents a spatial distribution, often described by a mean, covariance and weight. It is not inherently an occupied object, a free-space region or a collision-distance field. Those meanings come from the mapping algorithm.

The existing voxel-grid storage guide explains point indexing and aggregation. Occupancy mapping adds another requirement: recording what observations imply about the space between the sensor and each measured surface.

Calculate a voxel baseline before optimizing

Start with a dense grid because its storage estimate is easy to audit. For axis-aligned dimensions and cubic cells, use:

Here, r is cell size and each length uses the same units. This estimates cell payload only, excluding indexes, allocation overhead and temporary buffers.

Consider an application volume measuring 8 m × 8 m × 3 m. Assume a four-byte cell payload for this example, not a specification for any product or library.

One MiB is 1,048,576 bytes. Halving cell size multiplies dense storage by eight because all three dimensions double.

Sparse voxel blocks and hierarchical grids can avoid allocating large unobserved regions. However, keys, pointers, block headers and allocation granularity add overhead. Compare their measured allocation against this baseline rather than assuming that every unallocated cell becomes a proportional saving.

Also decide how unknown space is represented. An initial occupancy probability alone may not distinguish an unobserved cell from one receiving conflicting observations; observation metadata may be necessary.

Estimate Gaussian storage without hiding the overhead

For an illustrative Gaussian layout, assume three mean values, six independent covariance values and one weight. With four-byte floating-point values, that parameter payload occupies:

Suppose alignment, identifiers and bookkeeping bring the assumed allocation to 64 bytes per component. A map containing 20,000 components then needs:

That is smaller than the example dense grid at 50 mm spacing, but it is not yet an equivalent-performance comparison. You still need to account for spatial indexes, free-space information, optimization workspaces and any duplicated map used during updates.

Two complete component buffers would occupy about 2.44 MiB before those additions. An implementation might instead update in place, trading lower memory for more complex synchronization.

Component count is also scene-dependent. A broad smooth surface may fit compactly, while clutter, thin edges and changing objects can demand additional components. A fixed component budget needs a documented policy for merging, deletion and aging.

The GPU point-cloud memory-layout guide helps explain why logical parameter counts can differ from actual buffer sizes. Measure allocated bytes, including padding and temporary arrays.

Keep free, occupied and unknown space distinct

A point cloud describes measured endpoints. It does not, by itself, record all the space traversed by the measurement rays.

An occupancy mapper normally uses a sensor model to update both surface evidence and traversed-space evidence. Invalid depth readings need separate treatment: a missing return does not automatically prove that the entire ray is clear.

Gaussian surface reconstruction, visual Gaussian rendering and Gaussian occupancy mapping are different tasks. A representation that produces convincing images may not support reliable free-space queries. Likewise, a normalized probability density over measured endpoints is not automatically an occupancy probability field.

Before accepting any Gaussian implementation, establish:

• How measured surfaces contribute occupied-space evidence.
• How valid rays contribute observed-free evidence.
• How never-observed regions remain unknown.
• How contradictory observations change confidence.
• How old observations expire when objects move.

If the implementation stores only surface components, compare it with a voxel surface map—not a complete occupancy map. Any separate visibility or free-space structure belongs in the memory total.

Budget acquisition, updates and queries together

Map payload can be smaller than the data waiting to enter it. For an illustrative input stream, a 640 × 480 depth frame with two bytes per sample occupies 614,400 bytes.

Expanding every sample into three four-byte coordinates requires:

Three full coordinate buffers therefore occupy about 10.55 MiB. That exceeds either compact-map example before application code, images or query workspaces are counted.

Use an explicit peak-memory budget:

Avoid double-counting shared buffers, but include overlapping allocations during rebuilds or map replacement. Bounded queues prevent a temporary slowdown from becoming steadily increasing latency and memory consumption.

At 20 frames/s, a frame arrives every 50 ms. A 640 × 480 stream presents 6,144,000 depth samples/s before invalid samples are rejected. If the application also requests 2,000 map queries per frame, the mapper must handle 40,000 queries/s alongside updates.

Benchmark that combined workload. Isolated update speed does not reveal query contention, index rebuild pauses or stale map reads. Record typical latency, high-percentile latency, longest observed stalls and the age of the sensor data behind each answer.

Run an equivalent-workload comparison

Use the same recorded depth sequence, calibration, timestamps and poses for both representations. Do not allow one mapper to receive cleaner or more aggressively filtered input without reporting the difference.

A practical comparison sequence has five stages:

1. Define the required answer. Specify occupancy at a location, clearance along a path, surface distance or another concrete query. Define how unknown answers are handled.
2. Set application acceptance limits. Specify the smallest relevant structure, allowable geometric error, update deadline and maximum data age. These are application requirements, not catalog specifications.
3. Replay representative scenes. Include broad surfaces, narrow gaps, thin objects, changing geometry and regions that disappear from view.
4. Measure steady state and transitions. Track initialization, normal operation, map growth, component merging, index rebuilding and recovery after interruption.
5. Reject inaccurate configurations before ranking memory. Compare only configurations that satisfy the same acceptance limits.

For example, include a 20 mm rod and a 100 mm gap when evaluating a map configured around a 50 mm spatial scale. Neither representation should be presumed to preserve those features without testing. Check both missed structures and false occupied regions that close usable gaps.

Pose errors can dominate representation errors. A small-angle estimate gives lateral displacement as range multiplied by angular error in radians. At 4 m, a 1° error gives approximately 4 × π / 180 = 0.070 m, or 70 mm.

Correct coordinate-frame transformations before blaming the mapper. For multiple sensors viewing moving geometry, also address point-cloud synchronization.

Choose sensors and processing hardware around the workload

The representation does not remove acquisition constraints. Select 3D sensors for the actual measurement task, then use the camera finder to narrow candidates. Confirm working range, usable detail, surface response, timing and data access through the documented specifications and an application trial.

The MV-DPS200P-02 is cataloged as a projected structured-light 3D camera.

The MV-DT01WMU is cataloged as a ToF sensing camera.

These identify different acquisition approaches, not a mapping-performance ranking. The supplied catalog context does not establish Gaussian mapping support, mapping throughput or compatibility with a particular software implementation.

Before ordering either approach, verify that its documented output can feed your mapper. Check depth units, calibration access, invalid-sample conventions, timestamps and the interfaces supported by your acquisition software.

For processing, evaluate vision controllers against measured peak RAM, acquisition interfaces and simultaneous update/query demand. A controller's memory capacity alone does not establish whether a particular mapper will meet its deadline.

The 3D camera positioning guide is useful when mounting geometry limits what the sensor can observe. Unseen surfaces cannot be recovered reliably just by changing the map representation.

Know when the usual recommendation is wrong

A dense voxel grid can be the right answer for a small, bounded inspection volume. Its predictable allocation and simple queries may matter more than reducing a modest map payload.

Sparse voxels can be preferable when the observed region occupies a small fraction of a larger workspace. They retain familiar cell-based semantics, although block allocation and index overhead must be measured.

Gaussian occupancy can be attractive when adaptive fitting substantially reduces the accepted map size. It becomes less attractive when fine clutter drives component growth or queries require expensive evaluation of many overlapping components.

For dimensionally demanding inspection, preserve access to the original measurements needed for verification. A compact planning map may discard detail that a later measurement requires. Review point-cloud downsampling distortion before treating reduced data as a geometrically neutral substitute.

Finally, memory savings do not establish energy savings. Measure power over the same workload and include acquisition, processing and memory activity. Average joules per processed frame equal average watts divided by processed frames per second; dropped frames and reduced query demand must be reported alongside that figure.

Check the complete design before committing

Use this checklist before selecting the representation or final hardware:

• Query semantics: The map answers the actual application question and preserves unknown-space handling.
• Geometric acceptance: Thin structures, edges and gaps pass the same tests for every candidate.
• Peak memory: Measurements include queues, indexes, rebuilds and update workspaces.
• Timing: Updates and queries meet their deadlines while running together.
• Data age: Answers carry enough timing information to detect stale observations.
• Growth control: Long runs do not silently exceed the component, block or queue budget.
• Sensor integration: Units, calibration, poses and timestamps agree throughout the pipeline.
• Recovery: Restarting or losing input produces a defined map state rather than apparently valid stale data.

Start with a voxel baseline, then retain a Gaussian alternative only if it passes equivalent accuracy and timing tests with a worthwhile total-memory benefit. Bring the resulting acquisition requirements and measured processing budget to the camera configurator, or contact the applications team to discuss suitable parts.