Camera fly mode is broken on OSX #45771

New Issue

Jose Mayi · 2015-08-12T20:12:29+02:00

Jose Mayi commented

2015-08-12 20:12:29 +02:00

System Information
Operating system and graphics card
Mac OSX 10.10.4; Intel Iris Pro 1536 MB

Blender Version
Broken: 2.75a c27589e

Short description of error
Whenever I go into camera fly mode by pressing shift + F, it allows me to move the camera with the WASD keys, but does not allow me to rotate it with the mouse. This only happens whenever I change the default layout in any way.

Exact steps for others to reproduce the error
There is no file attached because this can be reproduced with a default blender scene.

Open up blender
Dismiss Splash Screen
Go to the layout dropdown and change your layout to anything other than "Default"
Hover over the 3D view and go into fly mode by pressing Shift + F.
At this point, you can move the camera with the WASD keys, but mouse movement has no effect over camera's rotation...If you change your layout back to Default, and go into fly mode again, it works perfectly fine

This is the issue with the blender build stated above. Last time this was working was when I was in version 2.73 (did not test in 2.74). I also awn a Windows PC running Windows 10 and I don't seem to have this issue there.

Another way to repro the issue other than changing layout through the dropdown is to hover over the 3D view and press either the "N" or the "T" keys to bring/hide the menus on the sides....This also seems to cause problems

**System Information** Operating system and graphics card Mac OSX 10.10.4; Intel Iris Pro 1536 MB **Blender Version** Broken: 2.75a c27589e **Short description of error** Whenever I go into camera fly mode by pressing shift + F, it allows me to move the camera with the WASD keys, but does not allow me to rotate it with the mouse. This only happens whenever I change the default layout in any way. **Exact steps for others to reproduce the error** There is no file attached because this can be reproduced with a default blender scene. 1) Open up blender 2) Dismiss Splash Screen 3) Go to the layout dropdown and change your layout to anything other than "Default" 4) Hover over the 3D view and go into fly mode by pressing Shift + F. 5) At this point, you can move the camera with the WASD keys, but mouse movement has no effect over camera's rotation...If you change your layout back to Default, and go into fly mode again, it works perfectly fine This is the issue with the blender build stated above. Last time this was working was when I was in version 2.73 (did not test in 2.74). I also awn a Windows PC running Windows 10 and I don't seem to have this issue there. Another way to repro the issue other than changing layout through the dropdown is to hover over the 3D view and press either the "N" or the "T" keys to bring/hide the menus on the sides....This also seems to cause problems

Jose Mayi commented

2015-08-12 20:12:30 +02:00

Changed status to: 'Open'

Jose Mayi commented

2015-08-12 20:12:30 +02:00

Added subscriber: @xDarkProdigy

Bastien Montagne commented

2015-08-12 20:23:01 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2015-08-12 20:23:01 +02:00

Cannot reproduce it on linux either here (debian testing 64), so assuming it’s OSX-specific…

Bastien Montagne changed title from ~~Camera fly mode is broken~~ to Camera fly mode is broken on OSX

2015-08-12 20:23:43 +02:00

Bastien Montagne commented

2015-08-12 20:23:43 +02:00

Added subscribers: @jensverwiebe, @Sergey

Julian Eisel commented

2015-08-12 20:25:36 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2015-08-12 20:25:36 +02:00

Can't reproduce either. Could you try if disabling Continuous Grab (UserPrefs->Input) changes anything?

Can't reproduce either. Could you try if disabling *Continuous Grab* (UserPrefs->Input) changes anything?

Jose Mayi commented

2015-08-12 20:40:08 +02:00

Just tried disabling Continuous Grab, but the result was still the same.
Here are the settings I have for mouse input:

