Because of the volume of data that can be generated by Spatial Mapping, and the effect on speed and performance of generating that data, there are many issues to consider when using the low-level API.
If you don’t carefully plan your application’s use of Spatial Mapping, your application’s speed and performance can be poor. Below are some potential issues that Spatial Mapping can create, and best practice advice on how to work around them.
Generating collision data uses most of the CPU computation when generating Spatial Mapping data. Requesting collision data that isn’t going to be used unnecessarily ties up CPU resources and reduces battery life.
You can specify high values of trianglesPerCubicMeter in the SurfaceData struct when requesting Surface data through RequestMeshAsync. This generates a very large amount of geometry, especially in spaces with a lot of objects such as a cluttered office. Large amounts of geometry increase data generation latency and memory usage. In addition, higher Mesh densities can make run-time systems such as rendering and physics run more slowly.
SurfaceObservers report all added, updated, and removed Surfaces within their volume when Update is called.
Adding the total list of changed Surfaces to the work queue can result in Surfaces remaining in the work queue after they have been removed by the system. Surfaces still in the work queue after they have been removed still take up CPU time moving through the system, but do not generate any mMsh data. This increases the latency of any waiting requests.
RequestMeshAsync
in use at a time. Applications can use a Surface’s reported update time and bounds to prioritize RequestMeshAsync
calls.Each SurfaceObserver reports changes for all Surfaces that overlap its volume. A Surface can overlap multiple SurfaceObserver volumes if those volumes are close, so your application code might request the same Surfaces multiple times.
This common issue is typically due to one or more set-up issues.