C#
C# enters the SLAM world through one door: augmented reality applications. While SLAM algorithms themselves are written in C++, the applications that consume SLAM output — AR games, industrial AR overlays, mixed-reality training tools — are very often built in C# on top of Unity or Microsoft’s mixed-reality stack.
Unity AR. Unity is the dominant engine for AR development, and its scripting language is C#. Frameworks such as AR Foundation give a C# API over the platform tracking systems (ARKit on iOS, ARCore on Android): you receive the device pose, detected planes, and anchor points that an underlying VIO/SLAM system computes natively, and you use them to place and render virtual content. From the C# side, SLAM appears as a service — a stream of 6-DoF poses and environment geometry — rather than as an algorithm you implement.
The AR Foundation mental model maps directly onto SLAM concepts you know:
- Session — the lifetime of the underlying tracker; it can be initializing, tracking, or in a degraded/limited state (the C# app must handle all three gracefully).
- Trackables — planes, feature points, images, and meshes detected by the tracker: the platform’s version of a map.
- Anchors — poses pinned to the physical world that the system keeps updating as its map improves; the AR-facing face of landmarks and loop closure. When the tracker corrects drift, anchored content visibly snaps — understanding why is pure SLAM knowledge.
Microsoft HoloLens. HoloLens is a self-contained mixed-reality headset whose on-board head tracking and spatial mapping run as system services. Applications are typically built in Unity with C#, using the Mixed Reality Toolkit (MRTK) to access spatial meshes, spatial anchors, and hand/eye input. For a SLAM engineer, HoloLens is interesting in both directions: it is a deployed example of always-on head tracking and mapping in a consumer-grade device, and (through its research mode) a source of multi-sensor data for experiments.
The typical division of labor looks like this:
| Layer | Language | Role |
|---|---|---|
| SLAM / VIO engine | C++ | Tracking, mapping, relocalization (platform-provided or custom) |
| Engine bindings | C++/C# interop (P/Invoke, native plugins) | Expose poses, meshes, anchors |
| Application | C# (Unity, MRTK) | Rendering, interaction, business logic |
Bridging your own C++ SLAM into Unity. The standard route is a native plugin: compile the C++ core as a shared library per platform (.so, .dylib, .dll, iOS framework) and call it from C# with P/Invoke:
[DllImport("myslam")]
private static extern void slam_track(IntPtr image, double timestamp, float[] pose4x4);Poses cross the boundary as flat float arrays; the recurring gotcha is coordinate conventions — Unity uses a left-handed, Y-up coordinate system while most SLAM/robotics code is right-handed, so a conversion (axis flip plus corresponding quaternion component changes) sits at every bridge, and getting it wrong produces mirrored or tumbling content.
So even in a C# job, understanding SLAM pays off: you can interpret tracking failures, understand why anchors drift, and design content placement that respects the limits of the underlying tracker.
Why it matters for SLAM
AR is one of the largest commercial applications of visual SLAM, and C#/Unity is how most AR products are actually shipped. If you work on SLAM for AR devices, C# is the language of your users: you will write native plugins that expose your C++ tracker to Unity, debug issues reported in C# apps, and design APIs (poses, anchors, meshes) that C# developers consume. It is also a practical prototyping route — Unity can simulate cameras and environments for testing perception pipelines.