I don’t need to make anything for you, SaintHaven… I am happy with 1.0.4 controls, and I specified what it needs. And that wasn’t any extra crazy sh#t you were talking about.
@ SaintHaven: if you say something that’s incorrect you’ll be corrected. It’s that simple. It’s entirely up to you if you want to acknowledge or ignore that, or indeed conflate an issue through misunderstanding, causing greater confusion in the process. That’s OK. But please don’t inculcate others in aspersions directed squarely at you because again, you’re misunderstanding what’s actually being said to you. In other words, when someone calls you out on comments based on ignorance have the humility to at least step back and consider if such comments are properly grounded rather than immediately jumping to the attack and using circular logic as an oppositional argument. It’s tiresome.
@kat, saying someone is ignorant without proving it or making a strong case other than your opinion is NOT correcting someone. If you cannot make a strong argument as to why someone is WRONG then all you are doing is attempting to belittle another because of your OWN opinion. Given that FACT you are incorrect in your assumption and seek to confirm your bias by avoiding giving specifics.
Its “that simple”. So far the usual crud has happened, some poster doesnt like what another says, mocks them and avoids actually proving their stance. Way to dumb down this community.
It’s already been explained several times above, no need for me to waste any more time on it. Thanks nonetheless.
version 0.2.1 - MAC USERS DONT DOWNLOAD !!!
This isn’t a bug with the AddOn but something that happens as a result of the way Blender tends to work with Scene scale. If you work on a scene (level) that uses a large scale value, when initiated camera movement is excruciatingly slow because of the global distances involved. I’m not sure how this can be solved (obviously changing scale values or working at a smaller scale isn’t an ideal solution), but thought it might be worth mentioning.
Easily solved, I upped the default speed to 20 (10 was a bit slow) and extended the speed maximum to 1000, for these real grand scale scenes.
Other than that, the only (minor) issues just relate to the Display Properties (“N”) section having a short delay between de/activation and the checkbox status changing.
Fixed.
Great work so far!
Two suggestions:
- Lock mouse to center of view while in the mode and hide the cursor - this is what is done in WebGL FPS views as well.
- Make space key move up (In fps regular mode it works like jump). So in noclip type mode space usually just moves up in a vertical direction.
Biggest change, I worked for hours on this, cause its quite outside the “standard Python box”, but now mouse is fixed during FPSFly and you can mouselook indefinitely in all directions! In Linux mouse pointer will be hidden. Under Windows the mouse pointer will be centered on view and irritatingly “kindof” follow movement, but I didnt see (and I looked!) a way of hiding it, cause Windows reinstates the cursor to shown on every mouse move… (ideasman42 : will PM you about this).
ALSO THIS VERSION WILL NOT WORK ON MAC. Ill get my old G5 from under the dust and code a Mac solution later.
Ok feedback time.
- Still choppy. When pressing W, it should be a smooth forward movement (similar to Shift F mode) but less “slick”. For me it to incremental. Maybe its working better for others though. I could be wrong, since my coding experience is limited, but my guess is that you are telling the viewport to listen for keypresses, and that if W is pressed, move forward +1 (example) then stop. What would be ideal is for it to keep adding that value non stop (with a limit) as long as W is pressed so its not jittery. Again I could be completely wrong about this so, take that with a grain of salt, or in this case a variable of salt.
- C or X should make it go down where as space bar should make it rise.
- Like others have said, map the center of the viewport to the mouse pointer. This is fine because if the mouse is a high precision mouse, they can adjust the sensitivity there.
- Control + shift + F, or rather the enabling of the fly mode can probably be better. Perhaps something like control + f + right mouse click enables the FPS fly mode (if possible find a way to visually indicate its in fly mode) and then have the viewport only look around when right mouse is pressed. This would allow for the user to take their finger off the right mouse and move the mouse around but still be able to adjust perspective based on the WASDXSpace controls.
-
On Linux, its a bit smoother, but I switched the system from timers to redrawing, so on Windows now also (a bit) better.
-
Its funny to see how this is being discussed, but really Ill just cater for all : now C and X go down, SPACEBAR up + old EQ also works (but I switched them around as I first intended)
-
Solved, as said.
-
It now says “FPS navigation” on top. I think CTRL+SHIFT+F is fine… Also, why would you want to move the mouse in nav mode except for mouselook?
Cool Addon, but where is the rocket launcher?
Will controls be customizable (like any FPS does)? Not only keyboard, but even having mouse buttons custom? Also, it might be cool to have a key for walk/run speed adjust, as well as overall speed could be adjusted with mouse wheel. Anyway, Just some ideas… cool stuff.
Btw, You probably noticed, but this messes with PreSel highlighting, (maybe a solution is to disable presel during this mode since you can’t really edit during fpsfly)?
edit: oops, seems this is only for bge!?! Nevermind…
This is a pacifist addon, sorry… 
Custom controls are next on my list.
Mousewheel now does speed adjust. Watch out, its sensitive!
Allright, have fun!
EDIT : been made to work with PreSel too (download new PreSel for it to work)
@ideasman42 : ah, you dont take PMs, I can see why…
Ill take a look at GitHub to see what it can do for me (dont have experience with using it yet). Were you thinking of contributing to it yourself?
If so, you might know of a way to hide the mouse cursor on Windows from Python (without using external packages) or maybe you can implement a hide_cursor call for the Python API? I might do that myself, would you accept such a patch? (cant be difficult to make)…
EDIT : seems it does the same too in Linux, but narrowed it down to only EditMode,… Does Blender continually refresh mouse cursor on mousemove in EditMode ?
Great work!!! Its running smooth now, and the mouse center works great. I hope this can find its way officially into blender at some point.
One small bug:
If I hold down W for example and move forward, then cancel the fly mode by right clicking, the next time FPflymode is activated, it continues going forward on its own. The input is probably not being dropped upon exiting FPflymode.
Regarding the right mouse button for activation, it would be easier to fire off (toggle on and off) while making adjustments to the assets and continuing back into fly mode. I am also considering this both from the perspective of using a mouse as a primary input device, but also the wacom pent tablets.
Regarding the right mouse being held down for looking around, I find that by consciously looking around with a mouse button helps separate two aspects of this mode of navigation.
> First: The movement from WASDXCspaceQE (whew!) would be independent of where the mouse is pointing. This is useful for moving forward along a set path (directly forward or up at an angle) without worrying about the mouse messing up the direction. By activating the right mouse (holding down) for looking around in conjuction with the movement controls, it allows two modes of operation instead of one. I can stop in one spot, hold down mouse button and look around, unclick and move in incriminates in another direction while keeping the direction I was focused on. Again gives more control to the user.
> Second: Wacom pens. The pens are mapped to screen space. If I hold my pen to the upper left, it jumps to the upper left of the screen, it also senses where the pen is even when its not touching the surface. This can make it a bit more finicky to use. By clicking on one of the side buttons on that pen (usually mapped to right mouse), the user can tell Blender when it wants that input to look around. So if I find a position I like and get the right perspective needed…i might want to preserve that…but moving the pen from the screen even if its to get it away from the input zone will still track that information briefly.
Again, the reason is to give the user more control and to make it tablet friendly. It cant hurt by having this in. To escape FPSfly mode, perhaps escape or the same hotkey to toggle on can be used instead.
(add: when using a wacom pen in general, the viewport freaks out and jumps all over the place, problem solving that may be time consuming due to how its input is different than a regular mouse. Mouse tracks movement, where as wacom pens track position)
version 0.2.2
Fixed the small bug.
So if I understand correctly, you want WASD direction only to change when WASD is used DURING right-mouselook ? Yes?
Many thanks for the bug fix.
Regarding mouse button…No not quite.
Basically everything is normal like it is now… except that the viewport does not track the mouse until its being held down by the right mouse button.
For example, I could press W to move forward, S to move back… and if I move my mouse during that W and S key press, it wont look around. However, the moment I hold down the right mouse button, it enables the mouse look in addition to WASDQEXCspace (whew!).
In short mouse look is tied to right mouse button, when pressed you get mouse look, when not pressed it maintains position and you can move the mouse pointer around. WASD should work regardless of mouse right mouse being pressed or not.
If right mouse press, mouse pointer snaps to center of screen and mouse look enabled. If right mouse not pressed, mouse pointer free to move around, no mouse look enabled.
If WASDQEXCspace (movement forward, back, up down left right…ect)
version 0.3.0
Implemented right mouse look.
But can switch back to always mouselook by unticking “Active/Passive mode” in Addon Preferences.
Great stuff.
Its pretty solid now. Just needs some polish.
The jittery movement is back with this version. Also is there a way to hide the actual mouse pointer in FPfly mode or at least unlock it when its not toggled by the right mouse button?
Add: I was just thinking how great it would be to increase speed with the mouse wheel…and I realized you already did that. Kudos for you!
Notes:
- Might be useful to have the text display on the top of the viewport display the current movement speed. This can be helpful it accidentally gets put into one extreme or the other.
- Mouse speed might need some minor adjustments, but ill have to hold off on that to see if the jitter removal makes it let jumpy.
Bonus Feature?
An added bonus to this mode would be an option to turn on incremental speed. So pressing W starts it off going slow then ramps up to a max speed, nothing too extreme but a slight but subtle difference. This will give the impression of polish and make the movement smooth. Could even have an option to have incremental stops, so when the key is unpressed it slows down until its movement value is 0. It shouldnt be anything that goes past a 1.5-2 seconds.
@paleajed, yep, if there were on github (or a similar service, though suggest go with github), Id submit a pull request with updates - initially just changes which I would consider making it ready for inclusion in Blender, also IIRC some of the code is a bit more complicated then it needs to be.
version 0.3.2 Mac testers needed!
Quick update should remove jitter.
Seems cursor isnt hidden also when on Linux in EditMode.
I added code that should (could) make it work on Mac. Itll be a while before I can test this myself, so anyone there on Mac wanting to give this a try?
Ill start work on a “hide-cursor” patch for Blender C core, cause its really too much hassle (and probably impossible) by using Python alone.
OK Ill postpone hidecursor patch project then, and host this on github.
I am delighted you would consider this for inclusion in Blender.
And yes, especially the code calculating mouselook viewmatrix could probably be done more efficient, and who knows what else…
I just made a repository “paleajed/FPSFly” on GitHub.
Gave read/write access to ideasman42.
Congrats if this gets blender integration.
Note: jitter still present on windows.
@ideasman42 : as part of my new ongoing adventure at browsing/understanding the Blender C source, I managed to get a patch together that adds hiding and showing of the 3D viewport mouse cursor (its on github), I dont know if its common practice to add a field to the wmWindow DNA struct definition for implementing something like this (that wont have much use except for this addon) but it seemed natural since setting of cursor in space_view3d.c is done for a given wmWindow. Maybe there are other ways of approaching this? Anyhow, Im learning!
version 0.4.0
Added keybindings! Click set and press a key/button.
Do test, it was mainly quite the boring chore and I might have made typos…
It’s super fun to play with - though I’ve had trouble getting it to work in windows 7 at all. Works fine for me in Linux.
One bug, the space key to go up should move up on the world coordinates not the camera coordinates. Currently, if you move above your object, look down and press space, you will move forward in relation to the object (camera up). Expected behavior would be to move up along the world coordinates Z-Axis.
version 0.4.1
Im running it on Win7 64 here on different Blender versions, must say its smoother on Linux, whats the matter exactly?
Made up/down move on world Z.