Details
- Reviewers
Dalai Felinto (dfelinto) Campbell Barton (campbellbarton) - Maniphest Tasks
- T54643: Multi-Object-Mode: EditMesh Tools
Diff Detail
- Repository
- rB Blender
- Branch
- multi_object_mode_sort_elements (branched from blender2.8)
- Build Status
Buildable 1573 Build 1573: arc lint + arc unit
Event Timeline
Select mode is shared across editmesh, so you can still use CTX_data_edit_object(C); for the first part of the function.
You then can make the loop just to run sort_bmelem_flag(). That also prevents you from running RNA_enum_set inside the for loop, which you shouldn't.
Much better. There is still a required change though in regard to the seed:
Object order isn't deterministic, please follow convention here: rB847f028b715f20aea1021220e18da1183f45c131
Changed the way the seed gets handled in loop over objects, so that it gives a consistent result.
I also moved the BKE_view_layer_array_from_objects_in_edit_mode_unique_data call inside the if statement, so that it is not called every time.
You still need to skip the for loop when mode is not SRT_SELECTED and no relevant element is selected (do it based on elem_items).
| source/blender/editors/mesh/editmesh_tools.c | ||
|---|---|---|
| 5984 | Add a space between for and (. | |
| 6011 | This is bad, in this case it will run only for the active object. | |
@Dalai Felinto (dfelinto) I don't understand why SRT_SELECTED would be an exception.
There is at least one selectmode, and if there is nothing selected for any of the active modes, does sort_bmelem_flag() actually change something under certain circumstances?
It guarantees to keep relative order except for the pair of the last selected element and the first unselected element.
If nothing is selected, or everything is selected, then nothing should happen if I understand correctly.
Even with the reverse option enabled, no change to the indexes seem to occur in 2.79 (buildbot build 4461be1).
Thus, I assume that the following check inside the for-loop would be sufficient:
if (!((elem_types & BM_VERT && bm->totvertsel > 0) ||
(elem_types & BM_EDGE && bm->totedgesel > 0) ||
(elem_types & BM_FACE && bm->totfacesel > 0)))
{
continue;
}Now looping over all objects regardless ofwhether type is set or not. Added check for SRT_SELECTED.
@Fulk33 You lost me. Now the operator does nothing if action/type is one of the following:
- SRT_VIEW_ZAXIS
- SRT_VIEW_XAXIS
- SRT_CURSOR_DISTANCE
- SRT_MATERIAL
- SRT_RANDOMIZE
- SRT_REVERSE
Oh, right. Can I put the if around the if that checks for the selection of any vert/edge/face? Maybe I am not quite understanding how this should work...
See my previous comment https://developer.blender.org/D3330#78857
I don't know what Dalai asked for regarding SRT_SELECTED. I tried different mesh sort types in an older Blender and it's always based on the selection.
Only selected elements will be sorted, the rest remain unchanged. Exception to this is the Selected type, which reorders all selected elements, then the unselected, but keep the relative order, except between both sets.
Example: if a cube has the vertex indices 0, 1, 2, 3 at the bottom and 4, 5, 6, 7 at the top and you select the bottom half and sort selected, then you end up with 4, 5, 6, 7 at the bottom and 0, 1, 2, 3 at the top.
The indexes will be different for all vertices, but the first vertex of the bottom half is still the first etc. Some goes for the top half. Only the order between 3 and 4 is changed to 7 and 0.
However, if everything or nothing is selected, then sorting selected has no effect because there is only one set of elements, for which the relative order must be retained and hence no change of indices can occur.
That's why I believe my suggested check should be inside the for loop regardless of the sort type.
Hey, you were right I was overcomplicating things, sorry about that.
I implemented this operator here rBffb424c85f8e7a1c1c2d1722eda261b007525613.