Regression: Adjust last action dismissed after rotating view #106292

New Issue

Sahin Ersoz · 2023-03-30T07:25:13+02:00

Sahin Ersoz commented

2023-03-30 07:25:13 +02:00

System Information
Operating system: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 471.11

Blender Version
Broken: version: 3.5.0, branch: blender-v3.5-release, commit date: 2023-03-29 02:56, hash: 1be25cfff18b
Worked: Blender 3.41

Caused by f68e50a263

Short description of error
In Blender 3.5 rotating the view while looking through a camera sets the changes and ends the app (or add-on) you are currently working in (as if the user left clicked in the view port).

It is demonstrated in the video below:
https://youtu.be/p-ZHl3J6l4o

Exact steps for others to reproduce the error

Start Blender
press Numpad 0 to switch to Camera view.
press N, under "View" tab check "Camera To View" button.
Move cube by a bit and expand adjust last action panel at the left bottom corner of the screen.
While the panel is still active, Rotate the view to a different angle by pressing and holding "Middle Mouse Button".

The panel will disappear and the changes will be set.

**System Information** Operating system: Windows-10-10.0.22621-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 471.11 **Blender Version** Broken: version: 3.5.0, branch: blender-v3.5-release, commit date: 2023-03-29 02:56, hash: `1be25cfff18b` Worked: Blender 3.41 Caused by f68e50a263b8a970075c8fd540a985f2798e1d13 **Short description of error** In Blender 3.5 rotating the view while looking through a camera sets the changes and ends the app (or add-on) you are currently working in (as if the user left clicked in the view port). It is demonstrated in the video below: https://youtu.be/p-ZHl3J6l4o **Exact steps for others to reproduce the error** * Start Blender * press Numpad 0 to switch to Camera view. * press N, under "View" tab check "Camera To View" button. * Move cube by a bit and expand adjust last action panel at the left bottom corner of the screen. * While the panel is still active, Rotate the view to a different angle by pressing and holding "Middle Mouse Button". The panel will disappear and the changes will be set.

Sahin Ersoz added the

labels 2023-03-30 07:25:14 +02:00

Richard Antalik changed title from ~~Blender 3.5 Camera View Bug~~ to Regression: Adjust last action dismissed after rotating view

2023-03-30 20:35:26 +02:00

Richard Antalik added

and removed

labels 2023-03-30 20:38:53 +02:00

Richard Antalik commented

2023-03-30 20:39:42 +02:00

Assumed UI module as responsible, but will bisect later to be sure.

Philipp Oeser commented

2023-03-31 15:07:53 +02:00

Caused by f68e50a263

(own undo pushes for navigation were added in befe38fe1d)

So this is actually intended behavior regarding the commit message, but will keep open with high prio to make sure this was really the way envisioned.

CC @ideasman42 : that seems like a pretty "general" approach to a fix only intended for sculpt?

Caused by f68e50a263b8a970075c8fd540a985f2798e1d13 (own undo pushes for navigation were added in befe38fe1dfbbdac9ed9ef61853800426e5966c5) So this is actually intended behavior regarding the commit message, but will keep open with high prio to make sure this was really the way envisioned. CC @ideasman42 : that seems like a pretty "general" approach to a fix only intended for sculpt?

Campbell Barton was assigned by Julian Eisel

2023-04-05 16:29:31 +02:00

Campbell Barton commented

2023-04-06 08:23:19 +02:00

CC @ideasman42 : that seems like a pretty "general" approach to a fix only intended for sculpt?

Yes, intentionally so.
Without this, the redo panel would redo it's self as well as the operator that happened to push it's own undo step.

Checking the old behavior, the panel remained when moving the camera - but adjusting a the redo panel would reset the camera view to the previous state.
It's possible the previous behavior - while technically incorrect, was preferred by users though.

@JulianEisel do you know if artists in the studio leave the camera locked to the view while working?

Attached a patch that re-introduces old behavior, only for viewport operations (I'm not so keen to apply this but I don't see better alternatives besides leaving things as-is).

Details:

This is a logical issue with locking the object to the viewport.

If the camera is locked to the viewport, moving the viewport moves the object, an action which can be undone (it may also auto-keyframe the object).
When undo steps are pushed, the previous action's redo panel closes.

