I've looked up as much as I've been able to find of forum posts here on using VRTK toolkit with AC. I noticed
@Alverik worked on a project using VRTK. Could you please kindly help with suggested best practices for getting the integration to work from your experience? The last post I saw was from 2017 so I don't know if some things have changed in AC which might mean a different workflow. Please anyone else with this experience, do share. The main reason for using VRTK is to be able to develop and test the VR integrations as I do not have a HMD at hand.
I built the game originally with AC, now I want to use VRTK to adapt it to VR, final destination would be Occulus Go. I want the player to be able to trigger pick ups and open access doors using controllers to trigger the hotspots I already set up in AC. I'm also wondering about changing AC menus (there are 42 of them currently) to world space. Is this necessary / practical for all the AC menus in VR? Or should I choose only those ones that make sense when interactable in 3d space? Should menus that just give you updates on gameplay remain in screen space or will that jar the experience? Please help with some tips while I keep tinkering with the toolkit. Thanks!
Comments
Working with AC and VRTK
Resolving Main Camera VR conflict with VRTK
Video play test of adventure game he worked on using AC and VRTK
Reposted below:
Archiving some posts by @Alverik on the subject, here for future reference:
Working with AC and VRTK: https://adventurecreator.org/forum/discussion/5661/pyramid-2016-demo-now-out
Resolving Main Camera VR conflict with VRTK: https://adventurecreator.org/forum/discussion/5791/maincameravr-vrtk-conflict
Video play test of adventure game he worked on using AC and VRTK: https://www.youtube.com/watch?v=8EWqpCOswxI&feature=youtu.be
"When using VR with AC you have to setup AC as if you were using a custom character controller. I was also using a custom way to run hotspots and actionlists so I had also configured it to Custom
...3rd person VR requires a little more finesse. Moving the player in VR (AKA the camera), has to be done carefully or else you'll get the Player nauseated...
...a lot of starting players get nauseous from just Touchpad walking, and having the player follow the Character around continuously could be an issue if you aren't careful (if your code to get the Player to follow the Character isn't smooth it could be a problem).....
.....Remember the first, most important rule in VR is to never take control of the camera away from the player. You can move the player around, but never the camera itself.
...(Well, position might be not be overriden in headsets that don't have RoomScale, not sure what would happen with Oculus Go, since I don't have one of those...).(edited)
"...Well, depends on how your own codebase works. To avoid having to set scripts on all your players (I had sim, Rift and Vive) you'll want to add your custom scripts (if any) at runtime (by placing them in the same objects you find VRTKs's scripts). This makes it easy to access the hands. You will basically be accessing the ControllerEvents scripts to Access input.
https://www.dropbox.com/s/ck6t77o2zqe2zmu/ACVR_ActionlistAssetTrigger.cs?dl=0
That'll teach you what you need to access VR input in scripts using VRTK (the link above). Anyway, be careful about input, some inputs only exist for some devices. For example, Vive controller's have less buttons than the Rift's (which makes Button Two always return negative). I think the Go also has less buttons than the Rift, so you'll have to play around with it."
The script opens up slots in the inspector you could plug action lists into, to react to the different VRTK inputs, I'm still trying to think through how to take advantage of that, ditto sorting out how to set up AC to use the VRTK character controller rather than its own.
Edit: It seems to happen when a link is pasted in the body of the comment rather than embedding it in text.
"Ummm, just letting everyone know (for those who don't want to do any extra scripting), that the idea to use the hotspot detector to make only hotspots that "touch" the controller activate, really does work. But the result of my testing were a little inconsistent. I attached Hotspot scripts on some walls (which are just stretched cubes), but for some reason the hotsposts only activate when the hotspot detector is contacting/intersecting right at the center of the wall. Somehow the Hotspots don't activate if the detector is entering/intersecting only the edges (even though the hotspot should encompass the whole wall). This happens even if the Hotspot detector is not attached to the controls so I'm guessing something else is causing it. It's like the detector needs to be just in the right place inside the hotspot to activate it (by the way, the hotspot detector is like the size of a football, not the usual player size)...
That's where I thought I could get the rotation started, it does not work.
This gets some kind of jerky feedback when the hoverCursor hovers over the hotspot, but seems to block the hotspot trigger from executing.
Relevant functions from the toggleRotate.cs script:
Next challenge is to figure out a way to get hotspots to 'attract' the VR cursor and make it snap to a locked on position after hovering for a few milliseconds. Trying to achieve this because I noticed that it gets a bit tricky getting the VR cursor to lock on to the hotspot manually, especially using a gaze type cursor arrangement like the ClickByHoveringCursorExample script affords.