[Help] Daydream controller input.

Hello,
I am working on a project using the daydream controller. In my project, I am trying to use the controller to move a game object along x(left right) and z(forward backward) axes.

Movement on the x axes have been accomplish easily with gyroscope. The problem is the z axes.

What I want to accomplish is when user extend his arm along z axes, my game object will go forward in that direction. When user bring controller closer to his body then the same thing but toward user body.

I dont know if there is any input with daydream controller that would help me accomplish this task. I already tried with accelorometer but it doesnt give my good result like the gyroscope for the x axes. I am also open to have user hold the controller in a different way than laser pointing forward if it is the only way to get input when moving the controller forward backward.

Hope this is clear.
Thank you.

 

That would work, but I would lose the sense of immersion. I'm working on a air hockey game and i want the paddle to be controlled by the movement of the controller. Using trackpad would make the game quite hard to play.

 

maybe think of forward/back rotation (x-axis) as an accelerator peddle (or joystick) to change the forward back velocity of the puck

 

I am not totally sure to understand what you mean. If you mean rotating the controller back and forth on the x axes (pointing controller up and down) to have the gameobject moving forward and backward, i already tried it and yes it works. But it isnt natural at all and quite hard to control.

I think detecting movement when hand is moving forward and backward is the only i could have the natural feeling that you actually holding the paddle.

I have no problem using gyro to move the gameobject left and right but forward backward is giving me headache.

 

Hello!

If you look at GvrArmModel (Which you can see being used in GvrDemo with the GvrControllerPointer prefab) you will see that it is calculating an approximation of the physical space of the controller based on the data provided by the controller. However, it is not possible to precisely detect when the controller is moving forwards and backwards. GvrArmModel has an option to enable use of the accelerometer that will give you some of the type of motion that you are looking for, but it won't be precise.

I suggest that you investigate alternative control schemes that are within the constraints of the data provided by the controller. You can use GvrArmModel as a starting point.

Thanks,

Dan

 

mat9054,

I'm wondering if you made any progress on this? I'm trying to do something very similar and have had some success with pointerPosition. However, I believe it is doing something funky to keep the controller in the normal laser pointer as noted on this page under arm model https://developers.google.com/vr/unity/controller-support Once it is rotated in a certain way positioning no longer makes sense.

Basically I want the controller to act as if it were a physical model in your hand to move and rotate in the scene. So far I can select the model, put it in a fixed space in front of the user and rotate it flawlessly using either pointerRotation or
GvrController.Orientation. I then want to be able to displace the model from the fixed position based on how the controller is being moved by the user in meatspace regardless of its rotation/orientation. I don't need it to be crazy accurate just that if you move it towards/away/left/right/up/down it follows your movements. It seems something between the arm model, arm model offsets and the gyro/accelerometer can get me there, but it is difficult to test these combos with the technical preview and not much documentation or samples around them. I haven't tried the beta yet as I don't read good things here about it.

Any ideas Dan?

 

Are you using GvrControllerPointer like in the GvrDemo sample scene or are you adding your own object? Either way, try checking "Use Accelerometer" in GvrArmModel on the object GvrControllerMain. If you are trying to create your own object that follows the arm model instead of using GvrControllerPointer, this is what you should do:

1. Create a GameObject to represent the controller. Add whatever visuals you want to it.
2. Make this GameObject a sibling of the camera. All positions and rotations from the Arm Model are relative to the camera.
3. Add the script GvrArmModelOffsets to the GameObject. Set the "Joint" to "Wrist".

This is about as accurate as it will get to your actual movements in meat space. Accelerometers are not very precise so the arm model constrains how much the accelerometer impacts the controller position to avoid drift.

Thanks,

Dan

 

@mat9054

Maybe too late to help but...

You've tried using controller like laser pointer to point to where you want paddle to be:

Left right movement maps well, there is a good yaw range used from table left to right. But pushing the paddle in/out Z by pitching controller... well as you've discovered; the trig makes the pitch of the controller cover only a very thin sector, and so the paddle is too sensitive/glitchy. But don't disregard pitch controlled paddle Z, you can solve the bad control:

Make the laser pointer line act like a weighty elastic rod in just the Y axis (without any inertia), that is: the more the controller is pointed upward: the bendier the line is. Tune it such that you get a good feeling for the Pitch:ZDist mapping ratio. The line itself may be rendered lightly so user can get an intuitive feel for the control faster. For higher paddle spatial resolution you may smooth the paddle position (in both X&Z) and make the line bend to meet it. Tune the smoothing such that max paddle acceleration (when controller is snapped one side to other over a frame or so) is comparable to what can be achieved using a real arm with real paddle.

Any scheme using accelerometer: you'd be trying to derive a constant position by integrating a noisy acceleration signal and so you would need return to home function (paddle constantly drifts back to center) to prevent paddle wandering off, and so a constant non centered position could not be maintained without constantly pushing further out. It would be very irritating for user.