3D View: Refactor navigation operators #106279

Merged
Germano Cavalcante merged 1 commits from mano-wii/blender:navigation_refactor into main 2023-04-28 14:11:06 +02:00

No functional changes.

Merge the modal callbacks of the VIEW3D_OT_move, VIEW3D_OT_rotate
and VIEW3D_OT_zoom operators into a single simplified
view3d_navigate_modal_fn callback.

Deduplicate code for initialization, also the code for finalization and
the code to get the event_code.

Improve support for operation switching by existing (but unmapped)
modal keymap items VIEWROT_MODAL_SWITCH_ZOOM,
VIEWROT_MODAL_SWITCH_MOVE and VIEWROT_MODAL_SWITCH_ROTATE.


This is a step towards creating a proper generic navigation utility. Or just a proposal to improve the code.

Many navigation operators try to share the same navigation solution.
We can see this by the use of a common customdata, also by the use of the same modal keymap items and the operators having the same properties.

But despite that, these operators have independent algorithms making these matching things meaningless for matching.

Advantages of the new solution:

  • Deduplicate code;

Disadvantages:

  • Not really a disadvantage, but since the algorithms of these operators are no longer inlined, this new solution may bring a small overhead with switch and calls.
No functional changes. Merge the modal callbacks of the `VIEW3D_OT_move`, `VIEW3D_OT_rotate` and `VIEW3D_OT_zoom` operators into a single simplified `view3d_navigate_modal_fn` callback. Deduplicate code for initialization, also the code for finalization and the code to get the `event_code`. Improve support for operation switching by existing (but unmapped) modal keymap items `VIEWROT_MODAL_SWITCH_ZOOM`, `VIEWROT_MODAL_SWITCH_MOVE` and `VIEWROT_MODAL_SWITCH_ROTATE`. --- This is a step towards creating a proper generic navigation utility. Or just a proposal to improve the code. Many navigation operators try to share the same navigation solution. We can see this by the use of a common `customdata`, also by the use of the same modal keymap items and the operators having the same properties. But despite that, these operators have independent algorithms making these matching things meaningless for matching. Advantages of the new solution: - Deduplicate code; Disadvantages: - Not really a disadvantage, but since the algorithms of these operators are no longer inlined, this new solution may bring a small overhead with `switch` and calls.
Germano Cavalcante requested review from Brecht Van Lommel 2023-03-29 21:36:02 +02:00
Germano Cavalcante requested review from Campbell Barton 2023-03-29 21:36:02 +02:00
Germano Cavalcante force-pushed navigation_refactor from 74547485aa to c32cf2bd2a 2023-03-29 21:42:16 +02:00 Compare
Germano Cavalcante force-pushed navigation_refactor from c32cf2bd2a to c4fec9e72a 2023-03-29 21:57:46 +02:00 Compare

Improved support for operation switching

Improved in what way?

Not really a disadvantage, but since the algorithms of these operators are no longer inlined, this new solution may bring a small overhead with switch and calls.

There is no performance concern here at all. This sort of thing is only relevant for a function that is called many times, like for every mesh vertex.

> Improved support for operation switching Improved in what way? > Not really a disadvantage, but since the algorithms of these operators are no longer inlined, this new solution may bring a small overhead with switch and calls. There is no performance concern here at all. This sort of thing is only relevant for a function that is called many times, like for every mesh vertex.
Brecht Van Lommel requested changes 2023-03-30 13:57:01 +02:00
Brecht Van Lommel left a comment
Owner

The overall idea seems reasonable given the planned transform navigation changes. But I haven't worked much on this code so Campbell's opinion on it is more important.

The overall idea seems reasonable given the planned transform navigation changes. But I haven't worked much on this code so Campbell's opinion on it is more important.
@ -46,0 +54,4 @@
static int viewpan_invoke_impl(ViewOpsData *vod, const int pandir);
/* Navigation operators that share the `ViewOpsData` utility. */
const char *op_idnames[] = {

This name is too generic for a global variable. I think it's better to make this a function call with a switch statement so there will be compiler warnings when this goes out of sync with the enum.

This name is too generic for a global variable. I think it's better to make this a function call with a switch statement so there will be compiler warnings when this goes out of sync with the enum.
mano-wii marked this conversation as resolved
@ -60,0 +116,4 @@
r_xy[0] = 2 * r_xy[0] - event->prev_xy[0];
r_xy[1] = 2 * r_xy[1] - event->prev_xy[1];
return VIEW_APPLY;
}

