Proposal: Update rename "Body" to "MixedRealityPlayspace", and add an accessor to MixedRealityManager

[Ecnassianer]

Overview

Right now MRTK creates a "Body" game object which contains a camera. The camera's position is determined by a combination of headset tracking and teleporting. Though the name "Body" seems to imply that it is either a virtual body (positioned beneath the headset) or a tracked object that represents the body (e.g, positioned by a vive tracker puck), but it is neither. The "Body" position is determined by teleporting. Furthermore, it seems to mostly exist sitting around somewhere on the real world ground, something that "Bodies" usually don't do.

Step 1) Give Body a better name

We should rename it MixedRealityPlayspace.

Feel free to skip to the next section. Here's an interesting philosophy to think about. The MixedRealityPlayspace GameObject actually represents a tracker agnostic reference point to convert from arbitrary tracker spaces into Unity World Space Coordinates. It essentially defines a "Reality Space Coordinate System".

In the case of a stationary tracker, like a Vive Lighthouse, 0,0,0 in tracker space happens to always line up exactly with Reality Space 0,0,0. It would also line up exactly with Unity World Space 0,0,0, except that when you teleport they get offset by the distance you teleported. So why do we need a Reality Space Coordinate System if always lines up with the position the tracker is reporting?

Consider non-stationary trackers, like Oculus Go, HoloLens, or a headset mounted Leap Motion. These devices might start up anywhere in their playspace, and they're always tracking relative to something else (in most cases, relative to the headset). In the case of non-visible WMR controllers, they're essentially tracked relative to where they were last seen by the headset. So we have to combine a whole host of inconsistent tracker spaces; and these tracker spaces may even move relative to the Unity World Space. (Picture graph paper pinned to a leap motion which is attached to a headset as it moves through Unity World Space).

None of these tracker spaces are aware of each other, or share any kind of common reference. So we have to choose an arbitrary point (or really, we let the platform choose, but from an MRTK user's perspective it's arbitrary), and calibrate each tracker to that point. That way controllers, hands, cameras, bodies, pucks, and world anchors all appear to align correctly, and when we teleport, they all receive the teleport's offset uniformly.

Step 2) Add an accessor to MixedRealityManager

Anybody trying to place tracked game objects (for instance, someone implementing Vuforia support to position printed cards relative to a camera) will need to be able to get at the shared space. As far as I can tell, there's no way to request the Body component other than finding the name in the scene (could be wrong, haven't looked too hard). We should add a GetMixedRealityPlayspace() accessor.

As a sidenote, there's space for a GetMixedRealityPlayspace(Int PlayerIndex) which could get a play space object for a player in a multiplayer game, while GetMixedRealityPlayspace() always returns the local player's playspace, and would return null on a dedicated server).

[Optional] Step 3) Put all the runtime stuff under MixedRealityRuntimeObjects

The proposal isn't ready to die on this hill, but as long as we're at it, we should put all our stuff in a MixedRealityToolkit gameobject as an organizational tool to keep the scene hierarchy tidy. The same way all our assets are in the "MixedRealityToolkit" folder in the project browser. We shouldn't be dropping stuff willy nilly about in the scene root.

It doesn't really make sense to me to put the MixedRealityPlayspace under the MixedRealityManager. I think we should probably create a new game object that stays at 0,0,0 as an organizational tool and put both MixedRealityPlayspace and MixedRealityManager, as well as any other MRTK objects in it.

Don'tDestroyOnLoad objects like MixedRealityManager will move out of the MixedRealityToolkit object at runtime. I'm open to suggestions on a way to be more consistant (maybe create a second MixedRealityToolkit object that's also DontDestroyOnLoad), but I don't think it's a big concern, we could just leave it alone.

[Ecnassianer]

Making sure @StephenHodgson @keveleigh @julenka see this.

[Ecnassianer]

Also, happy to tackle this work myself once everyone is onboard.

[StephenHodgson]

MixedRealityPlayspace sounds good to me.

Step 2) Add an accessor to MixedRealityManager

Did you mean accessor to the aforementioned MixedRealityPlayspace?

Not really keen on step 3. There's valid reasons to have a shallow hierarchy. Currently we only have two GameObjects in the scene we keep track of any way, so this isn't really necessary yet. ( I guess it depends on how complicated our setup gets ).

[Ecnassianer]

Did you mean accessor to the aforementioned MixedRealityPlayspace?

Yes. More verbosely, what I mean is add a function to MixedRealityManager which is an accessor which grants access to MixedRealityPlayspace.

[StephenHodgson]

Currently you can get the Body(AKA MixedRealityPlayspace) with CameraCache.Main.transform.parent but I can see why that's not immediately obvious! haha. We can easily wrap that in a parameter exposed to the MixedRealityManager.

MixedRealityManager.Instance.MixedRealityPlayspace

[david-c-kline]

We can easily wrap that in a parameter exposed to the MixedRealityManager. MixedRealityManager.Instance.MixedRealityPlayspace

Great suggestion! @Ecnassianer are you going to work on this?

[david-c-kline]

Not really keen on step 3. There's valid reasons to have a shallow hierarchy.

I believe what @Ecnassianer means is ANY non-playspace / body related objects (ex: floor, diagnostic window, etc) should be created under MixedRealityRuntimeObjects.

That would DEFINITELY help developers understand where autocreated objects are coming from.

[Ecnassianer]

I half-started this yesterday but got distracted. I'll find time for it this week.

[Ecnassianer]

I had a question as a implemented this. Users will assume that the MixedRealityPlayspace always corresponds to the "center" (maybe "origin" would be a better word) of the tracked space. Is it safe to assume that when the MixedRealityManager starts, this would be at 0,0,0 worldspace? It will never be, for instance, the lower left hand corner of the tracked space? Should the MixedRealityManager do something specific to ensure this is always true?

[StephenHodgson]

MixedRealityManager

Why do we need to know where this is?

[Ecnassianer]

We don't need to know where the MixedRealityManager is, but since I am making it initialize the playspace (rather than having each manager that relies on a playspace be responsible for setting it up properly), the Manager needs to know where the Playspace goes.

Currently, the teleport module moves both the Body/Playspace and the Camera to Vector3.zero. I'm pretty confident this is incorrect, since it would offset something like a boundary space by the inverse of the distance between the headset and the center of the user's playspace. (I've taken that behavior out of MixedRealityTeleportManager, since it shouldn't be moving the camera, only the playspace.)

That's the kind of issue I'd like to guarantee we avoid by expicitly placing the Playspace in world coordinates that make sense. I suspect this could vary by platform, but it might just be safe enough to assume that when the scene loads up, the tracked space 0,0,0 overlaps world space 0,0,0. Hence my question.

[StephenHodgson]

As long as we're not putting anything on or under the Mixed Reality Manager. It's the only class we call "don't destroy on load" unless the user specifically asks for it in the camera profile, then the camera's root parent is flagged.

[StephenHodgson]

Pretty sure the camera is actually what needs to be at the origin on start or some weird things happen.

[Ecnassianer]

Do you have any details about the weird things that happen? Or know who would know?

If we need the camera at the origin, then we can offset the playspace appropriately, but I'd rather not do that unless it's necessary.

[StephenHodgson]

Controller positions get offset by the distance the camera is offset from the origin. That's not a MRTK specific thing, but a Unity thing, I believe.

Might be other things too, but that's the first one off the top of my head.

[SimonDarksideJ]

Can't believe I've not seen this discussion before, which 1 & 2 certainly sound like a great proposal. Will get on reviewing / testing the PR.