The old GetNativePtr mechanism provided by Legacy VR was a stopgap approach meant more to allow our platform partners the ability to get at information on their platforms that we couldn't or didn't expose through a common API. This pointer mechanism usually consisted of a blob of data that had to be cast and interpreted correctly by the user or bad things could happen. This was deemed not very maintainable.

When we created the new XR SDK plugin system, a lot of what was exposed in that blob was pushed out into specific native pointer data for subsystems that allowed for a more semantic definition of the data as well as more explicit pointer definitions. You still have to cast the pointer, but it should be a specific pointer to a single instance of the underlying system type for the managed object in play.

For instance: Anything that supports [ITrackable](https://docs.unity3d.com/Packages/com.unity.xr.arsubsystems@3.0/api/UnityEngine.XR.ARSubsystems.ITrackable.html) has a **nativePtr** field that is used to pass the native pointer to the platform underlying data for that thing.

Example: [XRAnchorSubystem](https://docs.unity3d.com/Packages/com.unity.xr.arsubsystems@3.0/api/UnityEngine.XR.ARSubsystems.XRAnchorSubsystem.html?q=XRAnchor) and Windows MR Plug-in provider

For anchors with Windows MR as the provider, the native pointer field will be set to a pointer to the underlying (SpatialAnchor)[https://docs.microsoft.com/en-us/uwp/api/windows.perception.spatial.spatialanchor?view=winrt-19041]. The benefit in this case is you can use that ptr directly using WinMD APIs to get data from it directly without reaching down to native code.

You can find more info about the general AR APIs and where they provide native pointer information in the [AR Subsystems documentation](https://docs.unity3d.com/Packages/com.unity.xr.arsubsystems@3.0/manual/index.html).

Where something general like that didn't make sense, or there was data specific to a platform that was not exposable at a common point, the provider for that platform should expose specific APIs for getting at the platform data.

For Windows MR we have the following examples:

SourceStates: (WindowsMRInput.GetCurrentSourceStates)[https://docs.unity3d.com/Packages/com.unity.xr.windowsmr@4.0/api/UnityEngine.XR.WindowsMR.WindowsMRInput.html]. This returns a list of (WindowsMRInput.SourceState)[https://docs.unity3d.com/Packages/com.unity.xr.windowsmr@4.0/api/UnityEngine.XR.WindowsMR.WindowsMRInput.SourceState.html]. Each source state has a nativeState pointer that is an instance of a (SpatialAnchorSourceStates)[https://docs.microsoft.com/en-us/uwp/api/windows.ui.input.spatial.spatialinteractionsourcestate?view=winrt-19041].

Meshing Data:

[WindowsMRExtensions.GetMeshingDataForMesh](https://docs.unity3d.com/Packages/com.unity.xr.windowsmr@4.0/api/UnityEngine.XR.WindowsMR.WindowsMRExtensions.html) will return meshing information in a [WindowsMRExtensions.MeshingData](https://docs.unity3d.com/Packages/com.unity.xr.windowsmr@4.0/api/UnityEngine.XR.WindowsMR.WindowsMRExtensions.MeshingData.html) structure for a given mesh id. The **MeshingData.surfaceInfo** and **MeshingData.surfaceMesh** which are (respectively) instances of [SpatialSurfaceInfo](https://docs.microsoft.com/en-us/uwp/api/Windows.Perception.Spatial.Surfaces.SpatialSurfaceInfo?view=winrt-19041) and (SpatialSurfaceMesh)[https://docs.microsoft.com/en-us/uwp/api/windows.perception.spatial.surfaces.spatialsurfacemesh?view=winrt-19041].

You can find more info about these APIs for Windows MR in the [Windows MR Plug-in Documentation](https://docs.unity3d.com/Packages/com.unity.xr.windowsmr@4.0/manual/index.html).

All documentation pointed to here is also accessible from the package Documentation links from the Package Manager UI within Unity. This includes specific platform plug-ins that may be available but not talked about here.