This switch statement feels like it's putting code in a shared function that really belongs to the specific operator.

This switch statement feels like it's putting code in a shared function that really belongs to the specific operator.
mano-wii marked this conversation as resolved
@ -60,0 +120,4 @@
break;
case V3D_VIEW_PAN:
return VIEW_APPLY;
default:

I rather see an explicit list of cases without default, with a comment explaining why they are not handled. That will give a compiler warning to ensure someone checks if it needs to be handled.

I rather see an explicit list of cases without `default`, with a comment explaining why they are not handled. That will give a compiler warning to ensure someone checks if it needs to be handled.
mano-wii marked this conversation as resolved
@ -60,0 +162,4 @@
/* Continuous zoom. */
return VIEW_APPLY;
}
[[fallthrough]];

Not sure you need to have a switch on the navigation type here at all, if zoom is the only one creating a timer this can just be checked for all types.

Not sure you need to have a switch on the navigation type here at all, if zoom is the only one creating a timer this can just be checked for all types.
mano-wii marked this conversation as resolved
@ -60,0 +175,4 @@
return VIEW_CANCEL;
}
break;
default:

It's unclear why V3D_VIEW_PAN is not handled here, can't tell easily tell if it's intentionally part of default or not.

It's unclear why `V3D_VIEW_PAN` is not handled here, can't tell easily tell if it's intentionally part of `default` or not.
mano-wii marked this conversation as resolved
@ -60,0 +207,4 @@
bool use_cursor_init = false;
if (nav_type != V3D_VIEW_PAN) {
use_cursor_init = RNA_boolean_get(ptr, "use_cursor_init");

Can this check if the use_cursor_init property exists rather than nav_type != V3D_VIEW_PAN?

Can this check if the `use_cursor_init` property exists rather than `nav_type != V3D_VIEW_PAN`?
mano-wii marked this conversation as resolved
@ -60,0 +227,4 @@
if (RNA_struct_property_is_set(ptr, "my")) {
xy[1] = RNA_int_get(ptr, "my");
}
}

Can this logic be in viewzoom_invoke_impl, by passing it the ptr? This also seems like code that should be in the specific operator implementation.

