Page MenuHome

View Navigation: Walk and Fly modes

Authored by Dalai Felinto (dfelinto) on Nov 22 2013, 6:33 AM.



This is an alternative to the dynamic fly mode.
It behaves as the first person navigation system available in most 3d world games nowadays.

You can alternate between the old mode (Fly) and the new mode (Walk) in User Preferences > Inputs


Shift+F - Start View Navigation operator
WASD (hold) - Move forward/backward and straft left/right
QE (hold) - Move up and down (in free mode)
Tab - Alternate between gravity and free walk modes
Shift (hold) - Speed up movement
Alt (hold) - Slow down movement
Space or MMB - Teleport
V - Jump
+/- or mouse wheel - speed increase/decrease

User Preferences Options:

Navigation Mode - fly/walk navigation systems (fly is the old, walk is the new, next options are for walk mode only)
Gravity - alternate between free navigation and walk with gravity modes
Mouse Sensitivity - sensitivity factor to mouse influence to look around
Teleport Duration - how long the teleport lasts
Camera Height - camera height to use in gravity mode
Jump Height - maximum jump speed in m/s
Move Speed - base move speed in m/s
Boost Factor - multiplication factor when running or going slow (1/boost)

Recent Features:

  • Speed is relative to unit_settings.scale_length -
  • Teleport stops at a given distance (camera height) to the hit point
  • Reverse mouse
  • walk->base_speed needs to be static or an operator settings

Development Notes:

  • The initial code was based on view3d_fly.c.
  • The NDoF code was not touched, so it most likely is not working.
  • I removed the axis roll correction


  • Testing/bug fixing (no bugs so far)
  • Try to implement delta mouse offset, Linux has a bug on mouse wrapping

Not addressed:

  • NDoF will not be supported for now
  • We need a nice API to draw in the header while running the operator

Diff Detail

Event Timeline

Glad to see this is coming along. I had just a couple comments on stuff I tried to do but couldn't and on a couple specific notes in the code. Even though I'm not the assigned reviewer I hope this is ok.

I wanted to bind my spacebar to up and ctrl to down, because that's what I'm used to for fly mode in game engines. But if I did that then space bar couldn't be bound to jump for walk mode. This isn't that big of a deal for me because I don't see myself using walk mode a lot, but I just wanted to ask if you're sure you want jump in the code to follow through into teleport all the time and not to up in fly mode.

The other thing I wanted to do was to increase/decrease the move speed on mousewheel up/down, but there wasn't any modal event to increase/decrease speed except for shift and alt. But those are boost/slow and have to be held down. I wonder if it would be possible to add model events such as FPS_MODAL_SPEED_INCREASE and FPS_MODAL_SPEED_DECREASE so that the base move speed could be adjusted while the operator is active.

It seems pretty easy for me to get into weird states in walk mode. If I fly really close to the ground then switch to walk mode it snaps to camera height but the move keys don't work. If before I enter the operator I spin around a couple times in trackball orbit style, then I enter walk mode on top of a plane, when I go forward/back it goes sideways somewhat randomly. Again not very important for me because I don't plan to use walk mode very much, but just wanted to note the problems I found. If I get time I'll look at that code more to see if I can find out why.

Thanks for your work on this feature. By the way, I really like teleport, great idea for moving around a level :)

