Designing Augmented Reality Systems for Speed
summary
Niantic-era systems push concrete choices: a peer-to-peer mesh between phones and cell towers yields round trips in the tens of milliseconds so 30 fps budgets (~33 ms) hold for multiplayer AR; restructuring SLAM into an actor model with message queues removes locks and busy waiting and produces about a 5× speedup without new math; practical tradeoffs combine UDP/TCP, coarse-grained remoting, and mobile-friendly caching to run heavy vision, mapping, and rendering on phones.
AI-written summary · about
chapters (26)
- 0:00Intro
- 0:59Problems in Computer Science
- 1:19Why is AR so hard
- 1:52AR is an interdisciplinary field
- 2:59Understanding the world
- 5:25Running in realtime
- 7:44Point cloud
- 8:11Augmented Reality
- 9:13Developer Experience
- 10:47Putting it all together
- 11:02Infinity Heart Problems
- 12:39Beyond Moores Law
- 14:39Holmes Law
- 16:40Fundamental Human Limit
- 17:28Systems Design
- 18:21Systems Design Principle for Distributed System
- 22:33Speeding Up Networking
- 25:50Unreliable Messages
- 26:42Ideal Solution
- 30:08Speeding Up Computation
- 30:34Slam Computation Pipeline
- 31:32Embedding Slam
- 33:26Actor Models
- 35:06Restructure
- 36:49Credits
- 37:12Were also hiring
related talks
42mLocal Agentic Theory for Accessible Mobile Games
21mNiantic's AR mapping lead on using Earth as an AR gameboard
19mThe ARCloud: A Myth? Or the Future of AR?
14mHow to AR
22mHow developers can bring augmented reality games to the masses in 2019
16mConnecting us to Each Other Means Connecting AR Apps to Each Other
14mImaginateAR: AI-Assisted In-Situ Authoring in Augmented Reality
01h 16mAugmented Reality For The Masses