Can this logic be in `viewzoom_invoke_impl`, by passing it the `ptr`? This also seems like code that should be in the specific operator implementation.
mano-wii marked this conversation as resolved
@ -35,0 +35,4 @@
extern const char *op_idnames[];
enum eNavType {
V3D_ZOOM = 0,

eNavType and V3D_ prefix are too generic. They both need to include 3D viewport and navigation.

`eNavType` and `V3D_` prefix are too generic. They both need to include 3D viewport and navigation.
mano-wii marked this conversation as resolved
@ -75,2 +96,4 @@
ENUM_OPERATORS(eViewOpsFlag, VIEWOPS_FLAG_USE_MOUSE_INIT);
#ifndef __cplusplus
typedef enum eV3D_OpEvent eV3D_OpEvent;

I think for this type of thing we generally just write this to work in both C and C++:

typedef enum eV3D_OpEvent {
} eV3D_OpEvent;

Rather than using #ifndef __cplusplus.

I think for this type of thing we generally just write this to work in both C and C++: ``` typedef enum eV3D_OpEvent { } eV3D_OpEvent; ``` Rather than using `#ifndef __cplusplus`.
mano-wii marked this conversation as resolved
Author
Member

Applied suggested changes and fixed a bug due ENUM_OPERATORS.

On the suggestion of passing the ptr to the specific implementation of the operator, as some properties with the same name are used in more than one operator, it seemed convenient to use another approach and check all properties with RNA_struct_find_property in the general implementation.

Applied suggested changes and fixed a bug due `ENUM_OPERATORS`. On the suggestion of passing the `ptr` to the specific implementation of the operator, as some properties with the same name are used in more than one operator, it seemed convenient to use another approach and check all properties with `RNA_struct_find_property` in the general implementation.
Brecht Van Lommel requested changes 2023-03-30 16:51:44 +02:00
@ -46,0 +53,4 @@
static void viewops_data_end_navigation(bContext *C, ViewOpsData *vod);
static int viewpan_invoke_impl(ViewOpsData *vod, const int pandir);
const char *op_idname_get(eV3D_OpMode nav_type)

This should be a static function and get a less generic name like viewops_operator_idname_get.

This should be a static function and get a less generic name like `viewops_operator_idname_get`.
brecht marked this conversation as resolved
@ -60,0 +214,4 @@
}
if (prop = RNA_struct_find_property(ptr, "use_all_regions")) {
use_all_regions = RNA_property_boolean_get(ptr, prop);

This is unused.

This is unused.
mano-wii marked this conversation as resolved
@ -60,0 +240,4 @@
return viewzoom_invoke_impl(C, vod, event_code, xy, event->prev_xy, delta);
case V3D_OP_MODE_ROTATE: {
/* MOUSEROTATE performs orbital rotation, so y axis delta is set to 0 */
const bool is_inverted = is_scroll_inverted && (event->type != MOUSEROTATE);

I still think that having code like this in the generic function makes it harder to understand and reason about. This logic is tied to the rotate operator and I don't see a reason for it to be here. Personally I would also still prefer passing a ptr to the specific operators rather than sharing the code for RNA property reading.

I still think that having code like this in the generic function makes it harder to understand and reason about. This logic is tied to the rotate operator and I don't see a reason for it to be here. Personally I would also still prefer passing a `ptr` to the specific operators rather than sharing the code for RNA property reading.
mano-wii marked this conversation as resolved
Brecht Van Lommel approved these changes 2023-03-30 18:07:07 +02:00
Brecht Van Lommel left a comment
Owner

Looks good to me now, still would like Campbell to approve before this lands.

Looks good to me now, still would like Campbell to approve before this lands.
Author
Member

In fact, putting ptr (and event) as parameters simplifies the code. (I complicated it thinking about future changes but it doesn't really seem necessary)

As for making the viewops_operator_idname_get function static, this will require bringing the operator definitions to view3d_navigate.cc file (or a new file). It's not complicated, but it can get in the way of the review.

In fact, putting ptr (and event) as parameters simplifies the code. (I complicated it thinking about future changes but it doesn't really seem necessary) As for making the `viewops_operator_idname_get` function static, this will require bringing the operator definitions to `view3d_navigate.cc` file (or a new file). It's not complicated, but it can get in the way of the review.
Germano Cavalcante force-pushed navigation_refactor from 42ed1d6087 to da0fd22f4b 2023-03-30 18:09:06 +02:00 Compare

As for making the viewops_operator_idname_get function static, this will require bringing the operator definitions to view3d_navigate.cc file (or a new file). It's not complicated, but it can get in the way of the review.

Yes, it's not necessary, I was confused because it's under /* Prototypes. */.

> As for making the `viewops_operator_idname_get` function static, this will require bringing the operator definitions to `view3d_navigate.cc` file (or a new file). It's not complicated, but it can get in the way of the review. Yes, it's not necessary, I was confused because it's under `/* Prototypes. */`.
Germano Cavalcante changed title from 3D View: Refactor navigation operators to WIP: 3D View: Refactor navigation operators 2023-04-21 21:31:03 +02:00
Germano Cavalcante force-pushed navigation_refactor from da0fd22f4b to cc9f011629 2023-04-28 03:23:25 +02:00 Compare
Germano Cavalcante changed title from WIP: 3D View: Refactor navigation operators to 3D View: Refactor navigation operators 2023-04-28 03:24:25 +02:00
Campbell Barton approved these changes 2023-04-28 08:30:59 +02:00
Germano Cavalcante merged commit 67203c0ec8 into main 2023-04-28 14:11:06 +02:00
Germano Cavalcante deleted branch navigation_refactor 2023-04-28 14:11:07 +02:00
Howard Trickey referenced this issue from a commit 2023-05-29 02:51:43 +02:00
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
3 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#106279
No description provided.