so a while ago I’ve reported a bug that causes UE4 to completely ignore windows mouse pointer speed and take just raw mouse input when panning in editor windows, such as blueprint or material editor. The bug was reproduced by the staff and logged into issue tracker here: Unreal Engine Issues and Bug Tracker (UE-38571)
I was absolutely shocked to see the bug was marked as by design, as it shows very concerning apathy towards quality of the product.
I just recently returned to learning UE4 and I found out I am having very hard time doing simple tasks such as translating scene objects using move, rotate and scale gizmos. As it turns out, this bug affects translation gizmos as well. As soon as I click move or rotate viewport gizmo, my mouse cursor shoots far away, and I have to do surgeon-precise movements to be able to put it where I want to.
I have high DPI mouse and in Windows, I have mouse sensitivity set to be 1 tick down from the center, but even such a small change makes huge difference.
I really can’t believe such a severe issue is not getting any attention at all. I struggle to believe UE4 users just learned to live with this.
EDIT:
I have yet again recorded a video showcasing this issue:
It makes interaction with UI in many places very difficult.
While I can understand reasoning for accepting raw mouse input when it comes to actual play mode, where you interact with your game through player’s perspective, accepting raw mouse input and bypassing window’s cursor speed settings for user interface part of the engine is insane in my eyes.
The editor and engine use raw input (values coming directly from the hardware) instead of the standard mouse input on windows or any other platform. This is to avoid inconsistencies with pointer acceleration and to provide more accurate results. You can read about it here for windows if you are curious.
So this is definitely not a bug as we intentionally wrote it this way. Have you tried using the mouse sensitivity settings Edit->Editor Preferences and search for Mouse Sensitivity?
thanks for a quick response but I think there has been misunderstanding. As I wrote, raw mouse input makes complete sense for 3 dimensional navigation, such as viewport orbit, viewport movement or actual gameplay movement, but it makes no sense for 2D user interface interaction, which is happening in two axes, such clicking and dragging move, scale or rotate gizmo, or for example panning material editor schematic view using right mouse button.
So I have followed your instruction, went to editor preferences and adjusted Mouse Sensitivity, and I am observing exactly what I would expect - 3D space navigation, such as viewport movement of viewport orbit are affected, but 2D user interface interaction, such as dragging move, rotate or scale gizmo, or panning graphs in material editor or blueprint are unaffected. Or in other words, that setting has no effect exactly on the UI interactions I am having problems with.
So if your raw mouse input sensitivity happens to significantly differ from windows cursor speed setting, you get radically different movement speed, which really messes with muscle memory every single time, and makes it hard to position scene objects using transform gizmos. Basically, you move your mouse cursor over move gizmo arrow at a certain speed, which your brain is accustomed to, and then as soon as you click and hold down mouse button on the arrow to move the object, UE4 switches mouse input to raw one that is significantly more sensitive.
I have Zowie mouse that has hardware DPI switch that goes between 1600 and 3200, while 2400 is a sweet spot for my screen, so I use 3200 and one less tick in windows cursor speed setting.
Since mouse sensitivity setting does not affect 2D user interface interactions mentioned above, I still stand behind my opinion this is a bug/design flaw.
I highly doubt this behavior can be justified as “by design”. I can understand and even to some point relate to instinctive defense of a behaviors that are in place for a long period of time, perhaps due to the fact, that changing the behavior may throw some of the existing users off (the infamous xkcd workflow slide: xkcd: Workflow ). Regardless, I think that this still needs to be addressed, as it goes against basic guidelines of UI/Usability design.
The reason you do not get more complains for this is because most of the new as well as existing users don’t really want to spend time thinking about it. They just open the editor, click some some object in viewport, drag it, and go “Wooow, that moves weirdly - guess I will have to use to that…” and they eventually get used to it indeed, but it does not mean it’s a good thing. If you lose a leg and get a prosthetic one, you will eventually learn to walk with it almost as efficiently as with the real one, but arguably, having two, real, working legs is always better
Or because most people are just sane enough to NOT maximize their mouse dpi and then interpolate the speed through Software. There’s ZERO advantage of High dpi with interpolation over Normal DPI without interpolation. Just lower your DPI till you don’t need any software Interpolation… That will solve your problem and also give you a more precise mouse while maintaining it’s speed.
It’s described in the post #3. I have Zowie mouse that has no drivers, only hardware DPI switch, that goes from 1600 to 3200, 3200 being closer to ideal 2400DPI for my mouse to screen ratio and preferred sensitivity. (Upscaled 1600 feels a bit less precise than downscaled 3200). If I set the cursor speed to middle, and use hardware switch only, then 1600 is way to slow for me while 3200 being way too fast.
However, I mainly do not see how this is relevant. Even if it was not about DPI, just about enhance pointer precision feature of Windows, you would still get different mouse curve in some parts of the user interface where it makes no sense to alter it, for any reason.
Let me put it different way:
Current state:
If you do not use enhance pointer precision, and have windows cursor speed at the default value, you will experience no problems.
If you do use enhance pointer precision and/or have windows cursor speed at a value other than default, you will experience problems.
Proposed state:
If you do not use enhance pointer precision, and have windows cursor speed at the default value, you will experience no problems.
If you do use enhance pointer precision and/or have windows cursor speed at a value other than default, you will experience no problems either.
I can’t see how proposed state is worse than original one?
I have the same issue. High DPI mouse and no option to lower the sensitivity for UI, which leads to very uncomfortable workflow when it comes to positioning nodes etc. Is this going to be fixed?
