Best Practices
This topic describes several best practices that come handy while integrating the Passthrough API.
Save compute and power resources by pausing objects
Some of the objects can be paused and later resumed in order to save compute and memory resources. Pausing is less expensive than destroying, but may leave some resources allocated / reserved.
Application can create multiple passthrough layers. This is necessary in certain situations, for example when layers should differ in compositing order (e.g. one on top and one beneath the application’s projection layer) or style. But every layer incurs a non-trivial performance overhead to the system, which is why applications should use as few layers as possible. To avoid an excessive performance impact, the system currently limits an application to three active passthrough layers at any given time.
Use system recommendation to choose between MR and VR
Avoid reconstruction artifacts by using surface-projected passthrough
When an application intends to show passthrough restricted to a specific surface or object, for example, a desk or the user’s hands, consider letting users mark those surfaces in a setup workflow. You can also obtain proxy geometry from tracking APIs and use the resulting geometries as passthrough projection surface instead of the automatic environment reconstruction. This approach eliminates reconstruction artifacts and leads to a more stable passthrough visualization.
Keep passthrough cameras in sync with the display
To maximize the smoothness of passthrough, it is recommended to use a 72Hz refresh rate for your application. In flicker-free lighting conditions, passthrough will synchronize the cameras with the display, ensuring stable latency and eliminating judder. The feature is only available on Quest3/Quest3S devices.
