HTC Vive controllers

[Xipherx]

Hi,

I'm evaluating Babylonjs for porting an existing naval ship virtual navigator from Unity 3D to webGL.

I have ported 90% of the system in two months ( thanks babylon.js !!!! ) and now I have to implement VR part of the project.

I started with HTC Vive, that I consider one of the best hardware at the moment, and in only one day I had VRDisplay integrated using WebVRFreeCamera, but now I need to integrate controllers.

At the moment I'm trying to use gamepad API retrieving controllers position using gamepad.pose attribute but I cannot understand values coming from this which origin they have.

I realized that the controllers position is not related to the HMD position but maybe to the center of the room? But if this is the case where can I retrieve that origin?

What's the best way to visualize Vive controllers position?

Thank you very much in advance guys!!

[RaananW]

Hi!

I am getting my vive back in a few days and was planning to find the time and integrate the vive controllers in the framework (using the already-integrated gamepad api, just like you did it).

I don't have answers to your questions, as I have never tested this, but I would assume that the position correlates to the same world the HUD is. Again, I will be able to test it when I have the vive back and provide a better answer (and a better integration )

 

[Xipherx]

Thank you very  much.

I'll investigate further in the meanwhile.

One more  question: I used navigator.getgamepads() method to accessing gamepads, you said "already integrated gamepad api" you meant that I could  use a Babylon class for accessing controllers? Maybe using events insted of polling for testing buttons? Would be great!!!

[RaananW]

Yes!

Babylon has Gamepad support already (https://github.com/BabylonJS/Babylon.js/blob/master/src/Cameras/Inputs/babylon.freecamera.input.gamepad.ts) . The plan is to have the controllers as user input for your camera.

[jellix]

Sounds really great, guys!

I'd love to be your test candiate!

[Xipherx]

Ok, maybe I found the problem: the current gamepad (controller) position is in the gamepad.getPose() result, but it's calculated on the last HMD position, hence, if I update the HMD position calling camera.resetToCurrentRotation() before asking the controller position values are good.

For now is a simple and dirty solution that works in my case because the application is intended as a sitting mode VR, in a near future I have to find another way because I need to walk around the room.

 

[Steffen]

Hi @RaananW, @Xipherx,

I haven't found any link or post on how to use the gamepad class of babylon. I am using the latest nightly of v2.5. Target is to get the vive controllers working - for teleporting within my scene or interacting with other objects. It's possible to get the current state of all the different buttons and the trackpad information is it?

Thanks.

[jellix]

any news on vive controllers? 

[GameMonetize]

Ping @davrous

[RaananW]

Which pinged me

God, I haven'T been here for ages! Sorry guys!

The only thing I can say is "I'll do it asap", unless davrous beats me to it. I have been too busy lately. My Vive is not even connected! Damn...

[GameMonetize]

Lol while reviewing the forum like every morning, I was pleased to see so many raanan's posts today

[jerome]

who's that guy ?

[jellix]

Would be soooo great to have the controllers getting to life!

I am working nearly every day with the vive and it's controllers. I can say that WebVR is absolutely stable on working with it. So it would we a great benefit to have it in babylon.

@RaananW Google just released google earth for HTC Vive. Today I tried it and I can say: Get your Vive to life again just for experiencing the world in 3D. It is soooooo amazing!

[davrous]

Hi guys,

Latest status from @RaananW is that WebVR 1.1 has removed supported for Gamepad input like WebVR 1.0 had. He's then currently thinking about implementing both spec but as they're moving fast, it's complex to follow. For instance, if you're using latest version of Chrome, our current WebVR implementation will break. But if we're switching to WebVR 1.1, it will work again but we'll lose gamepad support... We'll keep you posted.

David

[Korreca]

I've been able to run one Vive's gamepads. Each of them is a different Gamepad and only have LeftStick, so for the moment I have done the following:

1. Disable chrome:flags Gamepad Extensions (even an Xbox Gamepad doesn't work)
2. Set a key to send the image to Vive
3. Inside key function: attachControl(), and immediately after, camera.inputs.addGamepad(). You must add the gamepad after, not before
4. Limit babylonGamepads array to 1 element on onGamepadConnected, and add a new condition to _updateGamepadObjects (gamepads && this.babylonGamepads.length === 0), otherwise you enter an infinite loop

In FreeCameraGamepadInput.prototype.checkInputs, checks against rightStick before normalize Right values or addRotation

But... there is a problem... camera rotation never updates!! Its always the same :(, so even if you move, handle it is impossible because the direction never changes

[jellix]

Hi,

don't know much about the background-technology of using the vive controllers. But one question that hopefully doesn't look like an attack: Another javaScript framework is already working wonderfully with the controllers. Shouldn't the developers have the same problems? Or could it even be an inspiration to port the functionality to babylon? (I think you know which framework I mean but I don't want to name it right here because I don't want to advertise another framework ;-))

[GameMonetize]

@Jellix: based on what  @RaananW told me, 3js implementation does not work anymore on latest build of chrome (where webvr 1.1 is supported)

[jellix]

Oh, I see.

So because I am developing a customer project that is running in a chromium browser I have to be careful not to update that browser :-)

[GameMonetize]

Definitely! 

[RaananW]

Hi,

I have been playing a lot with the vive controllers. I have the 1.0 specs implemented, integrated in Babylon's Gamepad interface, but couldn't really use it, as Babylon is updated to the latest specs (1.1).

The controllers are still detected, but they don't expose the pose anymore (which is about the same thing that happened to the VRDisplay object). The buttons also don't work anymore (the 1.0 specs had both "pressed" and "touched" flags, which WORK. The axis was the position on the front trackpad. Again, those things don't work in 1.1 .

I will wait for the next update and see how we can integrate the controllers. I thought of maybe making a "legacy" WebVR camera, that will support the 1.0 specs, but this will be counterproductive. Sometimes patience is not the worst thing to have.

Oh, and @jellix - telling me that google earth is available was a huge mistake. I was stuck there for a few hours, walking on many many buildings. Didn't really help my son's "VR" time as well.

 

[jellix]

Hi @RaananW, can u say if there will be the same problems by using WebGL 2.0?

Because now some browsers support it as I mentioned in another thread. As a developer for customer projects that are only used in specific scenaries I don't have to look for solutions that are working for a wide range of users. So I already could use a WebGL 2.0 browser.

 

[RaananW]

Using WebGL 2.0 while a lot of browsers still only support 1.0 will require the developer to support fallbacks in case some WebGL 2.0 is called and it is not available.

Usually, your engine will take case of this for you (as in the case of mouse and touch pointers when using babylon.js). I can also say that everyone is pretty much excited about WebGL 2.0, so it will probably be integrated rather early. And knowing how @Deltakosh ticks (at least regarding Babylon.js) - you can be sure that all fallbacks will be implemented. Backwards compatibility is and always will be very important.

But we first want to know if everything is implemented, if the standard is kept, if everything works as expected. That's a sad truth about web standards - each browser manages to implement it a bit differently.