Lock wiew to cursor not working #45301

Closed
opened 2015-07-04 14:17:38 +02:00 by Alexey · 41 comments

System Information
Operating system and graphics card

Blender Version
Broken: (2.75(c6b042b)only)
Worked: (all other)

Short description of error
1.png

**System Information** Operating system and graphics card **Blender Version** Broken: (2.75(c6b042b)only) Worked: (all other) **Short description of error** ![1.png](https://archive.blender.org/developer/F200370/1.png)
Author

Changed status to: 'Open'

Changed status to: 'Open'
Author

Added subscriber: @Inwader77

Added subscriber: @Inwader77

#45905 was marked as duplicate of this issue

#45905 was marked as duplicate of this issue

#45313 was marked as duplicate of this issue

#45313 was marked as duplicate of this issue

Added subscribers: @ideasman42, @mont29

Added subscribers: @ideasman42, @mont29

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Bastien Montagne self-assigned this 2015-07-04 15:17:17 +02:00

Thanks for the report, but no bug here, this is intended change from @ideasman42, see c5748f3c.

Thanks for the report, but no bug here, this is intended change from @ideasman42, see c5748f3c.
Author

In #45301#319545, @mont29 wrote:
Thanks for the report, but no bug here, this is intended change from @ideasman42, see c5748f3c.

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

> In #45301#319545, @mont29 wrote: > Thanks for the report, but no bug here, this is intended change from @ideasman42, see c5748f3c. 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
Author

In #45301#319545, @mont29 wrote:
Thanks for the report, but no bug here, this is intended change from @ideasman42, see c5748f3c.

P.S. in this new mode we truly can miss cursor

> In #45301#319545, @mont29 wrote: > Thanks for the report, but no bug here, this is intended change from @ideasman42, see c5748f3c. P.S. in this new mode we truly can miss cursor

Added subscriber: @Osgur

Added subscriber: @Osgur

Added subscriber: @anth455

Added subscriber: @anth455

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?

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?

Pressing the home key centers the view over the cursor.

Pressing the home key centers the view over the cursor.

Added subscriber: @rz3x

Added subscriber: @rz3x

Locking to cursor in 2.75 is terribly uncomfortable!! Every click time press HOME is annoying. How can I make this work the way it did in previous releases?

Locking to cursor in 2.75 is terribly uncomfortable!! Every click time press HOME is annoying. How can I make this work the way it did in previous releases?
Member

Added subscriber: @Blendify

Added subscriber: @Blendify

Added subscriber: @zeauro

Added subscriber: @zeauro

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.

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. :(

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. :(

Added subscriber: @Jazzmo67

Added subscriber: @Jazzmo67

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!

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!

Added subscriber: @arountre

Added subscriber: @arountre

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.

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.

Added subscriber: @CharlesScoville

Added subscriber: @CharlesScoville

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 "c5748f3cc7" 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. view3d_edit.c

@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.

Final thoughts.
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.

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 "c5748f3cc7" to the file "source/blender/editors/space_view3d/view3d_edit.c," then I build as per [these instructions.](https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows) ~~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. [view3d_edit.c](https://archive.blender.org/developer/F650349/view3d_edit.c) @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. Final thoughts. ~~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.....
Old Lock to cursor.png

... 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...
Blender 2.78.5 (Old lock to cursor v2).zip

Ok... Even BETTER news now. And since a picture says it best..... ![Old Lock to cursor.png](https://archive.blender.org/developer/F650576/Old_Lock_to_cursor.png) ... 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... [Blender 2.78.5 (Old lock to cursor v2).zip](https://archive.blender.org/developer/F650579/Blender_2.78.5__Old_lock_to_cursor_v2_.zip)

Added subscriber: @VukGardasevic

Added subscriber: @VukGardasevic

@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:
https://wiki.blender.org/index.php/Dev:Doc/Process/Contributing_Code

@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: https://wiki.blender.org/index.php/Dev:Doc/Process/Contributing_Code

@VukGardasevic

It is done. (I just hope I did it right.)

@VukGardasevic It is done. (I just hope I did it right.)
Member

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel
Member

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 c5748f3cc7 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, @ideasman42, 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. 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](https://archive.blender.org/developer/D2735) does). I'd suggest to just revert c5748f3cc7 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, @ideasman42, feel free to chime in, but I'd really suggest reverting the change.
Member

Changed status from 'Archived' to: 'Open'

Changed status from 'Archived' to: 'Open'
Member

Also reopening as design task. Like I said, this change seems to be crucial to some people.

Also reopening as design task. Like I said, this change seems to be crucial to some people.
Bastien Montagne was unassigned by Julian Eisel 2017-07-13 18:30:25 +02:00

@JulianEisel

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.

Agreed.

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 c5748f3cc7 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.

However, I would be against adding another option for this old behavior (like e.g. D2735 does). I'd suggest to just revert c5748f3cc7 completely.

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 notthere.

this change seems to be crucial to some people.

Indeed.

As I said before, the change may have addressed two issues, but it also removed a feature (keepingthe 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. ;)

@JulianEisel > 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. Agreed. 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 c5748f3cc7 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. > However, I would be against adding another option for this old behavior (like e.g. [D2735](https://archive.blender.org/developer/D2735) does). I'd suggest to just revert c5748f3cc7 completely. 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. Indeed. 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. ;)

If we revert back to old behavior, then it may be best to also disable view-panning (when cursor lock is enabled), otherwise you can end up getting the cursor lost quite easily (see #40353).

If users really like old behavior with its problems - we could make it an option too (would prefer over reverting at least).

If we revert back to old behavior, then it may be best to also disable view-panning (when cursor lock is enabled), otherwise you can end up getting the cursor lost quite easily (see #40353). If users really like old behavior with its problems - we could make it an option too (would prefer over reverting at least).

Why disabling view-panning, there is a Center View to Cursor operator (Alt Home) that is working when view is not locked on cursor.
Why it does not work when view is locked ? Why do we need a different Home shortcut when view is locked to do exact same thing ?

Why disabling view-panning, there is a Center View to Cursor operator (Alt Home) that is working when view is not locked on cursor. Why it does not work when view is locked ? Why do we need a different Home shortcut when view is locked to do exact same thing ?

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'

This issue was referenced by e038830650

This issue was referenced by e03883065042412347e7b72a4102532d7b1fc495

Committed optional changed behavior, see: Prefs -> Interface -> Cursor Lock Adjust - disable this option.

@zeauro having to know alt-home shortcut to avoid getting the cursor lost is quite obscure. While it works you need to know to access it.

Not sure about your second question - are you saying the home key should always centers around the cursor when the view is locked?

Committed optional changed behavior, see: *Prefs -> Interface -> Cursor Lock Adjust* - disable this option. @zeauro having to know alt-home shortcut to avoid getting the cursor lost is quite obscure. While it works you need to know to access it. Not sure about your second question - are you saying the home key should always centers around the cursor when the view is locked?

OK, so then does e038830650 invalidate my (questionable quality) patch?

With your patch + the parent commit it looks like you did some (safer) things with version checking, but it is otherwise the same result as what I did. If that's true, I don't see the reason to keep my patch.

OK, so then does e038830650 invalidate my (questionable quality) patch? With your patch + the [parent commit ](https://developer.blender.org/rB2eb2655181b2d90457cb829d0ad285f193ad5e5c) it looks like you did some (safer) things with version checking, but it is otherwise the same result as what I did. If that's true, I don't see the reason to keep my patch.

yes, this change is very similar to your patch.

yes, this change is very similar to your patch.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
13 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#45301
No description provided.