Struct of Arrays Refactor for Mesh Polygons #95967

New Issue

Hans Goudey · 2022-02-22T21:05:29+01:00

Hans Goudey commented

2022-02-22 21:05:29 +01:00

Currently, MPoly stores some unnecessary data besides what is necessary:

typedef struct MPoly {
  /** Offset into loop array and number of loops in the face. */
  int loopstart;
  /** Keep signed since we need to subtract when getting the previous loop. */
  int totloop;
  short mat_nr;
  char flag, _pad;
} MPoly;

Data Format

For the reasons described in #95965, this is an inefficient way to organize data.
The first goal is to move the everything besides the face corner start index and the size to separate data layers.
Next, we can use the same offsets storage as curves to transform MPoly into a single integer indicating
the offset of the first corner in the face corner domain. The size of the polygon would be the difference
between that integer offset and the next.

Array<int> poly_offsets

This pattern is abstracted with the OffsetIndices class in Blender. The data would be accessed in two ways:

OffsetIndices<int> Mesh::polys() const;
MutableSpan<int> Mesh::poly_offsets_for_write() const;

Iterating over the corners of a face is quite simple.

for (const int corner : polys[i]) {
  ...
}

The only functional change this requires is that the order of the corners in a mesh is consistent with
the order of the corresponding polygons. Since this is the case in (all?) cases where new meshes are
created, it should be okay to expect this and to version meshes that don't comply.

The final result is that accessing mesh polygons will require a third of the memory that it does now.
Since they are used in hot loops where other data is accessed, that should give a sizeable improvement.

Material Index

This should move to a named integer attribute, with the name material_index.
This means it doesn't have to be processed when there are no material indices,
and meshes with a single material can also be processed more efficiently.

f1c0249f34

Flag

In the flag is:

  ME_SMOOTH = (1 << 0),
  ME_FACE_SEL = (1 << 1),
  /* ME_HIDE = (1 << 4), */

Selection 12becbf0df
This can be moved to a boolean custom data layer. Some way to process it differently than regular attributes will have to be implemented.

ME_SMOOTH
#93551 proposed moving this data completely to the edge domain, but in the end it is simpler to allow it to be on both edges and faces.
The flag value will be moved to a sharp_face attribute.

ME_HIDE 2480b55f21
This can be moved to a separate boolean custom data layer, likely with a reserved name.

Currently, `MPoly` stores some unnecessary data besides what is necessary: ``` typedef struct MPoly { /** Offset into loop array and number of loops in the face. */ int loopstart; /** Keep signed since we need to subtract when getting the previous loop. */ int totloop; short mat_nr; char flag, _pad; } MPoly; ``` ### Data Format For the reasons described in #95965, this is an inefficient way to organize data. The first goal is to move the everything besides the face corner start index and the size to separate data layers. Next, we can use the same offsets storage as curves to transform `MPoly` into a single integer indicating the offset of the first corner in the face corner domain. The size of the polygon would be the difference between that integer offset and the next. `Array<int> poly_offsets` This pattern is abstracted with the `OffsetIndices` class in Blender. The data would be accessed in two ways: ``` OffsetIndices<int> Mesh::polys() const; MutableSpan<int> Mesh::poly_offsets_for_write() const; ``` Iterating over the corners of a face is quite simple. ``` for (const int corner : polys[i]) { ... } ``` The only functional change this requires is that the order of the corners in a mesh is consistent with the order of the corresponding polygons. Since this is the case in (all?) cases where new meshes are created, it should be okay to expect this and to version meshes that don't comply. The final result is that accessing mesh polygons will require a third of the memory that it does now. Since they are used in hot loops where other data is accessed, that should give a sizeable improvement. ### Material Index This should move to a named integer attribute, with the name `material_index`. This means it doesn't have to be processed when there are no material indices, and meshes with a single material can also be processed more efficiently. f1c0249f34 ### Flag In the flag is: ``` ME_SMOOTH = (1 << 0), ME_FACE_SEL = (1 << 1), /* ME_HIDE = (1 << 4), */ ``` **Selection** 12becbf0df This can be moved to a boolean custom data layer. Some way to process it differently than regular attributes will have to be implemented. **ME_SMOOTH** #93551 proposed moving this data completely to the edge domain, but in the end it is simpler to allow it to be on both edges and faces. The flag value will be moved to a `sharp_face` attribute. **ME_HIDE** 2480b55f21 This can be moved to a separate boolean custom data layer, likely with a reserved name.

blender-admin commented

2022-08-11 18:54:24 +02:00

This issue was referenced by 2480b55f21

This issue was referenced by 2480b55f216c31373a84bc5c5d2b0cc158497c44

blender-admin commented

2022-08-31 16:09:01 +02:00

This issue was referenced by f1c0249f34

This issue was referenced by f1c0249f34c4171ec311b5b9882e36fed5889259

blender-admin commented

2022-09-23 16:38:37 +02:00

This issue was referenced by 12becbf0df

This issue was referenced by 12becbf0dffe06b6f28c4cc444fe0312cf9249b9