Mouse sensitivity in WebGL - WAY too sensitive

So we're trying to move our game from the plugin over to WebGL.
Our game is an FPS, which means the cursor is locked and hidden while playing.
For some reason, the mouse axes are a lot more sensitive in WebGL than they are the editor/standalone/plugin - our character turns a lot faster in the WGL build than everywhere else.

I set up an empty test project, and all it does is lock the cursor and display the mouse movement deltas and tracks the maximum absolute delta. Playing it in the editor yields results in the 5-10 pixels per frame. In the browser, somewhere in the 30-70 range. I haven't changed any of the input settings, this is a brand new test project.
I've attached the project zipped up for anyone to try it and see. The results also differ a bit between browsers (I tried FF and Chrome), so I can't even just multiply/divide by some predetermined number to 'normalize' the sensitivity.

I was thinking of just making a normalized movement speed when there is mouse movement at all (rather than check how much movement), but I believe that will prevent players with gaming mice from being able to cycle their DPI on the fly, which we'd rather not do. Is this a bug? Intended? Beyond Unity's control?

Side note: Upload says max 4MB but I tried uploading the zipped project with the build which was 3.2MB and it said too large. So build not included...

 

Bump? This is still an issue.

 

hummmmm this silence ^^

 

Hello,

This problem is present since the beginning of your webgl export.
The mouse feeling is completely different when you test on the editor and webgl build.

First, the sensitivity is around 2 time faster in a webgl build than on the editor (look like the GetAxis do not have the same value in the editor than webgl build).

Secondly, it's the feeling when you play an fps game in a webgl build compared to the editor or the old unity web player. It's horrible to play an fps game now on a webgl build because of the sensitivity problem and also because when you make a quick movement with the mouse the feeling is so bad. In my fps game (unity web player version) the mouse feeling is normal and we can play fluently. When i switch to the webgl version (exactly the same code) the mouse feeling is so bad.

It's the case for all fps game released with unity webgl. I have tested a lot of webgl fps game build with unity and everytime it's the same, the mouse feeling is bad.

You can test dead trigger here https://apps.facebook.com/deadtrigger_ii/ or my game here http://www.war-attack.com
The mouse feeling is bad ....

Here : http://www.asr-games.net/testing/mouse/ you have a simple build using the unity standard assets (FirstPersonCharacter). Everything work but the feeling when you move your character and move your mouse is bad if you compare it from the editor.

You can download the unity project here : http://www.asr-games.net/testing/MouseLooking.zip

Simply test on the editor and see how much you need to move your mouse for a 360 degrees and do the same on the webgl build here http://www.asr-games.net/testing/mouse/

Normally, if you have to move your mouse 2/3 centimeters on the editor, you should only need around 1 centimeters for doing the same movement on the webgl build. Also, you can check the mouse feeling by making some fast movements and see the difference bettween the editor/webgl build.

The report bug number : 1012749

Thank you

 

Thank you for the information.

Yeah, we can scale the mouse movement but even with that, the mouse movement/acceleration do not feel like in the editor or like previously by using the unity web player.

It's not easy to explain if you are not a regular first person shooter player.
At the first view, everything seem to work perfect and it's the case, it's working but the precision/accuracy is so hard if you compare it from the editor or desktop version.

As exemple, some of my players who continue to play my game with the unity web player are not able to play the same way on the webgl even with the same code.

- First because of the sensitivity difference between the editor/ WebGL build (repoduced by the unity staff)

- And also because of the precision/accuracy or mouse acceleration problem.
I don't know if the bad feeling mouse acceleration problem come from unity or from the web browser but something is wrong somewhere.

Thank you

 

Hi,
Way back I manage to report a similar problem which Unity kindly submitted to google: https://bugs.chromium.org/p/chromium/issues/detail?id=599152
The problem with a bug like this is that it is about feel...

 

Do you have any news on this @Marco-Trivellato ?
Thank you.

 

I have the same problem, moving the mouse a little and the player just whips around really fast.

 

I can attest to the same issue. WebGL builds seem to have massively increased sensitivity. Would love a fix for this.

 

For anyone looking for a workaround, values returned by Input.GetAxis("Mouse X") and Input.GetAxis("Mouse Y") are exactly twice as large in WebGL. A movement of one pixel returns 0.05 in the editor and 0.1 in WebGL. This does not seem to differ between browsers. So simply halve the value for your WebGL build.

 

I have noticed this long time ago and i divide by 2 the input but it's still more faster and the feeling is terrible compared to the editor or old Web Player.

 

i have the same problem, do you have any solution my friends?

 

