In order to create a Unity AR Foundation app, you must include an object within ARSession component on it in your scene. The ARSession component is responsible for controlling the life cycle of an AR experience, and you can use it to enable and disable AR features on the fly in your app at run time. This is very useful if you have an existing app, and want to only add AR features to certain parts of it, or if you want to have some regular 2D setup screens in your app that are not shown in augmented reality. An ARSession currently has two settings you can control called light estimation and attempt update. The light estimation setting is used to enable and disable lighting estimation for the scene. Lighting estimation can be expensive, so if you're not using it, you should leave it turned off. The attempt updates setting will allow your app at run time to trigger an update to AR Core or AR kit if the software is out of date or not installed on the user's device. It's probably a good idea to leave this feature enabled. AR foundation includes a static class called ARSubsystemManager, that has methods and callbacks that allow your app to monitor and control the ARSession lifecycle. We'll explore ARSubsystemManager callbacks throughout all of the project work for this course, but for now one of the most important callbacks is the system state change to callback. As we learned in the first module, AR tracking takes a little while to take effect. As we'll learn when we look at a AR best practices in our final module, AR apps need to be very flexible about dealing with a lack of AR tracking info. The system state enumeration in AR foundation lets your app determine if AR has been initialized and when it is sending valid tracking info, or if it's not installed, is not supported on the current device, or any number of other possibilities. AR apps should incorporate a state machine that monitors the state of the AR system, and display dialogues as appropriate letting the user know what's going on in plain language. ARSession data is in a coordinate system called Session space. If you want to make sense of any track features the ARSession data gives you, then you'll need to work in the unit coordinate system. AR foundation includes a component called an ARSessionOrigin that serves as a way to bridge the two coordinate systems. When you include an ARSessionOrigin in your scene, all of the Session data is relative to that coordinate system. It's quite possible that the session origin for the device may be quite different from where the user ends up wanting to look at any AR content. The session origin is probably the location where the user first started the app, but they may have moved to a better spot in their environment to view your AR content. So, the actual position of the session origin ends up not being that important with spatial computing, your app needs to deal with the layout of the users real-world environment, and planning of the virtual environment ahead of time is no longer a viable way to design for AR. But one important feature of the ARSessionOrigin that does make sense to manipulate is the scale. Assuming that your AR camera is a child of the ARSessionOrigin, you can scale your virtual content to match the world using this scale component of the ARSessionOrigin's transform. We'll talk about that more in our next module when we look at AR camera.