- Mentioned In
- T50564: Locking view to object not working
T45905: Lock To Cursor in 2.75 uncomfortable working
- Mentioned Here
- D2735: Give setting to bring back the old lock to cursor functionality.
rBc5748f3cc755: View3D: avoid jumping placing cursor /w lock on
rBc6b042be9ef3: Accidentally marked as 'rc'
if we lock on object and move in - we will have change view. but if we lock on cursor - we will have change view only 1st time.
How cursor can be out of view, when we was lock cursor to center of view? this is other error.
We press home in lock mode(set view to ocursor)? in this situation, why do we need this mode? we can press Alt+home in standart mode. we have not difference
How do I make this work the way it did in previous releases? I want the cursor to control the view? If this is not a bug then a working feature was removed? What is the new feature that has made this not work?
This is a change that remove the interest of the feature.
The idea of first behaviour was to change view by just clicking on it. Jumping was expected.
We already have Alt Home to center on Cursor.
So, locking camera to cursor to then press Home key is the same.
I understand view offset interest for locking view on an object but there is none for 3DCursor.
A decent behaviour would be that panning will move 3DCursor for a locked view.
Like Camera is moving when panning is done in a locked camera view.
Unfortunately I'm not using latest version. I'm using one of previous versions. I don't understand why they changed it and don't know how to make it work as before. I am sad about it. :(
I’ve just updated from 2.74 and discovered this change and I too find this incredibly annoying. It was a really good way of easily navigating around my models with a simple mouse click and I don’t understand at all why this function has been removed. I should also point out that there is no ‘HOME” button on Mac’s, we have to press ‘fn+ right arrow’ which makes the work around all the more uncomfortable to use. PLEASE BRING THIS FUNCTION BACK!
Click-Home Click-Home, Click-Home... This change makes usage very difficult. The behavior also seems to be buggy when in Quad View when one of the Views is a camera (clicking centers all views except active one??) . Could you please bring back the 2.73 functionality of the center-on-cursor or make the behavior an option?
For now we have reinstalled 2.73 on all computers in our lab.
For those of you that, like me, HATE this "feature" I have good news (if you're a Windows user)... I am building blender without this garbage and it works like it used to !(^.^)! To be clear, ALL I have done is reverse the change made by "rBc5748f3cc755" to the file "source/blender/editors/space_view3d/view3d_edit.c," then I build as per these instructions.
A zipped, portable build with these changes should be attached just below this line... Superseded, see my next post.
@Mac & Linux users:
I'm really sorry, but I have no way to make builds for you. Try and follow the build instructions for your platform with clean blender source, then just fix the above file. Here is my version of the file you can just copy/paste.
@Campbell Barton & supporters of this BS:
Your change is the very epitome of really bad development decisions, as you are making the user interface a moving target without sufficient justification. Making the cursor the center of the camera's world makes enough sense that every other 3D pipeline does it in some way or another, so why does Blender need to be different? The argument that it "gets lost" is fallacious since you could always 1: lock-to-cursor, 2: alt+home to get it back, 3: Right/left click it to an object under the mouse, and if all else failed, you could delete your user preferences file, and copy your assets to a fresh blend. Why are you preventing a problem that has 4+ fixes already, at the expense of creating other problems that now have NO solution? AT THE VERY LEAST, you should add a checkbox to user preferences for the old functionality, as it is quite apparent several people are very dissatisfied with this change. I'm not trying to be mean here, but this change is just terribly ill-conceived.
As SOON as I figure out how to add a check box to the User Preferences panel I will be making a patch/pull request that lets us toggle back in the old behavior. Figured it out, will make patch when i get around to it.
Edit: Forgot to mention, I think this was built without Cuda rendering, since I have a ATI GPU made out of wood. Let me know if it is, and if you need Cuda, and I may try and make a version with this included.
Ok... Even BETTER news now. And since a picture says it best.....
... and it works perfectly !!!
So, yeah, looks like I might be be making a patch/pull request sooner than I thought.
And for those Windows users that can't wait...
@Charles Scoville (CharlesScoville) please make a Differential with the diff of the code for the proposed patch since this task is closed as it is not a bug but intended behavior.
The patch needs to be reviewed and there is no guarantee that will be merged or merged in time for 2.79.
For some information about contributing code to Blender, please read:
Even though the workflow people used with the old behavior may abuse the original idea of the feature, I'd say we should keep supporting it. Maybe not many people use "Lock to Cursor" at all, but apparently for those who do, this change is crucial. BTW, I don't remember hearing anybody complain about the old behavior.
However, I would be against adding another option for this old behavior (like e.g. D2735 does). I'd suggest to just revert rBc5748f3cc7551 completely.
To avoid jumping we can also use smooth-view, which animates the move towards the new position. That would make it feel much less confusing.41
So, @Campbell Barton (campbellbarton), feel free to chime in, but I'd really suggest reverting the change.
Even though the workflow people used with the old behavior may abuse the original idea of the feature, I'd say we should keep supporting it.
Just because something is not being used the way it was intended, doesn't mean it's not being useful. Just look at duct tape.
BTW, I don't remember hearing anybody complain about the old behavior.
There was one or two individuals (linked around here somewhere) that had some issue with the cursor getting lost, or track pad issues, or whatever, and rBc5748f3cc7551 was supposed to fix it. Though, if you ask me, it does just the opposite since now the cursor is allowed to move around the view even while locked.
If that's a possibility then you can count my vote too.
Blender already has enough settings bloat hell, it doesn't need more. I only made the patch since it didn't seem like anyone was addressing the issue and my way serves both interested parties.
To avoid jumping we can also use smooth-view, which animates the move towards the new position. That would make it feel much less confusing.
That could possibly work [edit: for me]. Firefox does something similar for scrolling with the mouse wheel that makes other browsers look like eye cancer in comparison. My only worry is that it might slow down my workflow if it takes a long time to transition.
With that said, the jumping was never a nuisance to any real people I don't think. It was expected behavior. It's just like scrolling down a web page or file browser. It's so ingrained in you that it's going to move that it usually catches you off guard when it doesn't. It's something your subconscious learns to anticipate after a while, to the point that it can "feel icky" when it's not there.
this change seems to be crucial to some people.
As I said before, the change may have addressed two issues, but it also removed a feature (keeping the cursor centered) that has no alternatives or workarounds and made the UI behavior a moving target. I say "addressed" because it's hard to objectively say the new change "fixed" the issues. The jumping issue wasn't really a problem, more of a quirk, and one would think making the cursor move around by default would have made it even more likely to get it lost.
I'm not mad, BTW, but I am a touch concerned how this was just forced down my throat without a possibility for objection. Specifically it's concerning that, when people did object, they were largely brushed off with the dismissive "not a bug a feature" canned phrasing. Such canned responses, lacking satisfactory explanation, degrade the bug report process IMHO. (Though, reporters making demands instead of opening dialog are equally to blame.)
... but then again maybe I'm partial, since I typically work with the BGE where getting brushed off is a Blender feature too. ;)