Just tried disabling Continuous Grab, but the result was still the same. Here are the settings I have for mouse input: ![Mouse Settings.jpg](https://archive.blender.org/developer/F223757/Mouse_Settings.jpg)

Jose Mayi commented

2015-08-12 20:49:54 +02:00

Just tried booting up in safe mode to see if any programs I have could be causing an issue, but the issue is still there

Julian Eisel commented

2015-08-12 21:17:33 +02:00

Hmm, okay, next thing I'd try is lunching Blender from terminal using --factory-startup argument so we can be sure it's not a configuration issue.

Jose Mayi commented

2015-08-12 21:53:55 +02:00

It looks like I had already changed my default layout because when I did a factory startup, it just wouldn't work at all (not even in Default layout)

Jose Mayi commented

2015-08-12 21:57:26 +02:00

I don't know if this may be related to the issue, but on my Windows 10 Desktop, the feature only works if I press shift + F without moving the mouse. If I am moving the mouse while trying to go into fly mode, I will have the same issue as on my mac

Fabio Arnold commented

2015-08-13 16:57:51 +02:00

Added subscriber: @donfabio

cole commented

2015-08-18 17:38:07 +02:00

Added subscriber: @coleberries

cole commented

2015-08-18 17:38:07 +02:00

same problem here, i'm using blender 2.75 (c27589e)
running blender on mac os x 10.9.5
I really need to fix this : /
any help ?

same problem here, i'm using blender 2.75 (c27589e) running blender on mac os x 10.9.5 I really need to fix this : / any help ?

Seth L. commented

2015-08-20 11:35:29 +02:00

Added subscriber: @quantumanomaly

Seth L. commented

2015-08-20 11:35:29 +02:00

I just ran into this too. Mouselook broke in Camera Fly Mode. It was working and then suddenly a setting got corrupted and it stopped. Relaunching Blender didn't fix it. Only doing a "Load Factory Settings" resolved it. In case it helps here are the Preferences I modified today between the time it was working and the time it stopped working:

Input
Walk Speed: 33
Speed Factor: 5

Interface
View Manipulation:
Cursor Depth [ON]
Auto Depth [ON]
Global Pivot [OFF]

I enabled and disabled these in various combinations when trying to get the view to rotate how I wanted, and to get Fly Mode to be fast enough when traversing vast distances. These are the values I settled on, but I tried others in between. Changing only these settings back to the way they were before did not resolve the problem.

Another observation I made in the broken state is that doing a MMB-click while moving the mouse triggers the Teleport function. I wonder if an input conflict occurred when I tried to use MMB to look around (as one would normally in the 3D Viewport) while I was in Fly Mode.

As I'm typing up this bug report I'm troubleshooting and just discovered some new info:

It gets stranger... After encountering this problem first on a MacBook Pro (2015, running Yosemite) I then tried this on an older MacBook Air (2011, running Snow Leopard). The result on the Air was that I managed to get the Fly Mode control configuration screwed up there too, but instead of mouselook breaking this time it was the WASD keys that lost functionality. So on one machine I can move but can't look, and on another I can look, but not move. It's almost comical.

And yet more new info:

Before I tested this on my second machine I backed up my 2.75 folder inside ~/Library/Application Support/Blender/ so after I broke it the second time, I quit Blender, replaced the corrupt 2.75 folder with the backup I had made, relaunched, and now it's working again. Hopefully someone can replicate the bug and do a bit comparison on a corrupt 2.75 folder against a working one and pinpoint the cause.

I just ran into this too. Mouselook broke in Camera Fly Mode. It *was* working and then suddenly a setting got corrupted and it stopped. Relaunching Blender didn't fix it. Only doing a "Load Factory Settings" resolved it. In case it helps here are the Preferences I modified today between the time it was working and the time it stopped working: **Input** Walk Speed: 33 Speed Factor: 5 **Interface** View Manipulation: Cursor Depth [ON] Auto Depth [ON] Global Pivot [OFF] I enabled and disabled these in various combinations when trying to get the view to rotate how I wanted, and to get Fly Mode to be fast enough when traversing vast distances. These are the values I settled on, but I tried others in between. Changing *only* these settings back to the way they were before did not resolve the problem. Another observation I made in the broken state is that doing a MMB-click *while moving the mouse* triggers the Teleport function. I wonder if an input conflict occurred when I tried to use MMB to look around (as one would normally in the 3D Viewport) while I was in Fly Mode. As I'm typing up this bug report I'm troubleshooting and just discovered some new info: It gets stranger... After encountering this problem first on a MacBook Pro (2015, running Yosemite) I then tried this on an older MacBook Air (2011, running Snow Leopard). The result on the Air was that I managed to get the Fly Mode control configuration screwed up there too, but instead of mouselook breaking this time it was the WASD keys that lost functionality. So on one machine I can move but can't look, and on another I can look, but not move. It's almost comical. And yet more new info: **Before I tested this on my second machine I backed up my 2.75 folder inside ~/Library/Application Support/Blender/ so after I broke it the second time, I quit Blender, replaced the corrupt 2.75 folder with the backup I had made, relaunched, and now it's working again. Hopefully someone can replicate the bug and do a bit comparison on a corrupt 2.75 folder against a working one and pinpoint the cause.**

Seth L. commented

2015-08-20 12:16:07 +02:00

Wait wait wait... my conclusion was wrong! Everything I posted above about replacing the settings folder fixing it is a lie!

Not being able to move using the WASD keys... turns out that's unrelated, and not a bug - just I slowed movement to a halt by scrolling down too far, while trying out various things to reproduce the bug. Restarting Blender would have fixed it even if I hadn't replaced the 2.75 folder.

That said, my experience is different from Jose's in that "Load Factory Settings" did fix it... in the default .blend, but not in my .blend. Furthermore I have an older incremental save in which mouselook still works!
Based on that, I now believe it to be a problem that can occur locally in the .blend.

Jose, can you load factory settings again and try flying in the default .blend? If it works there but not in your project .blend we will be able to verify we're experiencing the same symptoms.

**Wait wait wait... my conclusion was wrong! Everything I posted above about replacing the settings folder fixing it is a lie!** Not being able to move using the WASD keys... turns out that's unrelated, and not a bug - just I slowed movement to a halt by scrolling down too far, while trying out various things to reproduce the bug. Restarting Blender would have fixed it even if I hadn't replaced the 2.75 folder. That said, my experience is different from Jose's in that "Load Factory Settings" did fix it... in the default .blend, but not in my .blend. Furthermore I have an older incremental save in which mouselook still works! Based on that, I now believe it to be a problem that can occur locally in the .blend. Jose, can you load factory settings again and try flying in the default .blend? If it works there but not in your project .blend we will be able to verify we're experiencing the same symptoms.

Jose Mayi commented

2015-08-20 14:35:20 +02:00

Hello Seth,

I don't believe we're having the same problem. Mine seems to be more of a layout problem as yours seems to be a corrupted .blend file or setting. I just tried loading factory default in the startup blend file, but the camera would not work until I went into full screen mode by pressing shift + space. My problem doesn't seem to get fixed by reinstalling blender as I have tried that as well in the past. It is weird, however, how if I don't load factory defaults the camera only works with a certain layout configuration, but when I load factory defaults the camera only works when I go into full screen mode on the 3D view.

Hello Seth, I don't believe we're having the same problem. Mine seems to be more of a layout problem as yours seems to be a corrupted .blend file or setting. I just tried loading factory default in the startup blend file, but the camera would not work until I went into full screen mode by pressing shift + space. My problem doesn't seem to get fixed by reinstalling blender as I have tried that as well in the past. It is weird, however, how if I don't load factory defaults the camera only works with a certain layout configuration, but when I load factory defaults the camera only works when I go into full screen mode on the 3D view.

Fabio Arnold commented

2015-08-20 15:24:58 +02:00

I'm on a rMBP with OS X 10.11 Beta 4 using the latest build from repo (f979115) and I also have this issue (no mouse control in fly and walk mode). I tried restoring factory settings to no success. Then I renamed the 2.75 folder in Application Support. Still no use. The only way I can make mouse control work is when entering fullscreen mode (alt+F11). Also during testing in fly mode I managed to loose all input focus with Blender reacting to no input at all. The only way was to open Mission Control and killing Blender. This is not good.

In fullscreen mode I noticed a separate issue: lots of tearing. It seams VSync is disabled in fullscreen mode. There is no tearing in window mode. Also the frame rate seams to be limited to 30 Hz. Weirdly the tearing consistently occurs in the vertical center. This can be made visible by setting the frame rate in the rendering panel to 60 fps and start animation playback (alt+a). In window mode the frame rate is limited to 60 Hz (my screen only supports 60 Hz). May I open another task for this issue?

Then I tested Blender 2.74 and mouse control in window mode works as it supposed to. To me it seams the root cause might be some mouse warping/grabbing issue in window mode introduced in 2.75.

Edit: Forgot to mention: launching blender with --factory-startup also didn't help.

I'm on a rMBP with OS X 10.11 Beta 4 using the latest build from repo (f979115) and I also have this issue (no mouse control in fly and walk mode). I tried restoring factory settings to no success. Then I renamed the 2.75 folder in Application Support. Still no use. The only way I can make mouse control work is when entering fullscreen mode (alt+F11). Also during testing in fly mode I managed to loose all input focus with Blender reacting to no input at all. The only way was to open Mission Control and killing Blender. This is not good. In fullscreen mode I noticed a separate issue: lots of tearing. It seams VSync is disabled in fullscreen mode. There is no tearing in window mode. Also the frame rate seams to be limited to 30 Hz. Weirdly the tearing consistently occurs in the vertical center. This can be made visible by setting the frame rate in the rendering panel to 60 fps and start animation playback (alt+a). In window mode the frame rate is limited to 60 Hz (my screen only supports 60 Hz). May I open another task for this issue? Then I tested Blender 2.74 and mouse control in window mode works as it supposed to. To me it seams the root cause might be some mouse warping/grabbing issue in window mode introduced in 2.75. Edit: Forgot to mention: launching blender with --factory-startup also didn't help.

Seth L. commented

2015-08-21 06:17:13 +02:00

This is a really elusive problem. Each time I thought I knew what was going on, it turned out to seem to be caused by something else. By the end of the day yesterday the .blend I had initially had the problem in was mysteriously working again, but when I would create a new file the problem would occur in the brand new files.

I'll experiment a little more and see if I can find out anything else.

Thanks for the feedback Jose.
Fabio, I'm not sure what you mean about tearing and FPS. Are we talking about the same bug?

This is a really elusive problem. Each time I thought I knew what was going on, it turned out to seem to be caused by something else. By the end of the day yesterday the .blend I had initially had the problem in was mysteriously working again, but when I would create a new file the problem would occur in the brand new files. I'll experiment a little more and see if I can find out anything else. Thanks for the feedback Jose. Fabio, I'm not sure what you mean about tearing and FPS. Are we talking about the same bug?

Fabio Arnold commented

2015-08-21 09:43:54 +02:00

In #45771#329324, @quantumanomaly wrote:
Fabio, I'm not sure what you mean about tearing and FPS. Are we talking about the same bug?

Sorry, no. That part was just an observation related to another issue.

I have yet to find a blend file which is actually working in window mode. Maybe could you attach a working one? Thanks.

> In #45771#329324, @quantumanomaly wrote: > Fabio, I'm not sure what you mean about tearing and FPS. Are we talking about the same bug? Sorry, no. That part was just an observation related to another issue. I have yet to find a blend file which is actually working in window mode. Maybe could you attach a working one? Thanks.

Campbell Barton commented

2015-08-26 09:22:00 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2015-08-26 09:22:00 +02:00

@xDarkProdigy, are you using http:*smoothmouse.com ? - this is known to have problems.*developer note, walk-mode uses mouse warping, even when continuous-grab is disabled.//

Campbell Barton commented

2015-08-26 11:16:44 +02:00

Tested on OSX 10.9.5 (Macbook Pro), and fly mode worked fine - with both a mouse and trackpad.

Jose Mayi commented

2015-08-26 14:59:38 +02:00

In #45771#330426, @ideasman42 wrote:
@xDarkProdigy, are you using http://smoothmouse.com ? - this is known to have problems.

developer note, walk-mode uses mouse warping, even when continuous-grab is disabled.

No. I don't think the problem could be another application because I made sure no startup item is running, just to verify that other programs were not conflicting....and like I said before, this was working prior to 2.75

> In #45771#330426, @ideasman42 wrote: > @xDarkProdigy, are you using http://smoothmouse.com ? - this is known to have problems. > > *developer note, walk-mode uses mouse warping, even when continuous-grab is disabled.* No. I don't think the problem could be another application because I made sure no startup item is running, just to verify that other programs were not conflicting....and like I said before, this was working prior to 2.75

levon hudson commented

2015-09-04 06:53:35 +02:00

Added subscriber: @LevonHudson

levon hudson commented

2015-09-04 06:53:35 +02:00

I was having the same problem using a bit of software called MagicPrefs that adds some functionality to the Mac book pro track pad.

With magicPrefs open, i can use the mouse in Fly mode.
If i close the software i can use the mouse in Fly mode.

strangely though, it only affects 2.75, if i run 2.74, or 2.73 with magicPrefs enabled, the mouse still works in fly mode.

I was having the same problem using a bit of software called MagicPrefs that adds some functionality to the Mac book pro track pad. With magicPrefs open, i can use the mouse in Fly mode. If i close the software i can use the mouse in Fly mode. strangely though, it only affects 2.75, if i run 2.74, or 2.73 with magicPrefs enabled, the mouse still works in fly mode.

Seth L. commented

2015-09-07 19:20:55 +02:00

@donfabio Sorry, but posting a .blend won't help for this one. It seems to be a UI issue. Luckily we have some new info on it, and a lead on a resolution!
See this: http://blender.stackexchange.com/questions/38147/os-x-fly-mode-wont-respond-to-mouse-movements/

Excerpt:
Oh I found the problem! The Menu Bar above the timeline that lists the options "View", "Select", "Add", and "Object" was set too high by default-- the fly mode wasn't reading my mouse movements because they were outside the menu's navigation.

@donfabio Sorry, but posting a .blend won't help for this one. It seems to be a UI issue. Luckily we have some new info on it, and a lead on a resolution! See this: http://blender.stackexchange.com/questions/38147/os-x-fly-mode-wont-respond-to-mouse-movements/ Excerpt: *Oh I found the problem! The Menu Bar above the timeline that lists the options "View", "Select", "Add", and "Object" was set too high by default-- the fly mode wasn't reading my mouse movements because they were outside the menu's navigation.*

Fabio Arnold commented

2015-09-07 20:36:39 +02:00

First I tried rearranging the layout a bit as some of you have suggested and I was indeed lucky for the first time. I got working mouse control in fullscreen with all other editors hidden except for view3d.
I found it weird that it only works in fullscreen mode and I noticed since I have my dock hidden on the left side of my screen the blender window was slightly displaced to the right by a few pixel. Moving the dock to the bottom of my screen I actually got working mouse control in windowed mode with the limitation of not being able to look down.

Then I decided to make a quick investigation using git diff v2.74..HEAD editors/space_view3d/view3d_walk.c to see what's changed since 2.74 (GHOST_SystemCocoa.mm and wm_window.c haven't changed much regarding mouse warping) and a lot of #ifdef USE_TABLET_SUPPORT has been added. So simply putting a #undef USE_TABLET_SUPPORT after #define USE_TABLET_SUPPORT in view3d_walk.c:63 restored old, working 2.74 behavior. So it looks like there's a problem with the tablet support code.

