Page MenuHome

Mesh: Move selection flags to generic attributes
ClosedPublic

Authored by Hans Goudey (HooglyBoogly) on Aug 27 2022, 6:21 AM.

Details

Summary

Using the attribute name semantics from T97452, this patch moves the
selection status of mesh elements from the SELECT of vertices, and
edges, and the ME_FACE_SEL of faces to generic boolean attribute
Storing this data as generic attributes can significantly simplify and
improve code, as described in T95965.

The attributes are called .selection_vert, .selection_edge, and
.selection_poly. The . prefix means they are "UI attributes",
so they still contain original data edited by users, but they aren't
meant to be accessed procedurally by the user in arbitrary situations.
They are also be hidden in the spreadsheet and the attribute list.

Until 4.0, the attributes are still written to and read from the mesh
in the old way, so neither forward nor backward compatibility are
affected. This means memory requirements will be increased by one byte
per element when selection is used. When the flags are removed
completely, requirements will decrease.

Further notes:

  • The MVert flag is empty at runtime now, so it can be ignored.
  • BMesh is unchanged, otherwise the change would be much larger.
  • Many tests have slightly different results, since the selection attribute uses more generic propagation. Previously you couldn't really rely on edit mode selections being propagated procedurally. Now it mostly works as expected.

Similar to 2480b55f216c
Ref T95965

Branch: refactor-mesh-selection-generic

Diff Detail

Repository
rB Blender

Event Timeline

Hans Goudey (HooglyBoogly) edited the summary of this revision. (Show Details)
  • Cleanups, fixes
Hans Goudey (HooglyBoogly) retitled this revision from Refactor: Move mesh selection flags to generic attributes to Mesh: Move selection flags to generic attributes.Sep 19 2022, 10:20 PM

Only one requested change otherwise LGTM.


The term selection is unnecessarily verbose, the term select communicates intent clearly. As far as I can see ".select_vert", ".select_edge", ".select_poly" are reasonable terms for layers, variable names & related API's.


Other remarks:

  • 'lookup_or_default' is used quite a in situations where there may be no selection, BKE_mesh_legacy_convert_selection_layers_to_flags could skip getting the default if the selection doesn't exist.
  • vgroup_select_verts moves from supporting a NULL hide_verts to accessing default (is there reason to move in this direction? it seems useful to be able to avoid allocating layers that aren't used).
This revision is now accepted and ready to land.Sep 23 2022, 11:36 AM

Thanks for the review.

The term selection is unnecessarily verbose, the term select communicates intent clearly. As far as I can see ".select_vert", ".select_edge", ".select_poly" are reasonable terms for layers, variable names & related API's.

I prefer "selection" since it sounds like a noun instead of a verb, but compromising is fine with me. I'm just happy to move forward here.

  • 'lookup_or_default' is used quite a in situations where there may be no selection, BKE_mesh_legacy_convert_selection_layers_to_flags could skip getting the default if the selection doesn't exist.

lookup_or_default doesn't allocate anything when the layer doesn't exist, it uses the virtual array system to give you something that looks like an array but is only a single value.

  • vgroup_select_verts moves from supporting a NULL hide_verts to accessing default (is there reason to move in this direction? it seems useful to be able to avoid allocating layers that aren't used).

Same as above. Using lookup_or_default instead of the custom data API simplifies code because we don't have to deal with the null checks.