Current Patch State
Entering edit-mode uses all selected mesh objects,
this patch is a test to help plan full featured support (see T54242 design task).
What Works:
General:
- Undo
3D View:
- Edit Mesh:
- drawing.
- select (all, picking, circle, border, lasso).
- select mode vert/edge/face switching.
- handful of tools: subdivide, delete, select(all)
- transform.
- undo.
- Edit Armature;
- drawing.
- select (all, picking, circle, border, lasso).
- handful of tools: subdivide, delete, select(all)
- transform.
- undo.
- Edit Curve/Lattice/Metaball
- transform.
- undo.
- Pose Mode
- drawing.
- select (all, picking, circle, border, lasso).
- some keyframe of tools: insert/remove.
- transform.
- undo.
UV Editing:
- select(all, circle, border, lasso, linked, pick-linked).
- mouse picking (vert/edge/face/island).
- transform.
- uv project & unwrap.
What doesn't work:
- everything not in the list above, but notably...
- Live UV unwrap is limited to single objects (uses static variables internally)
- Vertex/edge slide currently only use the active object to get reference vert/edge when dragging.
Details
- Enter/exit modes without touching workspace->mode was needed, this is currently done using EM_NO_CONTEXT - however we will need this for all modes, so more general solution is needed.
- Handling the case when some objects fail to create edit-mode data is needed (while it's not a common case, it can happen).
- Selecting a vertex/edge/face currently makes that object active too.
We might want to reconsider this, although I think we want a way to change the active object since this is used for the UI (UV layers, groups etc).
- Currently looping over view layer objects everywhere. In most cases I'd prefer to use utility function that allocates an array instead (although it's an extra thing to remember to free).
It has the following advantages:- More expensive checks for duplicate data can be done only once.
- Error checks (such as skipping objects not compatible with the mode or tool in use only need to be done once, and don't need to be repeated in every loop afterwards - with possibility they get out of sync between different functions, causing hard to track down bugs).
- When having single/multi-versions of a function. We can more easily have a single version that constructs an array of one. Then we can creating a fake view-layer (which could backfire later with unintended consequences).
- Currently duplicate object data occurring multiple times in the list isn't checked for (some users will want to disallow that - subdivide tool for eg).
- Syncing vert/edge/face changes to all other object's is quite awkward, I'd like to redo this as a single function which is called on each object.
Observations
- I found adding support for multi-edit while not especially difficult (in most cases) is often awkward design-wise because the level at which you handle all objects depends on the use case, so there is no rule-of-thumb which applies to all tools, sometimes needing to act on different levels within the same tool.
Mostly this can be managed by having *_multi(..) versions of utility functions, but it's still not as clear cut as I'd like.
eg:- select all/none: simply operate on all objects.
- select toggle: needs to check all objects first.
- uv unwrap: operate on all _except_ for packing which needs to group UV's.
- uv project bounds: operator on all, _except_ for clamping to bounds.
- many tools that use notifiers will need to do a loop on all objects at the end to add a notifier to each .. or, we could move notifiers inside utility functions - currently they're mostly in the operators which makes it easier to tell which notifiers are being triggered by am operator (we could have utility function for this: WM_event_add_notifier_objects_in_mode & WM_event_add_notifier_objects_data_in_mode).
Quite a few tools need refactoring to split logic into multiple functions.
Known Bugs
- Select linked in pose mode while mixed with weight paint mode no longer works.
Merging into 2.8
Bare minimum requirements for merging into 2.8
- No existing tools, workflows should be broken (single-object modes must work as expected).
- All basic select tools should support multi-object for all modes: (de)select-all, select-pick.
- Another developer needs to review the general API's and approaches used (@Bastien Montagne (mont29) ?)
Once merged, tasks for all non working features need to be created, One parent task per object-type / mode combination: Edit-mesh, edit-lattice, pose-armature... etc. Each parent task will have many sub-tasks, only grouped when they are closely related (eg: rotate UV's, rotate vertex colors).