As a thought experiment - we could optionally make the camera not to set undo steps.

No undo pushes when in the camera view.
Undo wouldn't restore the camera, instead the current viewport would always be applied to the camera.

This would make the camera behave as if it is screen data, not tracked by undo-redo but I don't see much advantage gained by this option for the complexity it introduces - just mentioning this for completeness.

> CC @ideasman42 : that seems like a pretty "general" approach to a fix only intended for sculpt? Yes, intentionally so. Without this, the redo panel would redo it's self as well as the operator that happened to push it's own undo step. Checking the old behavior, the panel remained when moving the camera - but adjusting a the redo panel would reset the camera view to the previous state. It's possible the previous behavior - while technically incorrect, was preferred by users though. @JulianEisel do you know if artists in the studio leave the camera locked to the view while working? Attached a patch that re-introduces old behavior, only for viewport operations (I'm not so keen to apply this but I don't see better alternatives besides leaving things as-is). ---- _Details:_ This is a logical issue with locking the object to the viewport. - If the camera is locked to the viewport, moving the viewport moves the object, an action which can be undone (it may also auto-keyframe the object). - When undo steps are pushed, the previous action's redo panel closes. As a thought experiment - we could optionally make the camera not to set undo steps. - No undo pushes when in the camera view. - Undo wouldn't restore the camera, instead the current viewport would always be applied to the camera. This would make the camera behave as if it is screen data, not tracked by undo-redo but I don't see much advantage gained by this option for the complexity it introduces - just mentioning this for completeness.

106292_workaround.diff

6.3 KiB

Sahin Ersoz commented

2023-04-06 10:42:01 +02:00

I am the developer of "Sketch N' Carve", a commercial product with well over a thousand users (4 years of development). It uses Grease Pencil for modeling, and all modeling is done from a custom cameras point of view (user perspective camera is not an option). This new behavior introduced with 3.5 renders my add-on useless.
Let me be clear, camera movements being included in the "Undo" stack is not the problem. The problem is when the camera moves it's ending any open panel/add-on.
If this absolutely needs to be a new feature then at least please make it optional; may be something in the preferences the users can select to turn on or off.

I am the developer of "Sketch N' Carve", a commercial product with well over a thousand users (4 years of development). It uses Grease Pencil for modeling, and **all modeling is done from a custom cameras point of view** (user perspective camera is not an option). This new behavior introduced with 3.5 renders my add-on useless. Let me be clear, camera movements being included in the "Undo" stack is not the problem. The problem is when the camera moves it's ending any open panel/add-on. If this absolutely needs to be a new feature then at least please make it optional; may be something in the preferences the users can select to turn on or off.

Campbell Barton commented

2023-04-06 12:10:00 +02:00

@sse could you expand on why using a camera is needed and a regular viewport doesn't work?

Is this typical grease pencil workflow? Or does your add-on depend on the camera in ways other ways that doesn't apply to typical Blender workflows?

@sse could you expand on why using a camera is needed and a regular viewport doesn't work? Is this typical grease pencil workflow? Or does your add-on depend on the camera in ways other ways that doesn't apply to typical Blender workflows?

Sahin Ersoz commented

2023-04-06 13:43:38 +02:00

Typical Blender workflow has always been that weather you are looking through a camera or the User Perspective, orbiting or panning the view does not close an open panel or end an add-on. My add-on works within these boundaries.

In Grease Pencil mode the canvas is always locked to the view (camera view or user perspective view). The advantage of using a camera is that the view stays locked (therefore the canvas) while using the panel sliders. One can look around but it always snaps back, until the user ends the operation with an intentional left click in the view.
This way the user can continue sketching new shapes without having to worry about loosing the camera angle.
Whereas the "User Perspective" view has no "lock", so as the user orbits the view the canvas follows and the perspective has changed permanently.
Typically I switch between the two frequently. Camera perspective to create the shapes, and the User Perspective to examine the resulting objects.

I hope I am making myself clear.

The link below is one of the tutorial videos (to demonstrate the workflow):
https://youtu.be/Xkhhhg_fbH8

