Search Unity

  1. Improved Prefab workflow (includes Nested Prefabs!), 2D isometric Tilemap and more! Get the 2018.3 Beta now.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice
  4. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

Google Cardboard Input using 5.6?

Discussion in 'AR/VR (XR) Discussion' started by astracat111, Jun 26, 2017.

  1. astracat111

    astracat111

    Joined:
    Sep 21, 2016
    Posts:
    379
    Hey there, I'm looking at developing for google cardboard using 5.6. The setup so far as been really easy and everything, but my question since there don't seem to be many demos for version 5.6 concerning cardboard...

    I understand that google cardboard basically has like one button, so the only thing I can think of is having a press, double press and long press to do everything (other than the whole turning your head sideways thing).

    I've been looking at videos online for using google cardboard and guides online but can't seem to find an answer to the simplest question, which is how do I use input with Unity 5.6? It's said to be native, right? So that means I don't have to import the google sdk?
     
  2. astracat111

    astracat111

    Joined:
    Sep 21, 2016
    Posts:
    379
    Okay, so for anyone looking for this information....VR in 5.6 is very easy to set up, I figured this out yesterday...

    The google sdk is bulky, annoying, and is not needed at all, here are the steps:

    1) Install Android Studio. In Android studio install at least Lollipop APK 5.0 for cardboard. Link Unity to this sdk in your Users/userNameGoesHere/%AppData%/ folder (where the android sdk is located after it downloads). Install latest java, install your phone drivers, hook in your phone to your comp, on your phone turn on USB debugging.
    2) Next, Edit > Project Settings > Player. Package name gets renamed to com.yourCompanyHere.yourGameNameHere. Check the box 'Virtual Reality Supported' and add in Google Cardboard.
    3) Select file, build settings, android, switch platforms. Select build and run and make sure your game builds and it comes up on your phone.
    4) Make the camera in your scene the main game camera. I rename it "MG_Camera". Now, when you build and run you will be able to look around with your phone, but you can't when you playtest. Instead of downloading the 100 files that are associated with the google cardboard sdk unity package that you find on google's website, just attach a mouselook.cs script (you can find these online) onto your main game camera. Add in #if UNITY_EDITOR at the top of it and #endif at the bottom of it. Now you have playtesting and building both working.
    5) For Input, do a raycast on your main game camera like this:

    Code (CSharp):
    1. using System.Collections;
    2.  
    3. //Change this script's execution to negative in Edit > Project Settings > Execution Order
    4. //(change it to something like -100 I suppose
    5.  
    6. using System.Collections.Generic;
    7. using UnityEngine;
    8.  
    9. public class MainGameCameraRaycast : MonoBehaviour {
    10.  
    11.     public RaycastHit raycastHit;
    12.  
    13.     void Update () {
    14.         Ray forwardRay = new Ray(transform.position, transform.forward);
    15.         Physics.Raycast(forwardRay, out raycastHit);
    16.     }
    17. }
    You can attach this script to your main game camera. Just name it "MainGameCameraRaycast.cs".

    6) [not helping with this part too much: ] Make a canvas on your main game camera or on an object that's a child of the main game camera. Set it to 'Screen Space - Camera' and select your camera. Create a 2D object as a child of the canvas that represents your cursor. Animate it in Unity creating the 'Idle' 'Hover' and 'Select' animation states. Make it in scripting so that when the raycast hits and it's a particular object layer, the cursor reacts (but changing it's state to 'Hover'). The basics are like:

    Code (CSharp):
    1.  
    2.  
    3. //The MainGameCameraRaycast script HAS to run before this runs, so you have to
    4. //make sure this runs second to it in script execution order (and in fact most scripts
    5. //to tell you the truth)
    6.  
    7. private MainGameCameraRaycast mainGameCameraRaycast;
    8. private RaycastHit raycastHit;
    9.  
    10. void Start() {
    11.     mainGameCameraRaycast = this.gameObject.GetComponent<MainGameCameraRaycast>();
    12.     raycastHit = mainGameCameraRaycast.raycastHit;
    13. }
    14.  
    15. void Update() {
    16.     //This uses layer 1, we could also though use (gameObject.tag == "myTagGoesHere")...
    17.     if (raycastHit.collider.gameObject.layer == 1) {
    18.         //Change cursor state here to hover.
    19.     }
    20. }
    21.  
    7) Now here's the trick with input that I wasn't understanding that's really really simple: The Fire1 button is the button used in google cardboard (and the only button for that matter), so you just have to basically use:

    if (Input.GetButtonDown("Fire1"))[/code]

    I'm not quite done with this part, but to create a proper control scheme my thought was that there needs to be 3 buttons. This is achievable with a single button if we have:

    Button A) One Quick Press
    Button B) Double Press
    Button C) Long Held Press

    I'll post my finished script maybe today if I get to it today, but the theory is like this...You need the following variables:

    InputEvent_CooldownTimer
    Button_CooldownTimer
    Button_NumberOfPresses

    You maybe do something in theory like... (attaching the finished script to your main game camera)

    Code (CSharp):
    1.  
    2.  
    3. //OneShortPress - 0
    4. //DoublePress - 1
    5. //LongHeldPress - 2
    6.  
    7. public enum InputEvent { OneShortPress, DoublePress, LongHeldPress, Idle }
    8. public InputEvent inputEvent = InputEvent.Idle; //idle to start
    9.  
    10. Start() {
    11.   InputEvent_CooldownTimer = 0;
    12.   Button_CooldownTimer = -1;
    13.   Button_NumberOfPresses = 0;
    14. }
    15.  
    16. Update() {
    17.   if (fire1 held down && InputEvent_CooldownTimer > 0) {
    18.     Button_CooldownTimer += 1;
    19.   } else if (fire1 NOT held down && Button_CooldownTimer > 0 && InputEvent_CooldownTimer > 0) {
    20.     Button_CooldownTimer -= 1;
    21.   }
    22.  
    23.   if (InputEvent_CooldownTimer > 0) {
    24.      //We are inside of a button event here, so give it some time before we can detect the next event...
    25.      InputEvent_CooldownTimer--;
    26.      Button_CooldownTimer = 0;
    27.      Button_NumberOfPresses = 0;
    28.   }
    29.  
    30.   if (fire1 just released && InputEvent_CooldownTimer > 0) {
    31.       if (Button_CooldownTimer < 10 && Button_NumberOfPresses < 2) {
    32.         //Trigger OneQuickPress Event Here
    33.         Button_CooldownTimer = 0;
    34.         inputEvent = InputEvent.OneShortPress;
    35.         InputEvent_CooldownTimer = 30;
    36.       } else if (Button_CooldownTimer >= 10 && Button_CooldownTimer <= 40) {
    37.          if (Button_NumberOfPresses < 2) {
    38.            Button_NumberOfPresses += 1;
    39.          } else {
    40.            //Trigger DoublePressEvent Here
    41.            inputEvent = InputEvent.DoublePress;
    42.            InputEvent_CooldownTimer = 30;
    43.          }
    44.       } else if (Button_CooldownTimer > 40) {
    45.            //Trigger LongHeldEvent Here
    46.            inputEvent = InputEvent.LongHeldPress;
    47.            InputEvent_CooldownTimer = 30;
    48.       }
    49.   }
    50.  
    51. }
    52.  
    It would be something along those lines.

    I'll be creating this script more than likely tonight so I'll re-post it as it's just theory and probably doesn't work.

    In any case, you'll then be set up to create games using VR Cardboard. Why cardboard? Because most people right now are using cardboard headsets with their phones so it has a very wide reach. Also, this makes it so that people can just use their phones without headsets to play.
     
    Last edited: Jun 26, 2017
    StevenPicard and DerrickBarra like this.
  3. DerrickBarra

    DerrickBarra

    Joined:
    Nov 19, 2013
    Posts:
    73
    Nice writeup on this solution, even for devs using the GoogleVR SDK, if they run into a bug with their Cardboard app then they can still use this as an alternative solution.
     
    astracat111 likes this.
  4. StevenPicard

    StevenPicard

    Joined:
    Mar 7, 2016
    Posts:
    425
    astracat111 likes this.
  5. DerrickBarra

    DerrickBarra

    Joined:
    Nov 19, 2013
    Posts:
    73
    Hey Astracat, do you have a good solution for the VR camera that cardboard uses?

     
  6. Selzier

    Selzier

    Joined:
    Sep 23, 2014
    Posts:
    579
    Definitely no need for GoogleVR SDK anymore, new project, set build target to Android and enabled Virtual Reality Supported in player settings and set Cardboard as the target.

    For Input, we've put together "Mobile VR Interaction Pack" which handles Gaze Input, Reticles, Outline, Object Distance, and UIs:
    https://www.assetstore.unity3d.com/en/#!/content/82023

    For Player Movement, Mobile VR Movement pack:
    https://www.assetstore.unity3d.com/en/#!/content/69041

    And the newest one was Mobile VR Inventory System for something like an Adventure game or RPG:
    https://www.assetstore.unity3d.com/en/#!/content/91529

    These were built to replace the GoogleVR SDK as it got really annoying with the constant changes, huge downloads, and if you just want to make Cardboard Games (Not Daydream) the GVR sdk is practically worthless.
     
    astracat111 likes this.
  7. AvGaz

    AvGaz

    Joined:
    Dec 21, 2012
    Posts:
    62
    I'm interested in your assets, I notice the description for the movement pack recommends GVR v1.03 or 1.20, but I take it it would work without that, and would you still recommend such an old version? I've run into a multitude of Cardboard issues (tried sdk 1.6 and 1.70) during build (mach-o linker error, GvrAudio error etc.) and if you're assets can replace it I probable would buy more.

    Could you please make the buttons have a progression color if gaze is on them though :) Thanks.