92 ↗(On Diff #68)

It seems these 5 things (SPEED, PRECISION, and FREELOOK) are defined but not used anywhere I can see. Is this correct? Maybe add comments explaining why?

1319 ↗(On Diff #68)

I think camera_height should be clamped to same values property is clamped too because you can easily get negative values here.


I wonder if there should also be an invert mouse option like all fps usually provide.


It seems this property should also be clamped greater or equal to zero because I could set it to -1 and teleport would fly me backwards to infinity.

The outcome of the first round of review can be found here:

@Anthony Edlin (krash) I will look at those suggestions. Thanks. I'm not sure about the 'invert orientation' (I never use it), but we'll see. Let's get the basic functionality out there first.

Dalai Felinto (dfelinto) updated this revision to Unknown Object (????).Nov 27 2013, 5:15 AM

View Navigation: changes from review


  • rename file and variables from fps to walk
  • unifying walk and fly modes into VIEW3D_OT_navigate
  • change up/down to Q/E keys
  • expose gravity in the ui
  • acceleration/deacceleration
  • new shortcuts (MMB, ...)
  • remove X/Z rolling
  • teleport distance clamp to positive
  • huge cleanup
  • other small changes

Missing parts:

  • walk->base_speed needs to be static or an operator settings
  • Teleport should try to land in an offset to the hit point
  • Speed could/should be relative to unit_settings.scale_length
  • Testing/bug fixing
  • Reverse mouse (I added a placeholder, but no functionality nor UI)

Not addressed:

  • NDoF will not be supported for now
  • We need a nice API to draw in the header while running the operator
Dalai Felinto (dfelinto) updated this revision to Unknown Object (????).Nov 27 2013, 5:20 AM

I forgot to push to my origin/master, this is the new patch, not the previous one

Hi again,

When I'm in walk mode and pressing forward and my pitch is on the horizon I go sideways instead. As I move the mouse farther away from the horizon (either up or down) I start going more in the direction I'm pointing. I have to be in walk mode and on the ground for this to happen. In flying mode it works fine.

Also it won't compile for me, comment inline.



Still no clamp on this camera_height here, so you can easily get negative value, and then you can never get back positive because you are always in falling state.


I have to change this to "short pad[3]" in order to get this diff to compile. Otherwise it errors with a DNA alignment problem.

Dalai Felinto (dfelinto) updated this revision to Unknown Object (????).Nov 27 2013, 1:43 PM

View Navigation: pad alignment for DNA struct

@Anthony Edlin (krash) the previous patch was more for the internal code cleanups, renames, changes, ... than for bug fixing.

I just updated the patch with the pad fix, thanks.

Bugs found so far:

  • Walking side-ways: For the bug you describe, is your camera parented? I noticed some bugs when the camera has a parent, and I'm planning to look at those. But for non-parented cameras it should work. Let me know which one is your case.
  • Aim/Cross: the cross is centered to the window, not the camera finder. So it the camera is not centralized in the view it seems like you are not moving straight (it happens with the original Fly mode too).
  • Locked Movement: If switch from free to gravity modes too close to the ground the camera can't move.

It is for non parented camera. For me, steps to reproduce are.

  1. Open default blender or load factory settings.
  2. Add a plane and scale it up 30x so it's large enough to walk around on.
  3. Enter fly mode with Shift+F and hit TAB to enter walk mode.
  4. You will fall downwards until you hit the ground.
  5. Move around with forwards and backwards keys with pitch or crosshair at the horizon, it moves more sideways (left/right) the closer you are too the horizon.
  6. It switches from right to left sideways movement if you go from slightly below horizon to slightly above horizon.
  7. The farther above or below the horizon you are looking, the less it moves sideways and the more it moves in the direction you're pointing.


Dalai Felinto (dfelinto) updated this revision to Unknown Object (????).Nov 27 2013, 6:56 PM

The only missing reported bug now is the side-walking.

  • View Navigation: fix aim draw not centered
  • View Navigation: Q/E no longer affects camera_height (they now only work on FREE)
  • View Navigation: fix for when camera gets stuck

I found the origin for the 'walk side-ways' problem.
Every time the camera Y rotation is not zero, you get the problem.

But how come we see this with Factory Settings's camera?
Guess what, Blender's initial camera has 0.62 of Y rotation ... lovely ;)

Dalai Felinto (dfelinto) updated this revision to Unknown Object (????).Nov 29 2013, 5:24 PM

More bug fix and code changes:

  • View Navigation: using camera control API
  • View Navigation: bug, not using EARTH_GRAVITY
  • View Navigation: scale the scene movements relative to the scene size
  • View Navigation: fix for sidewalking

The only show-stopper now is the Teleport code update (the offset).
More tests are welcome.

Also in the todo list:

  • walk->base_speed needs to be static or an operator settings
  • reverse mouse (trivial, I may do know for fun)
Dalai Felinto (dfelinto) updated this revision to Unknown Object (????).Nov 29 2013, 10:13 PM

Ironing out remaining issues:

  • View Navigation: offset distance for teleport
  • View Navigation: remove temporary keys
  • View Navigation: Reverse Mouse option

Missing bits:

  • walk->base_speed needs to be static or an operator settings

@Campbell Barton (campbellbarton) - what did you mean by operator settings?

  • Try to use mouse delta. I tried again and I failed to get decent results.

If I can find a way to pass a x,y as center coordinates (ar->winrct.xmin + ar->winx / 2)
and know the exactly result that would give me as event->mval I think I can make it work.
I'll still look at it (though I still like the current solution better)

Dalai Felinto (dfelinto) updated this revision to Unknown Object (????).Nov 30 2013, 3:21 PM

View Navigation: using static variables to store the speed across
@Campbell Barton (campbellbarton) nevermind my previous question. static int work just fine.

Dalai Felinto (dfelinto) updated this revision to Unknown Object (????).Dec 2 2013, 7:34 PM
  • minor edits (float/double use)
  • minor variable renaming and correct flag -> bool conversion.
  • View Navigation: aim/cross doesn't show when there is no camera in the scene
  • View Navigation: separate VIEW3D_OT_walk and VIEW3D_OT_fly operators
  • View Navigation: fix acceleration/deaceleration changes
  • View Navigation: fix - teleport behaves badly when normal is facing
  • View Navigation: cleanups
Dalai Felinto (dfelinto) updated this revision to Unknown Object (????).Dec 2 2013, 7:37 PM
  • View Navigation: using delta mouse movement
Dalai Felinto (dfelinto) updated this revision to Unknown Object (????).Dec 2 2013, 8:36 PM

Final commit

  • View Navigation: cleanups
  • View Navigation: using delta mouse movement

@Campbell Barton (campbellbarton) - I found a 'compromise' between re-centering the mouse everytime or never doing it.
Now it only re-centers every now and then (when mouse (abs)x,y > 0.75 of area)

All good imho, and ready for master.
I'll wait for your final review though.

Just a couple UI things:

  • Rename Reverse Mouse to Invert Mouse or Invert Y Axis - making it consistent with FPS gaming terms.
  • Make Gravity option a toggle switch, like Walk / Fly - this way it's clear that it's a THIS or THAT option.

After using this for a few weeks, I vote for setting the default preference back to "Fly mode".

It feels very weird to me, and my muscle memory is still irritated. :) I also feel like the fly mode is still more useful for the general 3D artist, who is not involved with Game Engine related things.

@Thomas Dinges (dingto) I must disagree. Personally I find this infinitely easier to control than Fly Mode and serves much of the same purpose. I can't even count the number of times I have had students in a class get totally lost because they accidentally enabled fly mode and went zipping off into infinity.

Fly Mode is one of those things that is very useful with lots of practice. Walk Mode can now be used by anyone with relative ease.