Spatial Mapping generates a large amount of data. This has an impact on your application’s speed and performance. This section discusses common issues that can arise from using Spatial Mapping, and guidance on how to avoid those issues.
Generating collision data requires more CPU processing time than any other aspect of Spatial Mapping. Ensuring that collision data is only requested when necessary optimizes usage of CPU resources and increase battery life.
Only request collision data where necessary. Avoiding collision data requests when they are not necessary decreases the latency for other Spatial Mapping requests, and prolongs battery life.
Use a Surface’s update time and bounding boxes to prioritize data requests, and only request Surfaces that are high priority.
High values of trianglesPerCubicMeter, set through the SurfaceData struct when requesting Surface data using the RequestMeshAsync method, generate a very large amount of geometry in your Scene. This is especially true in spaces containing many objects (like a cluttered office). Large amounts of geometry in your Scene increase data generation latency and the memory usage of your application. Higher Mesh densities in your Scene can also slow down run-time systems such as rendering and physics, which can affect performance.
Use the minimum resolution of Spatial Mapping data that your application requires. To do this, you need to test your application and the accuracy of the generated Spatial Mapping mesh, but the result is a balance of accuracy and performance that ultimately offers a much more positive user experience. Lower resolutions of generated Meshes result in less CPU time being spent by your application when the Mesh updates. This reduces the power consumption of your device, increases battery life, and also reduces latency in retrieving Mesh data. Lower resolution Meshes also use less memory and have a less impact on run-time systems such as rendering and physics (which expects low complexity geometry).
This adds a list of all changed Surfaces to the work queue and can result in unused Surfaces remaining in the work queue after Spatial Mapping has removed them. These Surfaces still take up CPU time when moving through the system, but do not generate any Mesh data. This increases the latency of any waiting requests.
Limit the number of Surfaces in the work queue where possible. Querying Meshes is an expensive operation with high latency, so keeping only a single RequestMeshAsync request in use at any given time minimizes any slowdown that these operations cause. Applications can use a Surface’s reported update time and bounds to prioritize
It is also important to prioritize Surface data requests so that your application receives the most important data first. Examples of common ways to prioritize include:
Prioritizing new Surfaces above updating existing ones.
Prioritizing Surfaces that are closer to the user over those further away.
SurfaceObservers report changes for all Surfaces that overlap their volume. A Surface can overlap multiple
SurfaceObserver volumes if they are close together. This makes it possible for application code to request the same Surfaces multiple times, which can lead to performance issues.
Best practice solution:
Use a single work submission queue for requests from
For many applications, a single
SurfaceObserver is often all you need.
Using a single
SurfaceObserver can help you reduce the complexity of developing your application. However, there are several advanced uses for Spatial Mapping that require multiple
SurfaceObserver members. In these cases, you should use a single work queue for all
SurfaceObserver members in your Scene in order to uniquely prioritize Mesh requests.
This is a common issue, typically caused by issues in the set-up process.
Set a valid volume on your
SurfaceObserver, using a method such as SetVolumeAsAxisAlignedBox.
You should also make sure that you enable the Spatial Perception capability in Publishing Settings (menu: File > Build Settings > Player Settings > Publishing Settings).
For more information relating to Capability and Publishing Settings for WMR, see Unity’s Windows Mixed Reality quick starter guide.
2018–05–01 Page published with editorial review
Spatial Mapping for Hololens documentation updated in 2017.3