So that's a work around for now...

First I tried rearranging the layout a bit as some of you have suggested and I was indeed lucky for the first time. I got working mouse control in fullscreen with all other editors hidden except for view3d. I found it weird that it only works in fullscreen mode and I noticed since I have my dock hidden on the left side of my screen the blender window was slightly displaced to the right by a few pixel. Moving the dock to the bottom of my screen I actually got working mouse control in windowed mode with the limitation of not being able to look down. Then I decided to make a quick investigation using git diff v2.74..HEAD editors/space_view3d/view3d_walk.c to see what's changed since 2.74 (GHOST_SystemCocoa.mm and wm_window.c haven't changed much regarding mouse warping) and a lot of #ifdef USE_TABLET_SUPPORT has been added. So simply putting a #undef USE_TABLET_SUPPORT after #define USE_TABLET_SUPPORT in view3d_walk.c:63 restored old, working 2.74 behavior. So it looks like there's a problem with the tablet support code. So that's a work around for now...

Campbell Barton commented

2015-09-08 06:26:44 +02:00

Currently we rely on being able to move the cursor to an exact location. Somehow on some OSX systems, the mouse position isn't set exactly as requested.

If its some off-by-one error, we could just not be as strict for OSX, though would like to know whats going on still, since that would be a workaround for an error in GHOST.

