You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: MRTK-vNext.md
-40Lines changed: 0 additions & 40 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,46 +53,6 @@ Following the feedback we’ve received both internally and through current cons
53
53
* All testing components / scripts / prefabs / scenes should only be retained in the dev branch. The master branch should only contain the “ToolKit” and working examples. Master is for consumers only.
54
54
* Simulator options need to be provided as another device. This will also form the template for new MR/XR/VR devices / SDKs.
55
55
56
-
## Fringe thoughts (dumping ground for ideas :D)
57
-
58
-
* Defining headset gameplay, allowing for sitting / standing or free roaming play.
59
-
Has to be easy enough to enable single projects to handle both behaviors
60
-
* Defining headset movement, is it free roam, shifting or teleporting?
61
-
* With Teleporting specifically, is it cursor based or zone based (something we don’t have). After watching the Rick and Morty retrospective, they struggled with this and movement space, something an SDK should be able to provide a starter experience for.
62
-
* Adding interaction mechanics to objects in the scene easily. Is it grabbable, moveable, altered by gravity etc.
63
-
* Helpers for 3d’ifying scene objects, 2 sided drawing or best practices
64
-
* Examples, Examples, Examples – Ensuring our examples are bigger than current based off the latest examples scene that came from VRTK which was well received. (showed ALL interaction options within a small house)
65
-
* Videos – a YT / FB video channel with educational snippets dedicated to MRTK
66
-
67
-
68
-
## Proposed Tasks
69
-
70
-
To ensure we have a smooth transition, we need several key tasks to be completed, to ensure a smooth transition and ensure we limit (as much as possible) any future breaking changes:
71
-
72
-
1. Build the new frontend architecture, to enable both existing users and new to start building from, comprising of an Initial set interactable component prefabs / components:
73
-
74
-
* Grabbing
75
-
* Touching
76
-
* Basic interaction
77
-
* Teleporting
78
-
79
-
2. A single example scene to demonstrate the use of the new components
80
-
81
-
3. Short video demonstration of example
82
-
83
-
Followed up with further front end components.
84
-
This will enable users to start using the new style approach for building new solutions.
85
-
86
-
Either in parallel (or following), we should focus on building the new underlying Multi-vr framework and stitching components together.
87
-
88
-
1. Define the underlying interfaces for the Multi-vr approach which abstracts the work Stephen has started in the Input system
89
-
2. In a feature branch, align the existing input and interaction systems to adopt the new interfaces
90
-
3. Update the current MR implementation to the new interfaces
91
-
92
-
It will be key to further understand any gaps we currently have in the toolkit to align to this new approach.
93
-
94
-
Once ready, the above prefabs/components will be updated to use the new underlying framework with little to no impact on their designed scenes.
0 commit comments