I tried solving this mouse sensitivity problem by adding a slider (for mouse sensitivity scaling) in my 'Controls Menu', which enables the user to choose their preferred scale factor. This solution works in my stand alone build, I can even set to zero and there will be no mouse movement (as expected), but this solution does NOT work in my webgl build and currently I do not know why? If I set the sensitivity to zero, the mouse shouldn't move at all, but it still does and at the same fast annoying speed. Does Unity handle static variables differently in webgl than it does in the editor or stand alone? It shouldn't...

 

It's not just sensitivity problem.
When you move mouse slowly, sensitivity feels too low, but when you move mouse faster, sensitivity feels too high.

Hi @roka, did you found solution for this problem?

 

No, it's still the same for me.

 

Hello,
I had the same issue, im not sure if it has to do with the screen size when you export it to WebGL. My workaround was a bit dirty but since it was just a quick prototype it worked. Hopefully you might be able to do something similar.

Basicall I ended up clamping the mouse delta from -1 to 1 and then multiply the value for my desired speed. That way the webGL version behaves in the same way that the Unity version.

//CLAMPS
mouseDelta.x = Mathf.Clamp(mouseDelta.x, -1, 1);
mouseDelta.y = Mathf.Clamp(mouseDelta.y, -1, 1);
scrollValue = Mathf.Clamp(scrollValue, -1, 1);

Its just a dirty fix but hopefully we can get a better anwer.

 

Same problem, post above was a perfect solution. Praisebe~

 

Hey I'm an absolute beginner. Would like to fix this in my first webgl game. Where exactly do I add this code?

 

To anyone stumbling on this post, remistorms' answer was close to the desired effect, but I found it dampened large motions too much. Here's what I did instead:

Code (CSharp):

1. var x = Input.GetAxisRaw ("Mouse X");
2. var y = Input.GetAxisRaw ("Mouse Y");
3. if (Application.platform == RuntimePlatform.WebGLPlayer) {
4.   x = MouseLook.DampenedMovement (x);
5.   y = MouseLook.DampenedMovement (y);
6. }
7. x *= sensitivity; // your custom sensitivity value...
8. y *= sensitivity; // ...which may be user-adjustable
9.  
10. // define this function:
11. public static float DampenedMovement (float value) {
12.  
13.   if (Mathf.Abs (value) > 1f) {
14.     // best value for dampenMouse is 0.5 but better make it user-adjustable
15.     return Mathf.Lerp (value, Mathf.Sign (value), dampenMouse);
16.   }
17.   return value;
18. }

Also note: sensitivity seems to vary by browser/OS. I only tested on Edge/Firefox/Chrome on Windows 10, and found that I had to multiply the original (standalone) sensitivity by 0.25 for Chrome and Edge, and about 0.5 for Firefox, to make it feel similar to standalone. Try to find a good default value and make it user-adjustable.

 

Hello everyone!

I was having the same issue, and the workaround that I found was this:

0.- To try the understand the problema, I did the follow excercise.

1.- Make a new project.
2.- Download Stantard FPS of Unity, Cinemachine and New Input System
3.- Create a new scene with a nested fps prefab.
4.- Create a floor and some props.
5.- Buils for HTML 5.
6.- Upload to your server or itch.io

The result is that, the DEFAULT value of FPS SCRIPT for the FPS prefab is too LARGE or HIGH for HTML.



Tha value is the mouse delta for the rotation of the player.

I set the same proyect but with values from 0.5 to 1.0 and the problem was controlled.

Hope you guys can make a better solution for Unity and HTML. We need that HTML export can respect the values on editor.

Cheers.

 

This more or less did the trick for me as well!

You can also get delta's from the browser. Maybe it's too performance heavy but I wonder if it's possible to send the browser delta to Unity WebGL.

Code (JavaScript):

1. function logMovement(event) {
2.   log.innerText = `movement: ${event.movementX}, ${event.movementY}\n${log.innerText}`;
3. }
4.  
5. const log = document.getElementById('log');
6. document.addEventListener('mousemove', logMovement);

Still, it's pretty crazy this issue is 6 years old and still hasn't been fixed.

 

macOS Ventura, M2 chip, it is faster in Chrome or Safari than in Editor and Standalone macOS build.

The solution in this thread doesn't work for me properly. It is still faster in browsers.

I use this method in LateUpdate (going to use this in my basketball asset):

Code (CSharp):

1.         horizontalDelta = Input.GetAxis(horizontalAxis);
2.         verticalDelta = Input.GetAxis(verticalAxis);
3.  
4. #if UNITY_WEBGL && !UNITY_EDITOR
5.  
6.         horizontalDelta /= 10f;
7.         verticalDelta /= 10f;
8.  
9. #endif

 

oof my WebGL build cursor sensitivity is way more than how it is set in the Editor. That's a big problem

 

Same problem, not sure if relevant but this extends to anything with a mouse scroll wheel input as well, where the sensitivity is waaaaaay over 2 times of what it would be in the unity editor