Oculus Quest: Raycast laser color constantly reset

[bilkusg]

As described in this forum issue, using a VRExperienceHelper, the function

changeLaserColor

has no effect on the color of the laser beam from the oculus quest controllers.

The following Playground example shows the result-
Example

If you run this in VR on an Oculus Quest ( and possibly other headsets ) the laser ray should be red, but it remains white.

The reason is that every time round the render loop, the VRExperienceHelper makes as call to _castRayAndSelectObject, which resets the laser pointer color in a hard-coded way. There seems no obvious workaround, as even trying to reset the color in each render loop doesn't have any effect.

[bilkusg]

Hmm, sorry to have taken so long, but I've finally been able to get round to testing this.
What happens now with the oculus quest is that the ray color is indeed set initially, but as soon as the Quest Controller mesh is loaded, something overrides the laser pointer display, and it reverts to being white all the time. So effectively the laser pointer color still won't change.

[RaananW]

Hi @bilkusg , does setting the color after the mesh was loaded work?

I'll be able to inspect the issue soon

[bilkusg]

No. Even if I try and set it inside the render loop it still does nothing once the quest controller mesh is loaded. To be precise, when the VR first starts, the controller is not visible but the ray is, and is the color I set. Then a few moments later, the controller mesh appears, and the ray turns white.

[RaananW]

I haven't tested yet. I will reopen and make sure to address this before 4.1 is released

[bilkusg]

In case it helps, the problem seems to be in Cameras/VR/webVRCamera.ts round about line 794 where the function activateLightOnSubMeshes is defined. As far as I can tell, the laser pointer with the correct color is overlaid by a hard-coded pointer which is part of the mesh on the Quest controller and gets lit by that function, thus masking out the laser pointer as set elsewhere.

[RaananW]

What function are you using to set the color? are you using setLaserColor or updateLaserColor?

This will make it "redish":

https://playground.babylonjs.com/#LZUEAR#3

The reaon it is "redish" and not red is the diffuseColor of the laser pointer. I will reduce is to a grayer value so the red will be more prominent. But make sure you use set and not update.

[RaananW]

Sorry, i said set and didnt change the function... here:

https://playground.babylonjs.com/#LZUEAR#6

[bilkusg]

I have been using 'set' and it's still not working, even with your example above. But if I pass defaultLightingOnControllers:false to createVRExperience as in

https://playground.babylonjs.com/#LZUEAR#10

then the colors are visible, but the controller is no longer illuminated as my normal environment is dark ( it's an astronomy simulation )

What seems to be happening is that when the default light for the controller it's illuminating the laser as well as the controller, as a result of which the intrinsic color is being overwhelmed by the additional light. But I'm not entirely sure....

[RaananW]

This is a lighting issue, as you said. Two different approaches to fix it right now -

https://playground.babylonjs.com/#LZUEAR#11

and

https://playground.babylonjs.com/#LZUEAR#9

It does work, simply harder to see when two white hemispheric lights are on. I will see what I can do about excluding the laser pointer from the lighting.

I leave this issue open as a reminder, but will probably deal with it in another one.

[bilkusg]

OK. I can live with the workaround for now. Many thanks for that. Is it worth noting this in the documentation somewhere pending an eventual fix - I suspect others will find it as confusing as I did if they try to do this and don't find this thread. I'm happy to help if I can.

[RaananW]

The documentation needs to be updated, for sure. If you want to point out exactly where (or submit a PR with the change) it will be a great help.

Having said that - WebVR is deprecated (https://developer.mozilla.org/en-US/docs/Web/API/WebVR_API) , long live WebXR . We of course want everything to be up to date, but we invest less time in fixing WebVR issues and more time in improving the (full) XR support coming up in 4.1. I am working on the documentation now, hoping to finish by next week