Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-09-27Fix: Assert in legacy mesh conversionHans Goudey
When setting the old face set custom data type, do it in the "layers to write" vector instead of the mesh's poly custom data layers, which weren't "prepared" yet. Otherwise this could make the mesh's custom data typemap invalid.
2022-09-23Mesh: Move selection flags to generic attributesHans Goudey
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 `.select_vert`, `.select_edge`, and `.select_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 Differential Revision: https://developer.blender.org/D15795
2022-09-23Mesh: Move edge crease out of MEdgeHans Goudey
This is very similar to D14077. There are two differences though. First is that vertex creases are already stored in a separate layer, and second is that we can now completely remove use of `Mesh.cd_flag`, since that information is now inherent to whether the layers exist. There are two functional differences here: * Operators are used to add and remove layers instead of a property. * The "crease" attribute can be created and removed by geometry nodes. The second change should make various geometry nodes slightly faster, since the "crease" attribute was always processed before. Creases are now interpolated generically in the CustomData API too, which should help maintain the values across edits better. Meshes get an `edge_creases` RNA property like the existing vertex property, to provide more efficient access to the data in Cycles. One test failure is expected, where different rounding between float the old char storage means that 5 additional points are scattered in a geometry nodes test. Differential Revision: https://developer.blender.org/D15927
2022-09-23Mesh: Move sculpt face sets to a generic attributeHans Goudey
Similar to the other refactors from T95965, this commit moves sculpt face sets to use a generic integer attribute named `".sculpt_face_set"`. This makes face sets accessible in the Python API. The attribute is not visible in the attributes list or the spreadsheet because it is meant for internal use, though that could be an option in the future along with other similar attributes. Currently the change is small, but in the future this could simplify code by allowing use of more generic attribute APIs. Differential Revision: https://developer.blender.org/D16045
2022-09-09Mesh: Move bevel weight out of MVert and MEdgeHans Goudey
As described in T95966, the goal is to move to a "struct of arrays" approach rather than gathering an arbitrary set of data in hard-coded structs. This has performance benefits, but also code complexity benefits (this patch removes plenty of code, though the boilerplate for the new operators outweighs that here). To mirror the internal change, the options for storing mesh bevel weights are converted into operators that add or remove the layer, like for some other layers. The most complex change is to the solidify modifier, where bevel weights had special handling. Other than that, most changes are removing clearing of the weights, boilerplate for the add/remove operators, and removing the manual transfer of bevel weights in bmesh - mesh conversion. Eventually bevel weights can become a fully generic attribute, but for now this patch aims to avoid most functional changes. Bevel weights are still written and read from the mesh in the old way, so neither forward nor backward compatibility are affected. As described in T95965, writing in the old format will be done until 4.0. Differential Revision: https://developer.blender.org/D14077
2022-08-31Mesh: Move material indices to a generic attributeHans Goudey
This patch moves material indices from the mesh `MPoly` struct to a generic integer attribute. The builtin material index was already exposed in geometry nodes, but this makes it a "proper" attribute accessible with Python and visible in the "Attributes" panel. The goals of the refactor are code simplification and memory and performance improvements, mainly because the attribute doesn't have to be stored and processed if there are no materials. However, until 4.0, material indices will still be read and written in the old format, meaning there may be a temporary increase in memory usage. Further notes: * Completely removing the `MPoly.mat_nr` after 4.0 may require changes to DNA or introducing a new `MPoly` type. * Geometry nodes regression tests didn't look at material indices, so the change reveals a bug in the realize instances node that I fixed. * Access to material indices from the RNA `MeshPolygon` type is slower with this patch. The `material_index` attribute can be used instead. * Cycles is changed to read from the attribute instead. * BMesh isn't changed in this patch. Theoretically it could be though, to save 2 bytes per face when less than two materials are used. * Eventually we could use a 16 bit integer attribute type instead. Ref T95967 Differential Revision: https://developer.blender.org/D15675
2022-08-11Mesh: Move hide flags to generic attributesHans Goudey
This commit moves the hide status of mesh vertices, edges, and faces from the `ME_FLAG` to optional generic boolean attributes. Storing this data as generic attributes can significantly simplify and improve code, as described in T95965. The attributes are called `.hide_vert`, `.hide_edge`, and `.hide_poly`, using the attribute name semantics discussed in T97452. 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 by default, 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 the hide status is used. When the flags are removed completely, requirements will decrease when hiding is unused. Further notes: * Some code can be further simplified to skip some processing when the hide attributes don't exist. * The data is still stored in flags for `BMesh`, necessitating some complexity in the conversion to and from `Mesh`. * Access to the "hide" property of mesh elements in RNA is slower. The separate boolean arrays should be used where possible. Ref T95965 Differential Revision: https://developer.blender.org/D14685
2022-07-08Cleanup: Move mesh legacy conversion to a separate fileHans Goudey
It's helpful to make the separation of legacy data formats explicit, because it declutters actively changed code and makes it clear which areas do not follow Blender's current design. In this case I separated the `MFace`/"tessface" conversion code into a separate blenkernel .cc file and header. This also makes refactoring to remove these functions simpler because they're easier to find. In the future, conversions to the `MLoopUV` type and `MVert` can be implemented here for the same reasons (see T95965). Differential Revision: https://developer.blender.org/D15396