Best Practices

This topic describes several best practices that come handy while integrating the Passthrough API.

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.

If your app supports both MR and pure VR, query the system to decide which one to default to. See Enable Based on System Recommendation for details.

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.

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.