Typical Blender workflow has always been that weather you are looking through a camera or the User Perspective, orbiting or panning the view does not close an open panel or end an add-on. My add-on works within these boundaries. In Grease Pencil mode the canvas is always locked to the view (camera view or user perspective view). The advantage of using a camera is that the view stays locked (therefore the canvas) while using the panel sliders. One can look around but it always snaps back, until the user ends the operation with an intentional left click in the view. This way the user can continue sketching new shapes without having to worry about loosing the camera angle. Whereas the "User Perspective" view has no "lock", so as the user orbits the view the canvas follows and the perspective has changed permanently. Typically I switch between the two frequently. Camera perspective to create the shapes, and the User Perspective to examine the resulting objects. I hope I am making myself clear. The link below is one of the tutorial videos (to demonstrate the workflow): https://youtu.be/Xkhhhg_fbH8

Campbell Barton referenced a pull request that will close this issue

2023-04-21 09:02:15 +02:00

Fix #106292: adjust last action dismissed after rotating view #107210

Brecht Van Lommel commented

2023-04-25 19:28:40 +02:00

The workflow seems quite specific to me, not something that is the correct behavior in general. If you have a grease pencil canvas that is meant to be seen from a specific camera angle, why enable "Camera to View" at all? You're risking accidentally changing the camera angle permanently, and only finding out many steps later.

To me it seems "Camera to View" off is better designed for this purpose. You can freely navigate for editing and then go back to camera view with numpad 0. There is a manual step, but for Blender tools in general I don't think you want to do this automatically. Perhaps for a specific add-on tool, but then maybe that add-on should implement the snapping back itself.

The workflow seems quite specific to me, not something that is the correct behavior in general. If you have a grease pencil canvas that is meant to be seen from a specific camera angle, why enable "Camera to View" at all? You're risking accidentally changing the camera angle permanently, and only finding out many steps later. To me it seems "Camera to View" off is better designed for this purpose. You can freely navigate for editing and then go back to camera view with numpad 0. There is a manual step, but for Blender tools in general I don't think you want to do this automatically. Perhaps for a specific add-on tool, but then maybe that add-on should implement the snapping back itself.

Bastien Montagne commented

2023-05-02 17:54:50 +02:00

I am also not convinced that current behavior needs to be fixed. If view is locked to camera, then changing the view is editing the camera Object, regardless of the fact that this last operation is not editable in the Redo panel.

Trying to roll back the previous fixes in this specific case imho is not only adding an extra layer of complexity to an area of code that is already extremely complex, it's also potentially breaking other workflows. Personally, if I move an object, then move my view, then adjust the object move, and as a result get my view/camera jumping back to the previous view point, I would be very annoyed, and call this a bug.

I am also not convinced that current behavior needs to be fixed. If view is locked to camera, then changing the view _is_ editing the camera Object, regardless of the fact that this last operation is not editable in the Redo panel. Trying to roll back the previous fixes in this specific case imho is not only adding an extra layer of complexity to an area of code that is already extremely complex, it's also potentially breaking other workflows. Personally, if I move an object, then move my view, then adjust the object move, and as a result get my view/camera jumping back to the previous view point, I would be very annoyed, and call this a bug.

Campbell Barton commented

2023-05-04 03:10:35 +02:00

@sse it sounds like your workflow is making up for the inability to lock or save/load non camera views, but as Brecht notes... if your relying on a camera to be able to lock to a particular view, I'm not sure why you would enable "lock camera to view" - where you could easily move the camera by accident.

Note that since this issue was reported the Escape key now works for cancelling viewport navigation, (it was confirming previously) perhaps this helps.

I'd be interested to know how non-camera views can support your workflow, so you can post in https://blender.community/c/rightclickselect/ and link here.

Closing as this is working as intended.

@sse it sounds like your workflow is making up for the inability to lock or save/load non camera views, but as Brecht notes... if your relying on a camera to be able to lock to a particular view, I'm not sure why you would enable "lock camera to view" - where you could easily move the camera by accident. Note that since this issue was reported the Escape key now works for cancelling viewport navigation, (it was confirming previously) perhaps this helps. I'd be interested to know how non-camera views can support your workflow, so you can post in https://blender.community/c/rightclickselect/ and link here. Closing as this is working as intended.

Campbell Barton closed this issue

2023-05-04 03:10:37 +02:00

Blender Bot added

and removed

labels 2023-05-04 03:10:38 +02:00

Sign in to join this conversation.