The error is likely in WM_cursor_warp or (GHOST_ClientToScreen, GHOST_SetCursorPosition).

@donfabio

Could you try these, running Blender inside a terminal.

Running Blender with the --no-native-pixels argument.
Could you apply this patch P259, and see the cursor coordinates after calling warp?

Currently we rely on being able to move the cursor to an exact location. Somehow on some OSX systems, the mouse position isn't set exactly as requested. If its some off-by-one error, we could just not be as strict for OSX, though would like to know whats going on still, since that would be a workaround for an error in GHOST. ---- The error is likely in `WM_cursor_warp` or (`GHOST_ClientToScreen`, `GHOST_SetCursorPosition`). @donfabio Could you try these, running Blender inside a terminal. - Running Blender with the `--no-native-pixels` argument. - Could you apply this patch [P259](https://archive.blender.org/developer/P259.txt), and see the cursor coordinates after calling warp?

Fabio Arnold commented

2015-09-08 15:02:09 +02:00

Regarding the patch: "FOUND!!!" isn't output but
wanted: (1015, 801)
got: (1014, 800)
is.
So obviously an off by one error.

When running with --no-native-pixels FOUND!!! is output and mouse control is working.

Regarding the patch: "FOUND!!!" isn't output but wanted: (1015, 801) got: (1014, 800) is. So obviously an off by one error. When running with --no-native-pixels FOUND!!! is output and mouse control is working.

Campbell Barton commented

2015-09-08 15:22:11 +02:00

@donfabio, thanks for testing, the problem is with WM_cursor_warp on OSX with retina,
Its rounding down odd numbers.

Will commit a fix shortly.

@donfabio, thanks for testing, the problem is with `WM_cursor_warp` on OSX with retina, Its rounding down odd numbers. Will commit a fix shortly.

Fabio Arnold commented

2015-09-08 15:24:32 +02:00

Awesome, thanks! :D