griefith/test2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
1b2f58adffe4784994efed00a1b2affd7210c665
test2/source/blender/blenkernel/intern/mesh_boolean_convert.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

864 lines
34 KiB
C++
Raw Normal View History

File headers: SPDX License migration Use a shorter/simpler license convention, stops the header taking so much space. Follow the SPDX license specification: https://spdx.org/licenses - C/C++/objc/objc++ - Python - Shell Scripts - CMake, GNUmakefile While most of the source tree has been included - `./extern/` was left out. - `./intern/cycles` & `./intern/atomic` are also excluded because they use different header conventions. doc/license/SPDX-license-identifiers.txt has been added to list SPDX all used identifiers. See P2788 for the script that automated these edits. Reviewed By: brecht, mont29, sergey Ref D14069
2022-02-11 09:07:11 +11:00
/* SPDX-License-Identifier: GPL-2.0-or-later
* Copyright 2001-2002 NaN Holding BV. All rights reserved. */
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
/** \file
* \ingroup bke
*/
#include "DNA_mesh_types.h"
#include "DNA_meshdata_types.h"
#include "DNA_object_types.h"
Mesh: Move material indices to a generic attribute 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-31 09:09:01 -05:00
#include "BKE_attribute.hh"
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
#include "BKE_customdata.h"
#include "BKE_material.h"
Mesh: Move functions to C++ header Refactoring mesh code, it has become clear that local cleanups and simplifications are limited by the need to keep a C public API for mesh functions. This change makes code more obvious and makes further refactoring much easier. - Add a new `BKE_mesh.hh` header for a C++ only mesh API - Introduce a new `blender::bke::mesh` namespace, documented here: https://wiki.blender.org/wiki/Source/Objects/Mesh#Namespaces - Move some functions to the new namespace, cleaning up their arguments - Move code to `Array` and `float3` where necessary to use the new API - Define existing inline mesh data access functions to the new header - Keep some C API functions where necessary because of RNA - Move all C++ files to use the new header, which includes the old one In the future it may make sense to split up `BKE_mesh.hh` more, but for now keeping the same name as the existing header keeps things simple. Pull Request: https://projects.blender.org/blender/blender/pulls/105416
2023-03-12 22:29:15 +01:00
#include "BKE_mesh.hh"
Cleanup: Remove unecessary C API for direct mesh boolean The main goal here is to remove the need for a C API to the code in `mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c` to C++ and making the necessary changes for it to compile. On top of that there are some other slight simplifications possible to the direct mesh boolean code: it doesn't need to copy the material remaps, and the modifier code can use some other C++ types directly.
2021-04-02 00:16:01 -05:00
#include "BKE_mesh_boolean_convert.hh"
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
#include "BLI_alloca.h"
Cleanup: Remove unecessary C API for direct mesh boolean The main goal here is to remove the need for a C API to the code in `mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c` to C++ and making the necessary changes for it to compile. On top of that there are some other slight simplifications possible to the direct mesh boolean code: it doesn't need to copy the material remaps, and the modifier code can use some other C++ types directly.
2021-04-02 00:16:01 -05:00
#include "BLI_array.hh"
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
#include "BLI_math.h"
BLI: Use BLI_math_matrix_type.hh instead of BLI_math_float4x4.hh Straightforward port. I took the oportunity to remove some C vector functions (ex: copy_v2_v2). This makes some changes to DRWView to accomodate the alignement requirements of the float4x4 type.
2023-02-06 21:25:45 +01:00
#include "BLI_math_matrix.hh"
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
#include "BLI_mesh_boolean.hh"
#include "BLI_mesh_intersect.hh"
#include "BLI_span.hh"
Various Exact Boolean parallelizations and optimizations. From patch D11780 from Erik Abrahamsson. It parallelizes making the vertices, destruction of map entries, finding if the result is PWN, finding triangle adjacencies, and finding the ambient cell. The latter needs a parallel_reduce from tbb, so added one into BLI_task.hh so that if WITH_TBB is false, the code will still work. On Erik's 6-core machine, the elapsed time went from 17.5s to 11.8s (33% faster) on an intersection of two spheres with 3.1M faces. On Howard's 24-core machine, the elapsed time went from 18.7s to 10.8s for the same test.
2021-07-05 18:09:36 -04:00
#include "BLI_task.hh"
Mesh: Move material indices to a generic attribute 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-31 09:09:01 -05:00
#include "BLI_virtual_array.hh"
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
namespace blender::meshintersect {
#ifdef WITH_GMP
constexpr int estimated_max_facelen = 100; /* Used for initial size of some Vectors. */
/* Snap entries that are near 0 or 1 or -1 to those values.
* Sometimes Blender's rotation matrices for multiples of 90 degrees have
* tiny numbers where there should be zeros. That messes makes some things
* every so slightly non-coplanar when users expect coplanarity,
* so this is a hack to clean up such matrices.
* Would be better to change the transformation code itself.
*/
Cleanup: Reword comment, rename variables Use "transform" instead of "obmat", because the meshes don't necessarily come from objects.
2022-04-27 18:52:56 -05:00
static float4x4 clean_transform(const float4x4 &mat)
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
{
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
float4x4 cleaned;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
const float fuzz = 1e-6f;
for (int i = 0; i < 4; i++) {
for (int j = 0; j < 4; j++) {
BLI: Use BLI_math_matrix_type.hh instead of BLI_math_float4x4.hh Straightforward port. I took the oportunity to remove some C vector functions (ex: copy_v2_v2). This makes some changes to DRWView to accomodate the alignement requirements of the float4x4 type.
2023-02-06 21:25:45 +01:00
float f = mat[i][j];
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
if (fabsf(f) <= fuzz) {
f = 0.0f;
}
else if (fabsf(f - 1.0f) <= fuzz) {
f = 1.0f;
}
else if (fabsf(f + 1.0f) <= fuzz) {
f = -1.0f;
}
BLI: Use BLI_math_matrix_type.hh instead of BLI_math_float4x4.hh Straightforward port. I took the oportunity to remove some C vector functions (ex: copy_v2_v2). This makes some changes to DRWView to accomodate the alignement requirements of the float4x4 type.
2023-02-06 21:25:45 +01:00
cleaned[i][j] = f;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
}
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
return cleaned;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
/* `MeshesToIMeshInfo` keeps track of information used when combining a number
* of `Mesh`es into a single `IMesh` for doing boolean on.
* Mostly this means keeping track of the index offsets for various mesh elements. */
class MeshesToIMeshInfo {
public:
/* The input meshes, */
Span<const Mesh *> meshes;
/* Numbering the vertices of the meshes in order of meshes,
* at what offset does the vertex range for mesh[i] start? */
Array<int> mesh_vert_offset;
/* Similarly for edges of meshes. */
Array<int> mesh_edge_offset;
/* Similarly for polys of meshes. */
Array<int> mesh_poly_offset;
/* For each Mesh vertex in all the meshes (with concatenated indexing),
Cleanup: spelling
2021-02-24 15:53:03 +11:00
* what is the IMesh Vert* allocated for it in the input IMesh? */
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
Array<const Vert *> mesh_to_imesh_vert;
/* Similarly for each Mesh poly. */
Array<Face *> mesh_to_imesh_face;
/* Transformation matrix to transform a coordinate in the corresponding
* Mesh to the local space of the first Mesh. */
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
Array<float4x4> to_target_transform;
Fix T89391, etc. Boolean bugs when objects have negative scale. The old modifier code, now just used for Fast, has code in it to flip faces of arguments when their tranform's negativity differs from the main object's transform's negativity. I had neglected to put that logic in when I made the change that skipped the round trip through BMesh. Fixing this means that the results are more what the user expects when some or all operands have negative scales.
2021-07-25 13:29:45 -04:00
/* For each input mesh, whether or not their transform is negative. */
Array<bool> has_negative_transform;
Fix T86427 Exact solver does not apply target material. I had done some experiments to see what Fast boolean did for material mapping and thought it just used the same slot in the target as the slot in the source. The truth is more complicated: if the target material exists in any slot of the destination, we need to remap to whatever slot has the matching material. I fixed Exact Boolean to do this. Since the materials may be in the object, this means that BKE_mesh_boolean had to get another argument, the remapping arrays. I will note that the current behavior of Fast, and now Exact, is not ideal. Ideally, if the source material does not exist in the target, a new material slot should be created in the target and the source material copied there (and incrementing the material's reference count). Maybe a future project, but for now, I want the behavior of Exact to match that of Fast.
2021-03-14 11:39:56 -04:00
/* For each input mesh, how to remap the material slot numbers to
* the material slots in the first mesh. */
Cleanup: Remove unecessary C API for direct mesh boolean The main goal here is to remove the need for a C API to the code in `mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c` to C++ and making the necessary changes for it to compile. On top of that there are some other slight simplifications possible to the direct mesh boolean code: it doesn't need to copy the material remaps, and the modifier code can use some other C++ types directly.
2021-04-02 00:16:01 -05:00
Span<Array<short>> material_remaps;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
/* Total number of input mesh vertices. */
int tot_meshes_verts;
/* Total number of input mesh edges. */
int tot_meshes_edges;
/* Total number of input mesh polys. */
int tot_meshes_polys;
int input_mesh_for_imesh_vert(int imesh_v) const;
int input_mesh_for_imesh_edge(int imesh_e) const;
int input_mesh_for_imesh_face(int imesh_f) const;
const MPoly *input_mpoly_for_orig_index(int orig_index,
const Mesh **r_orig_mesh,
int *r_orig_mesh_index,
int *r_index_in_orig_mesh) const;
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
void input_mvert_for_orig_index(int orig_index,
const Mesh **r_orig_mesh,
int *r_index_in_orig_mesh) const;
Mesh: Move edge UV seams to a generic attribute As part of #95966, move the `ME_SEAM` flag on mesh edges to a generic boolean attribute, called `.uv_seam`. This is the last bit of extra information stored in mesh edges. After this is committed we can switch to a different type for them and have a 1/3 improvement in memory consumption. It is also now possible to see that a mesh has no UV seams in constant time, and like other similar refactors, interacting with only the UV seams can be done with less memory. The attribute name starts with a `.` to signify that the attribute, like face sets, isn't meant to be used in arbitrary procedural situations (with geometry nodes for example). That gives us more freedom to change things in the future. Pull Request #104728
2023-03-01 14:13:05 +01:00
void input_medge_for_orig_index(int orig_index,
const Mesh **r_orig_mesh,
int *r_index_in_orig_mesh) const;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
};
/* Given an index `imesh_v` in the `IMesh`, return the index of the
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
* input `Mesh` that contained the vertex that it came from. */
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
int MeshesToIMeshInfo::input_mesh_for_imesh_vert(int imesh_v) const
{
Cleanup: replace static_casts with functional casts for numeric types
2022-09-25 18:30:50 +10:00
int n = int(mesh_vert_offset.size());
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
for (int i = 0; i < n - 1; ++i) {
if (imesh_v < mesh_vert_offset[i + 1]) {
return i;
}
}
return n - 1;
}
/* Given an index `imesh_e` used as an original index in the `IMesh`,
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
* return the index of the input `Mesh` that contained the vertex that it came from. */
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
int MeshesToIMeshInfo::input_mesh_for_imesh_edge(int imesh_e) const
{
Cleanup: replace static_casts with functional casts for numeric types
2022-09-25 18:30:50 +10:00
int n = int(mesh_edge_offset.size());
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
for (int i = 0; i < n - 1; ++i) {
if (imesh_e < mesh_edge_offset[i + 1]) {
return i;
}
}
return n - 1;
}
/* Given an index `imesh_f` in the `IMesh`, return the index of the
* input `Mesh` that contained the `MPoly` that it came from. */
int MeshesToIMeshInfo::input_mesh_for_imesh_face(int imesh_f) const
{
Cleanup: replace static_casts with functional casts for numeric types
2022-09-25 18:30:50 +10:00
int n = int(mesh_poly_offset.size());
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
for (int i = 0; i < n - 1; ++i) {
if (imesh_f < mesh_poly_offset[i + 1]) {
return i;
}
}
return n - 1;
}
/* Given an index of an original face in the `IMesh`, find out the input
* `Mesh` that it came from and return it in `*r_orig_mesh`,
* and also return the index of that `Mesh` in `*r_orig_mesh_index`.
* Finally, return the index of the corresponding `MPoly` in that `Mesh`
* in `*r_index_in_orig_mesh`. */
const MPoly *MeshesToIMeshInfo::input_mpoly_for_orig_index(int orig_index,
const Mesh **r_orig_mesh,
int *r_orig_mesh_index,
int *r_index_in_orig_mesh) const
{
int orig_mesh_index = input_mesh_for_imesh_face(orig_index);
BLI_assert(0 <= orig_mesh_index && orig_mesh_index < meshes.size());
const Mesh *me = meshes[orig_mesh_index];
Cleanup: Tweak naming for recently added mesh accessors Use `verts` instead of `vertices` and `polys` instead of `polygons` in the API added in 05952aa94d33eeb50. This aligns better with existing naming where the shorter names are much more common.
2022-09-07 00:06:31 -05:00
const Span<MPoly> polys = me->polys();
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
int index_in_mesh = orig_index - mesh_poly_offset[orig_mesh_index];
BLI_assert(0 <= index_in_mesh && index_in_mesh < me->totpoly);
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
const MPoly *poly = &polys[index_in_mesh];
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
if (r_orig_mesh) {
*r_orig_mesh = me;
}
if (r_orig_mesh_index) {
*r_orig_mesh_index = orig_mesh_index;
}
if (r_index_in_orig_mesh) {
*r_index_in_orig_mesh = index_in_mesh;
}
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
return poly;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
/* Given an index of an original vertex in the `IMesh`, find out the input
* `Mesh` that it came from and return it in `*r_orig_mesh`.
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
* Also find the index of the vertex in that `Mesh` and return it in
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
* `*r_index_in_orig_mesh`. */
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
void MeshesToIMeshInfo::input_mvert_for_orig_index(int orig_index,
const Mesh **r_orig_mesh,
int *r_index_in_orig_mesh) const
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
{
int orig_mesh_index = input_mesh_for_imesh_vert(orig_index);
BLI_assert(0 <= orig_mesh_index && orig_mesh_index < meshes.size());
const Mesh *me = meshes[orig_mesh_index];
int index_in_mesh = orig_index - mesh_vert_offset[orig_mesh_index];
BLI_assert(0 <= index_in_mesh && index_in_mesh < me->totvert);
if (r_orig_mesh) {
*r_orig_mesh = me;
}
if (r_index_in_orig_mesh) {
*r_index_in_orig_mesh = index_in_mesh;
}
}
/* Similarly for edges. */
Mesh: Move edge UV seams to a generic attribute As part of #95966, move the `ME_SEAM` flag on mesh edges to a generic boolean attribute, called `.uv_seam`. This is the last bit of extra information stored in mesh edges. After this is committed we can switch to a different type for them and have a 1/3 improvement in memory consumption. It is also now possible to see that a mesh has no UV seams in constant time, and like other similar refactors, interacting with only the UV seams can be done with less memory. The attribute name starts with a `.` to signify that the attribute, like face sets, isn't meant to be used in arbitrary procedural situations (with geometry nodes for example). That gives us more freedom to change things in the future. Pull Request #104728
2023-03-01 14:13:05 +01:00
void MeshesToIMeshInfo::input_medge_for_orig_index(int orig_index,
const Mesh **r_orig_mesh,
int *r_index_in_orig_mesh) const
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
{
int orig_mesh_index = input_mesh_for_imesh_edge(orig_index);
BLI_assert(0 <= orig_mesh_index && orig_mesh_index < meshes.size());
const Mesh *me = meshes[orig_mesh_index];
int index_in_mesh = orig_index - mesh_edge_offset[orig_mesh_index];
BLI_assert(0 <= index_in_mesh && index_in_mesh < me->totedge);
if (r_orig_mesh) {
*r_orig_mesh = me;
}
if (r_index_in_orig_mesh) {
*r_index_in_orig_mesh = index_in_mesh;
}
}
Cleanup: use our own code style for doxy-gen comment blocks
2021-04-09 18:47:10 +10:00
/**
* Convert all of the meshes in `meshes` to an `IMesh` and return that.
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
* All of the coordinates are transformed into the local space of the
* first Mesh. To do this transformation, we also need the transformation
* obmats corresponding to the Meshes, so they are in the `obmats` argument.
* The 'original' indexes in the IMesh are the indexes you get by
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
* a scheme that offsets each vertex, MEdge, and MPoly index by the sum of the
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
* vertices, edges, and polys in the preceding Meshes in the mesh span.
* The `*r_info class` is filled in with information needed to make the
* correspondence between the Mesh MVerts/MPolys and the IMesh Verts/Faces.
* All allocation of memory for the IMesh comes from `arena`.
*/
static IMesh meshes_to_imesh(Span<const Mesh *> meshes,
Cleanup: Use span and float matrix type in direct boolean code This commit includes a few simple improvements to the direct mesh boolean code added recently. - Passing the transforms and meshes to `direct_mesh_boolean` as spans makes the function easier to call from C++. - The definition of `TransMat`, was unecessary when we have the `float4x4` type already used elsewhere in C++ code. Differential Revision: https://developer.blender.org/D10592
2021-03-02 20:58:05 -06:00
Span<const float4x4 *> obmats,
Cleanup: Remove unecessary C API for direct mesh boolean The main goal here is to remove the need for a C API to the code in `mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c` to C++ and making the necessary changes for it to compile. On top of that there are some other slight simplifications possible to the direct mesh boolean code: it doesn't need to copy the material remaps, and the modifier code can use some other C++ types directly.
2021-04-02 00:16:01 -05:00
Span<Array<short>> material_remaps,
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
const float4x4 &target_transform,
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
IMeshArena &arena,
MeshesToIMeshInfo *r_info)
{
int nmeshes = meshes.size();
BLI_assert(nmeshes > 0);
r_info->meshes = meshes;
r_info->tot_meshes_verts = 0;
r_info->tot_meshes_polys = 0;
int &totvert = r_info->tot_meshes_verts;
int &totedge = r_info->tot_meshes_edges;
int &totpoly = r_info->tot_meshes_polys;
for (const Mesh *me : meshes) {
totvert += me->totvert;
totedge += me->totedge;
totpoly += me->totpoly;
}
/* Estimate the number of vertices and faces in the boolean output,
* so that the memory arena can reserve some space. It is OK if these
* estimates are wrong. */
const int estimate_num_outv = 3 * totvert;
const int estimate_num_outf = 4 * totpoly;
arena.reserve(estimate_num_outv, estimate_num_outf);
Cleanup: Reword comment, rename variables Use "transform" instead of "obmat", because the meshes don't necessarily come from objects.
2022-04-27 18:52:56 -05:00
r_info->mesh_to_imesh_vert.reinitialize(totvert);
r_info->mesh_to_imesh_face.reinitialize(totpoly);
r_info->mesh_vert_offset.reinitialize(nmeshes);
r_info->mesh_edge_offset.reinitialize(nmeshes);
r_info->mesh_poly_offset.reinitialize(nmeshes);
r_info->to_target_transform.reinitialize(nmeshes);
r_info->has_negative_transform.reinitialize(nmeshes);
Cleanup: Remove unecessary C API for direct mesh boolean The main goal here is to remove the need for a C API to the code in `mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c` to C++ and making the necessary changes for it to compile. On top of that there are some other slight simplifications possible to the direct mesh boolean code: it doesn't need to copy the material remaps, and the modifier code can use some other C++ types directly.
2021-04-02 00:16:01 -05:00
r_info->material_remaps = material_remaps;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
int v = 0;
int e = 0;
int f = 0;
/* Put these Vectors here, with a size unlikely to need resizing,
* so that the loop to make new Faces will likely not need to allocate
* over and over. */
Vector<const Vert *, estimated_max_facelen> face_vert;
Vector<int, estimated_max_facelen> face_edge_orig;
Cleanup: Reword comment, rename variables Use "transform" instead of "obmat", because the meshes don't necessarily come from objects.
2022-04-27 18:52:56 -05:00
/* To convert the coordinates of meshes 1, 2, etc. into the local space
* of the target, multiply each transform by the inverse of the
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
* target matrix. Exact Boolean works better if these matrices are 'cleaned'
Cleanup: Reword comment, rename variables Use "transform" instead of "obmat", because the meshes don't necessarily come from objects.
2022-04-27 18:52:56 -05:00
* -- see the comment for the `clean_transform` function, above. */
BLI: Use BLI_math_matrix_type.hh instead of BLI_math_float4x4.hh Straightforward port. I took the oportunity to remove some C vector functions (ex: copy_v2_v2). This makes some changes to DRWView to accomodate the alignement requirements of the float4x4 type.
2023-02-06 21:25:45 +01:00
const float4x4 inv_target_mat = math::invert(clean_transform(target_transform));
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
/* For each input `Mesh`, make `Vert`s and `Face`s for the corresponding
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
* vertices and `MPoly`s, and keep track of the original indices (using the
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
* concatenating offset scheme) inside the `Vert`s and `Face`s.
* When making `Face`s, we also put in the original indices for `MEdge`s that
* make up the `MPoly`s using the same scheme. */
for (int mi : meshes.index_range()) {
const Mesh *me = meshes[mi];
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
r_info->mesh_vert_offset[mi] = v;
r_info->mesh_edge_offset[mi] = e;
r_info->mesh_poly_offset[mi] = f;
Cleanup: Reword comment, rename variables Use "transform" instead of "obmat", because the meshes don't necessarily come from objects.
2022-04-27 18:52:56 -05:00
/* Get matrix that transforms a coordinate in meshes[mi]'s local space
Cleanup: Remove repeated word in comments
2022-02-23 18:24:08 +11:00
* to the target space. */
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
const float4x4 objn_mat = (obmats[mi] == nullptr) ? float4x4::identity() :
Cleanup: Reword comment, rename variables Use "transform" instead of "obmat", because the meshes don't necessarily come from objects.
2022-04-27 18:52:56 -05:00
clean_transform(*obmats[mi]);
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
r_info->to_target_transform[mi] = inv_target_mat * objn_mat;
BLI: Use BLI_math_matrix_type.hh instead of BLI_math_float4x4.hh Straightforward port. I took the oportunity to remove some C vector functions (ex: copy_v2_v2). This makes some changes to DRWView to accomodate the alignement requirements of the float4x4 type.
2023-02-06 21:25:45 +01:00
r_info->has_negative_transform[mi] = math::is_negative(objn_mat);
Fix T89391, etc. Boolean bugs when objects have negative scale. The old modifier code, now just used for Fast, has code in it to flip faces of arguments when their tranform's negativity differs from the main object's transform's negativity. I had neglected to put that logic in when I made the change that skipped the round trip through BMesh. Fixing this means that the results are more what the user expects when some or all operands have negative scales.
2021-07-25 13:29:45 -04:00
/* All meshes 1 and up will be transformed into the local space of operand 0.
* Historical behavior of the modifier has been to flip the faces of any meshes
* that would have a negative transform if you do that. */
bool need_face_flip = r_info->has_negative_transform[mi] != r_info->has_negative_transform[0];
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
Various Exact Boolean parallelizations and optimizations. From patch D11780 from Erik Abrahamsson. It parallelizes making the vertices, destruction of map entries, finding if the result is PWN, finding triangle adjacencies, and finding the ambient cell. The latter needs a parallel_reduce from tbb, so added one into BLI_task.hh so that if WITH_TBB is false, the code will still work. On Erik's 6-core machine, the elapsed time went from 17.5s to 11.8s (33% faster) on an intersection of two spheres with 3.1M faces. On Howard's 24-core machine, the elapsed time went from 18.7s to 10.8s for the same test.
2021-07-05 18:09:36 -04:00
Vector<Vert *> verts(me->totvert);
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
const Span<float3> vert_positions = me->vert_positions();
Cleanup: Tweak naming for recently added mesh accessors Use `verts` instead of `vertices` and `polys` instead of `polygons` in the API added in 05952aa94d33eeb50. This aligns better with existing naming where the shorter names are much more common.
2022-09-07 00:06:31 -05:00
const Span<MPoly> polys = me->polys();
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
const Span<MLoop> loops = me->loops();
Various Exact Boolean parallelizations and optimizations. From patch D11780 from Erik Abrahamsson. It parallelizes making the vertices, destruction of map entries, finding if the result is PWN, finding triangle adjacencies, and finding the ambient cell. The latter needs a parallel_reduce from tbb, so added one into BLI_task.hh so that if WITH_TBB is false, the code will still work. On Erik's 6-core machine, the elapsed time went from 17.5s to 11.8s (33% faster) on an intersection of two spheres with 3.1M faces. On Howard's 24-core machine, the elapsed time went from 18.7s to 10.8s for the same test.
2021-07-05 18:09:36 -04:00
/* Allocate verts
* Skip the matrix multiplication for each point when there is no transform for a mesh,
* for example when the first mesh is already in the target space. (Note the logic
* directly above, which uses an identity matrix with a null input transform). */
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
if (obmats[mi] == nullptr) {
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
threading::parallel_for(vert_positions.index_range(), 2048, [&](IndexRange range) {
Various Exact Boolean parallelizations and optimizations. From patch D11780 from Erik Abrahamsson. It parallelizes making the vertices, destruction of map entries, finding if the result is PWN, finding triangle adjacencies, and finding the ambient cell. The latter needs a parallel_reduce from tbb, so added one into BLI_task.hh so that if WITH_TBB is false, the code will still work. On Erik's 6-core machine, the elapsed time went from 17.5s to 11.8s (33% faster) on an intersection of two spheres with 3.1M faces. On Howard's 24-core machine, the elapsed time went from 18.7s to 10.8s for the same test.
2021-07-05 18:09:36 -04:00
for (int i : range) {
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
float3 co = vert_positions[i];
Various Exact Boolean parallelizations and optimizations. From patch D11780 from Erik Abrahamsson. It parallelizes making the vertices, destruction of map entries, finding if the result is PWN, finding triangle adjacencies, and finding the ambient cell. The latter needs a parallel_reduce from tbb, so added one into BLI_task.hh so that if WITH_TBB is false, the code will still work. On Erik's 6-core machine, the elapsed time went from 17.5s to 11.8s (33% faster) on an intersection of two spheres with 3.1M faces. On Howard's 24-core machine, the elapsed time went from 18.7s to 10.8s for the same test.
2021-07-05 18:09:36 -04:00
mpq3 mco = mpq3(co.x, co.y, co.z);
double3 dco(mco[0].get_d(), mco[1].get_d(), mco[2].get_d());
verts[i] = new Vert(mco, dco, NO_INDEX, i);
}
});
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
else {
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
threading::parallel_for(vert_positions.index_range(), 2048, [&](IndexRange range) {
Various Exact Boolean parallelizations and optimizations. From patch D11780 from Erik Abrahamsson. It parallelizes making the vertices, destruction of map entries, finding if the result is PWN, finding triangle adjacencies, and finding the ambient cell. The latter needs a parallel_reduce from tbb, so added one into BLI_task.hh so that if WITH_TBB is false, the code will still work. On Erik's 6-core machine, the elapsed time went from 17.5s to 11.8s (33% faster) on an intersection of two spheres with 3.1M faces. On Howard's 24-core machine, the elapsed time went from 18.7s to 10.8s for the same test.
2021-07-05 18:09:36 -04:00
for (int i : range) {
BLI: Use BLI_math_matrix_type.hh instead of BLI_math_float4x4.hh Straightforward port. I took the oportunity to remove some C vector functions (ex: copy_v2_v2). This makes some changes to DRWView to accomodate the alignement requirements of the float4x4 type.
2023-02-06 21:25:45 +01:00
float3 co = math::transform_point(r_info->to_target_transform[mi], vert_positions[i]);
Various Exact Boolean parallelizations and optimizations. From patch D11780 from Erik Abrahamsson. It parallelizes making the vertices, destruction of map entries, finding if the result is PWN, finding triangle adjacencies, and finding the ambient cell. The latter needs a parallel_reduce from tbb, so added one into BLI_task.hh so that if WITH_TBB is false, the code will still work. On Erik's 6-core machine, the elapsed time went from 17.5s to 11.8s (33% faster) on an intersection of two spheres with 3.1M faces. On Howard's 24-core machine, the elapsed time went from 18.7s to 10.8s for the same test.
2021-07-05 18:09:36 -04:00
mpq3 mco = mpq3(co.x, co.y, co.z);
double3 dco(mco[0].get_d(), mco[1].get_d(), mco[2].get_d());
verts[i] = new Vert(mco, dco, NO_INDEX, i);
}
});
}
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
for (int i : vert_positions.index_range()) {
Various Exact Boolean parallelizations and optimizations. From patch D11780 from Erik Abrahamsson. It parallelizes making the vertices, destruction of map entries, finding if the result is PWN, finding triangle adjacencies, and finding the ambient cell. The latter needs a parallel_reduce from tbb, so added one into BLI_task.hh so that if WITH_TBB is false, the code will still work. On Erik's 6-core machine, the elapsed time went from 17.5s to 11.8s (33% faster) on an intersection of two spheres with 3.1M faces. On Howard's 24-core machine, the elapsed time went from 18.7s to 10.8s for the same test.
2021-07-05 18:09:36 -04:00
r_info->mesh_to_imesh_vert[v] = arena.add_or_find_vert(verts[i]);
++v;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
for (const MPoly &poly : polys) {
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
int flen = poly.totloop;
Fix T89391, etc. Boolean bugs when objects have negative scale. The old modifier code, now just used for Fast, has code in it to flip faces of arguments when their tranform's negativity differs from the main object's transform's negativity. I had neglected to put that logic in when I made the change that skipped the round trip through BMesh. Fixing this means that the results are more what the user expects when some or all operands have negative scales.
2021-07-25 13:29:45 -04:00
face_vert.resize(flen);
face_edge_orig.resize(flen);
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
const MLoop *l = &loops[poly.loopstart];
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
for (int i = 0; i < flen; ++i) {
int mverti = r_info->mesh_vert_offset[mi] + l->v;
const Vert *fv = r_info->mesh_to_imesh_vert[mverti];
Fix T89391, etc. Boolean bugs when objects have negative scale. The old modifier code, now just used for Fast, has code in it to flip faces of arguments when their tranform's negativity differs from the main object's transform's negativity. I had neglected to put that logic in when I made the change that skipped the round trip through BMesh. Fixing this means that the results are more what the user expects when some or all operands have negative scales.
2021-07-25 13:29:45 -04:00
if (need_face_flip) {
face_vert[flen - i - 1] = fv;
int iedge = i < flen - 1 ? flen - i - 2 : flen - 1;
face_edge_orig[iedge] = e + l->e;
}
else {
face_vert[i] = fv;
face_edge_orig[i] = e + l->e;
}
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
++l;
}
r_info->mesh_to_imesh_face[f] = arena.add_face(face_vert, f, face_edge_orig);
++f;
}
e += me->totedge;
}
return IMesh(r_info->mesh_to_imesh_face);
}
/* Copy vertex attributes, including customdata, from `orig_mv` to `mv`.
* `mv` is in `dest_mesh` with index `mv_index`.
* The `orig_mv` vertex came from Mesh `orig_me` and had index `index_in_orig_me` there. */
static void copy_vert_attributes(Mesh *dest_mesh,
const Mesh *orig_me,
int mv_index,
int index_in_orig_me)
{
/* For all layers in the orig mesh, copy the layer information. */
CustomData *target_cd = &dest_mesh->vdata;
const CustomData *source_cd = &orig_me->vdata;
for (int source_layer_i = 0; source_layer_i < source_cd->totlayer; ++source_layer_i) {
int ty = source_cd->layers[source_layer_i].type;
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
if (StringRef(source_cd->layers->name) == "position") {
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
continue;
}
const char *name = source_cd->layers[source_layer_i].name;
int target_layer_i = CustomData_get_named_layer_index(target_cd, ty, name);
/* Not all layers were merged in target: some are marked CD_FLAG_NOCOPY
* and some are not in the CD_MASK_MESH.vdata. */
if (target_layer_i != -1) {
CustomData_copy_data_layer(
source_cd, target_cd, source_layer_i, target_layer_i, index_in_orig_me, mv_index, 1);
}
}
}
/* Similar to copy_vert_attributes but for poly attributes. */
static void copy_poly_attributes(Mesh *dest_mesh,
const Mesh *orig_me,
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
int poly_index,
Fix T86427 Exact solver does not apply target material. I had done some experiments to see what Fast boolean did for material mapping and thought it just used the same slot in the target as the slot in the source. The truth is more complicated: if the target material exists in any slot of the destination, we need to remap to whatever slot has the matching material. I fixed Exact Boolean to do this. Since the materials may be in the object, this means that BKE_mesh_boolean had to get another argument, the remapping arrays. I will note that the current behavior of Fast, and now Exact, is not ideal. Ideally, if the source material does not exist in the target, a new material slot should be created in the target and the source material copied there (and incrementing the material's reference count). Maybe a future project, but for now, I want the behavior of Exact to match that of Fast.
2021-03-14 11:39:56 -04:00
int index_in_orig_me,
Mesh: Move material indices to a generic attribute 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-31 09:09:01 -05:00
Span<short> material_remap,
MutableSpan<int> dst_material_indices)
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
{
CustomData *target_cd = &dest_mesh->pdata;
const CustomData *source_cd = &orig_me->pdata;
for (int source_layer_i = 0; source_layer_i < source_cd->totlayer; ++source_layer_i) {
int ty = source_cd->layers[source_layer_i].type;
if (ty == CD_MPOLY) {
continue;
}
const char *name = source_cd->layers[source_layer_i].name;
int target_layer_i = CustomData_get_named_layer_index(target_cd, ty, name);
if (target_layer_i != -1) {
CustomData_copy_data_layer(
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
source_cd, target_cd, source_layer_i, target_layer_i, index_in_orig_me, poly_index, 1);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
}
Fix T102522: Geometry nodes boolean doesent respect material index The refactor in f1c0249f34c417 incorrectly placed the material index remapping before the transfer of generic attributes. Now that the material index is a generic attribute, it was overwritten.
2022-11-21 15:49:18 -06:00
/* Fix material indices after they have been transferred as a generic attribute. */
const VArray<int> src_material_indices = orig_me->attributes().lookup_or_default<int>(
"material_index", ATTR_DOMAIN_FACE, 0);
const int src_index = src_material_indices[index_in_orig_me];
Fix T99592: Exact Boolean: Skip empty materials, add index-based option **Empty Slot Fix** Currently the boolean modifier transfers the default material from meshes with no materials and empty material slots to the faces on the base mesh. I added this in a2d59b2dac9e for the sake of consistency, but the behavior is actually not useful at all. The default empty material isn't chosen by users, it just signifies "nothing," so when it replaces a material chosen by users, it feels like a bug. This commit corrects that behavior by only transferring materials from non-empty material slots. The implementation is now consistent between exact mode of the boolean modifier and the geometry node. **Index-Based Option** "Index-based" is the new default material method for the boolean modifier, to access the old behavior from before the breaking commit. a2d59b2dac9e actually broke some Boolean workflows fundamentally, since it was important to set up matching slot indices on each operand. That isn't the cleanest workflow, and it breaks when materials change procedurally, but historically that hasn't been a problem. The "transfer" behavior transfers all materials except for empty slots, but the fundamental problem is that there isn't a good way to specify the result materials besides using the slot indices. Even then, the transfer option is a bit more intuitive and useful for some simpler situations, and it allows accessing the behavior that has been in 3.2 and 3.3 for a long time, so it's also left in as an option. The geometry node doesn't get this new option, in the hope that we'll find a better solution in the future. Differential Revision: https://developer.blender.org/D16187
2022-11-28 12:42:08 -06:00
if (material_remap.index_range().contains(src_index)) {
const int remapped_index = material_remap[src_index];
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
dst_material_indices[poly_index] = remapped_index >= 0 ? remapped_index : src_index;
Fix T102522: Geometry nodes boolean doesent respect material index The refactor in f1c0249f34c417 incorrectly placed the material index remapping before the transfer of generic attributes. Now that the material index is a generic attribute, it was overwritten.
2022-11-21 15:49:18 -06:00
}
else {
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
dst_material_indices[poly_index] = src_index;
Fix T102522: Geometry nodes boolean doesent respect material index The refactor in f1c0249f34c417 incorrectly placed the material index remapping before the transfer of generic attributes. Now that the material index is a generic attribute, it was overwritten.
2022-11-21 15:49:18 -06:00
}
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
BLI_assert(dst_material_indices[poly_index] >= 0);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
/* Similar to copy_vert_attributes but for edge attributes. */
static void copy_edge_attributes(Mesh *dest_mesh,
const Mesh *orig_me,
int medge_index,
int index_in_orig_me)
{
CustomData *target_cd = &dest_mesh->edata;
const CustomData *source_cd = &orig_me->edata;
for (int source_layer_i = 0; source_layer_i < source_cd->totlayer; ++source_layer_i) {
int ty = source_cd->layers[source_layer_i].type;
if (ty == CD_MEDGE) {
continue;
}
const char *name = source_cd->layers[source_layer_i].name;
int target_layer_i = CustomData_get_named_layer_index(target_cd, ty, name);
if (target_layer_i != -1) {
CustomData_copy_data_layer(
source_cd, target_cd, source_layer_i, target_layer_i, index_in_orig_me, medge_index, 1);
}
}
}
Cleanup: spelling
2021-02-25 16:34:27 +11:00
/**
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
* For #IMesh face `f`, with corresponding output Mesh poly `poly`,
* where the original Mesh poly is `orig_poly`, coming from the Mesh
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
* `orig_me`, which has index `orig_me_index` in `mim`:
* fill in the `orig_loops` Array with corresponding indices of MLoops from `orig_me`
* where they have the same start and end vertices; for cases where that is
* not true, put -1 in the `orig_loops` slot.
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
* For now, we only try to do this if `poly` and `orig_poly` have the same size.
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
* Return the number of non-null MLoops filled in.
*/
static int fill_orig_loops(const Face *f,
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
const MPoly *orig_poly,
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
const Mesh *orig_me,
int orig_me_index,
MeshesToIMeshInfo &mim,
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
MutableSpan<int> r_orig_loops)
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
{
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
r_orig_loops.fill(-1);
const Span<MLoop> orig_loops = orig_me->loops();
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
int orig_mplen = orig_poly->totloop;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
if (f->size() != orig_mplen) {
return 0;
}
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
BLI_assert(r_orig_loops.size() == orig_mplen);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
/* We'll look for the case where the first vertex in f has an original vertex
* that is the same as one in orig_me (after correcting for offset in mim meshes).
* Then see that loop and any subsequent ones have the same start and end vertex.
* This may miss some cases of partial alignment, but that's OK since discovering
Cleanup: spelling
2021-02-25 16:34:27 +11:00
* aligned loops is only an optimization to avoid some re-interpolation.
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
*/
int first_orig_v = f->vert[0]->orig;
if (first_orig_v == NO_INDEX) {
return 0;
}
/* It is possible that the original vert was merged with another in another mesh. */
if (orig_me_index != mim.input_mesh_for_imesh_vert(first_orig_v)) {
return 0;
}
int orig_me_vert_offset = mim.mesh_vert_offset[orig_me_index];
int first_orig_v_in_orig_me = first_orig_v - orig_me_vert_offset;
BLI_assert(0 <= first_orig_v_in_orig_me && first_orig_v_in_orig_me < orig_me->totvert);
/* Assume all vertices in an mpoly are unique. */
int offset = -1;
for (int i = 0; i < orig_mplen; ++i) {
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
int loop_i = i + orig_poly->loopstart;
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
if (orig_loops[loop_i].v == first_orig_v_in_orig_me) {
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
offset = i;
break;
}
}
if (offset == -1) {
return 0;
}
int num_orig_loops_found = 0;
for (int mp_loop_index = 0; mp_loop_index < orig_mplen; ++mp_loop_index) {
int orig_mp_loop_index = (mp_loop_index + offset) % orig_mplen;
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
const MLoop *l = &orig_loops[orig_poly->loopstart + orig_mp_loop_index];
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
int fv_orig = f->vert[mp_loop_index]->orig;
if (fv_orig != NO_INDEX) {
fv_orig -= orig_me_vert_offset;
if (fv_orig < 0 || fv_orig >= orig_me->totvert) {
fv_orig = NO_INDEX;
}
}
if (l->v == fv_orig) {
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
const MLoop *lnext =
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
&orig_loops[orig_poly->loopstart + ((orig_mp_loop_index + 1) % orig_mplen)];
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
int fvnext_orig = f->vert[(mp_loop_index + 1) % orig_mplen]->orig;
if (fvnext_orig != NO_INDEX) {
fvnext_orig -= orig_me_vert_offset;
if (fvnext_orig < 0 || fvnext_orig >= orig_me->totvert) {
fvnext_orig = NO_INDEX;
}
}
if (lnext->v == fvnext_orig) {
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
r_orig_loops[mp_loop_index] = orig_poly->loopstart + orig_mp_loop_index;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
++num_orig_loops_found;
}
}
}
return num_orig_loops_found;
}
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
/* Fill `cos_2d` with the 2d coordinates found by projection MPoly `poly` along
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
* its normal. Also fill in r_axis_mat with the matrix that does that projection.
* But before projecting, also transform the 3d coordinate by multiplying by trans_mat.
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
* `cos_2d` should have room for `poly->totloop` entries. */
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
static void get_poly2d_cos(const Mesh *me,
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
const MPoly *poly,
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
float (*cos_2d)[2],
Cleanup: Use span and float matrix type in direct boolean code This commit includes a few simple improvements to the direct mesh boolean code added recently. - Passing the transforms and meshes to `direct_mesh_boolean` as spans makes the function easier to call from C++. - The definition of `TransMat`, was unecessary when we have the `float4x4` type already used elsewhere in C++ code. Differential Revision: https://developer.blender.org/D10592
2021-03-02 20:58:05 -06:00
const float4x4 &trans_mat,
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
float r_axis_mat[3][3])
{
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
const Span<float3> positions = me->vert_positions();
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
const Span<MLoop> loops = me->loops();
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
const Span<MLoop> poly_loops = loops.slice(poly->loopstart, poly->totloop);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
/* Project coordinates to 2d in cos_2d, using normal as projection axis. */
Mesh: Move functions to C++ header Refactoring mesh code, it has become clear that local cleanups and simplifications are limited by the need to keep a C public API for mesh functions. This change makes code more obvious and makes further refactoring much easier. - Add a new `BKE_mesh.hh` header for a C++ only mesh API - Introduce a new `blender::bke::mesh` namespace, documented here: https://wiki.blender.org/wiki/Source/Objects/Mesh#Namespaces - Move some functions to the new namespace, cleaning up their arguments - Move code to `Array` and `float3` where necessary to use the new API - Define existing inline mesh data access functions to the new header - Keep some C API functions where necessary because of RNA - Move all C++ files to use the new header, which includes the old one In the future it may make sense to split up `BKE_mesh.hh` more, but for now keeping the same name as the existing header keeps things simple. Pull Request: https://projects.blender.org/blender/blender/pulls/105416
2023-03-12 22:29:15 +01:00
const float3 axis_dominant = bke::mesh::poly_normal_calc(positions, poly_loops);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
axis_dominant_v3_to_m3(r_axis_mat, axis_dominant);
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
for (const int i : poly_loops.index_range()) {
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
float3 co = positions[poly_loops[i].v];
BLI: Use BLI_math_matrix_type.hh instead of BLI_math_float4x4.hh Straightforward port. I took the oportunity to remove some C vector functions (ex: copy_v2_v2). This makes some changes to DRWView to accomodate the alignement requirements of the float4x4 type.
2023-02-06 21:25:45 +01:00
co = math::transform_point(trans_mat, co);
*reinterpret_cast<float2 *>(&cos_2d[i]) = (float3x3(r_axis_mat) * co).xy();
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
}
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
/* For the loops of `poly`, see if the face is unchanged from `orig_poly`, and if so,
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
* copy the Loop attributes from corresponding loops to corresponding loops.
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
* Otherwise, interpolate the Loop attributes in the face `orig_poly`. */
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
static void copy_or_interp_loop_attributes(Mesh *dest_mesh,
const Face *f,
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
MPoly *poly,
const MPoly *orig_poly,
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
const Mesh *orig_me,
int orig_me_index,
MeshesToIMeshInfo &mim)
{
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
Array<int> orig_loops(poly->totloop);
int norig = fill_orig_loops(f, orig_poly, orig_me, orig_me_index, mim, orig_loops);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
/* We may need these arrays if we have to interpolate Loop attributes rather than just copy.
* Right now, trying Array<float[2]> complains, so declare cos_2d a different way. */
float(*cos_2d)[2];
Array<float> weights;
Array<const void *> src_blocks_ofs;
float axis_mat[3][3];
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
if (norig != poly->totloop) {
/* We will need to interpolate. Make `cos_2d` hold 2d-projected coordinates of `orig_poly`,
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
* which are transformed into object 0's local space before projecting.
* At this point we cannot yet calculate the interpolation weights, as they depend on
* the coordinate where interpolation is to happen, but we can allocate the needed arrays,
* so they don't have to be allocated per-layer. */
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
cos_2d = (float(*)[2])BLI_array_alloca(cos_2d, orig_poly->totloop);
weights = Array<float>(orig_poly->totloop);
src_blocks_ofs = Array<const void *>(orig_poly->totloop);
get_poly2d_cos(orig_me, orig_poly, cos_2d, mim.to_target_transform[orig_me_index], axis_mat);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
CustomData *target_cd = &dest_mesh->ldata;
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
const Span<float3> dst_positions = dest_mesh->vert_positions();
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
const Span<MLoop> dst_loops = dest_mesh->loops();
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
for (int i = 0; i < poly->totloop; ++i) {
int loop_index = poly->loopstart + i;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
int orig_loop_index = norig > 0 ? orig_loops[i] : -1;
const CustomData *source_cd = &orig_me->ldata;
if (orig_loop_index == -1) {
/* Will need interpolation weights for this loop's vertex's coordinates.
* The coordinate needs to be projected into 2d, just like the interpolating polygon's
* coordinates were. The `dest_mesh` coordinates are already in object 0 local space. */
float co[2];
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
mul_v2_m3v3(co, axis_mat, dst_positions[dst_loops[loop_index].v]);
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
interp_weights_poly_v2(weights.data(), cos_2d, orig_poly->totloop, co);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
for (int source_layer_i = 0; source_layer_i < source_cd->totlayer; ++source_layer_i) {
int ty = source_cd->layers[source_layer_i].type;
if (ty == CD_MLOOP) {
continue;
}
const char *name = source_cd->layers[source_layer_i].name;
int target_layer_i = CustomData_get_named_layer_index(target_cd, ty, name);
if (target_layer_i == -1) {
continue;
}
if (orig_loop_index != -1) {
CustomData_copy_data_layer(
source_cd, target_cd, source_layer_i, target_layer_i, orig_loop_index, loop_index, 1);
}
else {
Cleanup: consistent use of tags: NOTE/TODO/FIXME/XXX Also use doxy style function reference `#` prefix chars when referencing identifiers.
2021-07-03 23:08:40 +10:00
/* NOTE: although CustomData_bmesh_interp_n function has bmesh in its name, nothing about
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
* it is BMesh-specific. We can't use CustomData_interp because it assumes that
* all source layers exist in the dest.
* A non bmesh version could have the benefit of not copying data into src_blocks_ofs -
* using the contiguous data instead. TODO: add to the custom data API. */
int target_layer_type_index = CustomData_get_named_layer(target_cd, ty, name);
Fix T86308 Crash in Exact Boolean when have custom normal layer. Custom Normal layers can't be interpolated, so needed a check for non-interpolatable layers before trying to interpolate.
2021-03-06 09:05:55 -05:00
if (!CustomData_layer_has_interp(source_cd, source_layer_i)) {
continue;
}
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
int source_layer_type_index = source_layer_i - source_cd->typemap[ty];
BLI_assert(target_layer_type_index != -1 && source_layer_type_index >= 0);
Refactor: Const correct Custom Data API, prepare for CoW Currently you can retrieve a mutable array from a const CustomData. That makes code unsafe since the compiler can't check for correctness itself. Fix that by introducing a separate function to retrieve mutable arrays from CustomData. The new functions have the `_for_write` suffix that make the code's intention clearer. Because it makes retrieving write access an explicit step, this change also makes proper copy-on-write possible for attributes. Notes: - The previous "duplicate referenced layer" functions are redundant with retrieving layers with write access - The custom data functions that give a specific index only have `for_write` to simplify the API Differential Revision: https://developer.blender.org/D14140
2023-01-13 17:21:20 -06:00
const int size = CustomData_sizeof(ty);
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
for (int j = 0; j < orig_poly->totloop; ++j) {
Refactor: Const correct Custom Data API, prepare for CoW Currently you can retrieve a mutable array from a const CustomData. That makes code unsafe since the compiler can't check for correctness itself. Fix that by introducing a separate function to retrieve mutable arrays from CustomData. The new functions have the `_for_write` suffix that make the code's intention clearer. Because it makes retrieving write access an explicit step, this change also makes proper copy-on-write possible for attributes. Notes: - The previous "duplicate referenced layer" functions are redundant with retrieving layers with write access - The custom data functions that give a specific index only have `for_write` to simplify the API Differential Revision: https://developer.blender.org/D14140
2023-01-13 17:21:20 -06:00
const void *layer = CustomData_get_layer_n(source_cd, ty, source_layer_type_index);
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
src_blocks_ofs[j] = POINTER_OFFSET(layer, size * (orig_poly->loopstart + j));
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
Refactor: Const correct Custom Data API, prepare for CoW Currently you can retrieve a mutable array from a const CustomData. That makes code unsafe since the compiler can't check for correctness itself. Fix that by introducing a separate function to retrieve mutable arrays from CustomData. The new functions have the `_for_write` suffix that make the code's intention clearer. Because it makes retrieving write access an explicit step, this change also makes proper copy-on-write possible for attributes. Notes: - The previous "duplicate referenced layer" functions are redundant with retrieving layers with write access - The custom data functions that give a specific index only have `for_write` to simplify the API Differential Revision: https://developer.blender.org/D14140
2023-01-13 17:21:20 -06:00
void *dst_layer = CustomData_get_layer_n_for_write(
target_cd, ty, target_layer_type_index, dest_mesh->totloop);
void *dst_block_ofs = POINTER_OFFSET(dst_layer, size * loop_index);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
CustomData_bmesh_interp_n(target_cd,
src_blocks_ofs.data(),
weights.data(),
nullptr,
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
orig_poly->totloop,
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
dst_block_ofs,
target_layer_i);
}
}
}
}
Cleanup: use our own code style for doxy-gen comment blocks
2021-04-09 18:47:10 +10:00
/**
* Make sure that there are custom data layers in the target mesh
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
* corresponding to all target layers in all of the operands after the first.
* (The target should already have layers for those in the first operand mesh).
* Edges done separately -- will have to be done later, after edges are made.
*/
static void merge_vertex_loop_poly_customdata_layers(Mesh *target, MeshesToIMeshInfo &mim)
{
for (int mesh_index = 1; mesh_index < mim.meshes.size(); ++mesh_index) {
const Mesh *me = mim.meshes[mesh_index];
if (me->totvert) {
CustomData_merge(
Attributes: Improve custom data initialization options When allocating new `CustomData` layers, often we do redundant initialization of arrays. For example, it's common that values are allocated, set to their default value, and then set to some other value. This is wasteful, and it negates the benefits of optimizations to the allocator like D15082. There are two reasons for this. The first is array-of-structs storage that makes it annoying to initialize values manually, and the second is confusing options in the Custom Data API. This patch addresses the latter. The `CustomData` "alloc type" options are rearranged. Now, besides the options that use existing layers, there are two remaining: * `CD_SET_DEFAULT` sets the default value. * Usually zeroes, but for colors this is white (how it was before). * Should be used when you add the layer but don't set all values. * `CD_CONSTRUCT` refers to the "default construct" C++ term. * Only necessary or defined for non-trivial types like vertex groups. * Doesn't do anything for trivial types like `int` or `float3`. * Should be used every other time, when all values will be set. The attribute API's `AttributeInit` types are updated as well. To update code, replace `CD_CALLOC` with `CD_SET_DEFAULT` and `CD_DEFAULT` with `CD_CONSTRUCT`. This doesn't cause any functional changes yet. Follow-up commits will change to avoid initializing new layers where the correctness is clear. Differential Revision: https://developer.blender.org/D15617
2022-08-30 14:54:53 -05:00
&me->vdata, &target->vdata, CD_MASK_MESH.vmask, CD_SET_DEFAULT, target->totvert);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
if (me->totloop) {
CustomData_merge(
Attributes: Improve custom data initialization options When allocating new `CustomData` layers, often we do redundant initialization of arrays. For example, it's common that values are allocated, set to their default value, and then set to some other value. This is wasteful, and it negates the benefits of optimizations to the allocator like D15082. There are two reasons for this. The first is array-of-structs storage that makes it annoying to initialize values manually, and the second is confusing options in the Custom Data API. This patch addresses the latter. The `CustomData` "alloc type" options are rearranged. Now, besides the options that use existing layers, there are two remaining: * `CD_SET_DEFAULT` sets the default value. * Usually zeroes, but for colors this is white (how it was before). * Should be used when you add the layer but don't set all values. * `CD_CONSTRUCT` refers to the "default construct" C++ term. * Only necessary or defined for non-trivial types like vertex groups. * Doesn't do anything for trivial types like `int` or `float3`. * Should be used every other time, when all values will be set. The attribute API's `AttributeInit` types are updated as well. To update code, replace `CD_CALLOC` with `CD_SET_DEFAULT` and `CD_DEFAULT` with `CD_CONSTRUCT`. This doesn't cause any functional changes yet. Follow-up commits will change to avoid initializing new layers where the correctness is clear. Differential Revision: https://developer.blender.org/D15617
2022-08-30 14:54:53 -05:00
&me->ldata, &target->ldata, CD_MASK_MESH.lmask, CD_SET_DEFAULT, target->totloop);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
if (me->totpoly) {
CustomData_merge(
Attributes: Improve custom data initialization options When allocating new `CustomData` layers, often we do redundant initialization of arrays. For example, it's common that values are allocated, set to their default value, and then set to some other value. This is wasteful, and it negates the benefits of optimizations to the allocator like D15082. There are two reasons for this. The first is array-of-structs storage that makes it annoying to initialize values manually, and the second is confusing options in the Custom Data API. This patch addresses the latter. The `CustomData` "alloc type" options are rearranged. Now, besides the options that use existing layers, there are two remaining: * `CD_SET_DEFAULT` sets the default value. * Usually zeroes, but for colors this is white (how it was before). * Should be used when you add the layer but don't set all values. * `CD_CONSTRUCT` refers to the "default construct" C++ term. * Only necessary or defined for non-trivial types like vertex groups. * Doesn't do anything for trivial types like `int` or `float3`. * Should be used every other time, when all values will be set. The attribute API's `AttributeInit` types are updated as well. To update code, replace `CD_CALLOC` with `CD_SET_DEFAULT` and `CD_DEFAULT` with `CD_CONSTRUCT`. This doesn't cause any functional changes yet. Follow-up commits will change to avoid initializing new layers where the correctness is clear. Differential Revision: https://developer.blender.org/D15617
2022-08-30 14:54:53 -05:00
&me->pdata, &target->pdata, CD_MASK_MESH.pmask, CD_SET_DEFAULT, target->totpoly);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
}
}
static void merge_edge_customdata_layers(Mesh *target, MeshesToIMeshInfo &mim)
{
Fix T103011: Exact boolean skips copying edge custom data layers When converting from imesh to mesh for the final result, custom data should be copied from ALL operands including the main mesh. Differential Revision: https://developer.blender.org/D16854
2022-12-26 14:43:32 -05:00
for (int mesh_index = 0; mesh_index < mim.meshes.size(); ++mesh_index) {
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
const Mesh *me = mim.meshes[mesh_index];
if (me->totedge) {
CustomData_merge(
Attributes: Improve custom data initialization options When allocating new `CustomData` layers, often we do redundant initialization of arrays. For example, it's common that values are allocated, set to their default value, and then set to some other value. This is wasteful, and it negates the benefits of optimizations to the allocator like D15082. There are two reasons for this. The first is array-of-structs storage that makes it annoying to initialize values manually, and the second is confusing options in the Custom Data API. This patch addresses the latter. The `CustomData` "alloc type" options are rearranged. Now, besides the options that use existing layers, there are two remaining: * `CD_SET_DEFAULT` sets the default value. * Usually zeroes, but for colors this is white (how it was before). * Should be used when you add the layer but don't set all values. * `CD_CONSTRUCT` refers to the "default construct" C++ term. * Only necessary or defined for non-trivial types like vertex groups. * Doesn't do anything for trivial types like `int` or `float3`. * Should be used every other time, when all values will be set. The attribute API's `AttributeInit` types are updated as well. To update code, replace `CD_CALLOC` with `CD_SET_DEFAULT` and `CD_DEFAULT` with `CD_CONSTRUCT`. This doesn't cause any functional changes yet. Follow-up commits will change to avoid initializing new layers where the correctness is clear. Differential Revision: https://developer.blender.org/D15617
2022-08-30 14:54:53 -05:00
&me->edata, &target->edata, CD_MASK_MESH.emask, CD_SET_DEFAULT, target->totedge);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
}
}
Cleanup: use our own code style for doxy-gen comment blocks
2021-04-09 18:47:10 +10:00
/**
* Convert the output IMesh im to a Blender Mesh,
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
* using the information in mim to get all the attributes right.
*/
static Mesh *imesh_to_mesh(IMesh *im, MeshesToIMeshInfo &mim)
{
constexpr int dbg_level = 0;
im->populate_vert();
int out_totvert = im->vert_size();
int out_totpoly = im->face_size();
int out_totloop = 0;
for (const Face *f : im->faces()) {
out_totloop += f->size();
}
/* Will calculate edges later. */
Mesh *result = BKE_mesh_new_nomain_from_template(
Cleanup: Remove legacy argument from mesh creation functions The legacy `tessface_len` argument was only used for the explode modifier. Remove it and copy the legacy face data manually there.
2023-02-27 11:09:26 -05:00
mim.meshes[0], out_totvert, 0, out_totloop, out_totpoly);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
merge_vertex_loop_poly_customdata_layers(result, mim);
/* Set the vertex coordinate values and other data. */
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
MutableSpan<float3> positions = result->vert_positions_for_write();
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
for (int vi : im->vert_index_range()) {
const Vert *v = im->vert(vi);
if (v->orig != NO_INDEX) {
const Mesh *orig_me;
int index_in_orig_me;
Mesh: Move selection flags to generic attributes 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-23 09:38:37 -05:00
mim.input_mvert_for_orig_index(v->orig, &orig_me, &index_in_orig_me);
copy_vert_attributes(result, orig_me, vi, index_in_orig_me);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
copy_v3fl_v3db(positions[vi], v->co);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
/* Set the loopstart and totloop for each output poly,
* and set the vertices in the appropriate loops. */
Mesh: Move material indices to a generic attribute 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-31 09:09:01 -05:00
bke::SpanAttributeWriter<int> dst_material_indices =
Cleanup: Use C++ methods to retrieve attribute accessors Replace `mesh_attributes`, `mesh_attributes_for_write` and the point cloud versions with methods on the `Mesh` and `PointCloud` types. This makes them friendlier to use and improves readability. Differential Revision: https://developer.blender.org/D15907
2022-09-07 21:41:39 -05:00
result->attributes_for_write().lookup_or_add_for_write_only_span<int>("material_index",
ATTR_DOMAIN_FACE);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
int cur_loop_index = 0;
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
MutableSpan<MLoop> dst_loops = result->loops_for_write();
Cleanup: Tweak naming for recently added mesh accessors Use `verts` instead of `vertices` and `polys` instead of `polygons` in the API added in 05952aa94d33eeb50. This aligns better with existing naming where the shorter names are much more common.
2022-09-07 00:06:31 -05:00
MutableSpan<MPoly> dst_polys = result->polys_for_write();
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
MLoop *l = dst_loops.data();
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
for (int fi : im->face_index_range()) {
const Face *f = im->face(fi);
const Mesh *orig_me;
int index_in_orig_me;
int orig_me_index;
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
const MPoly *orig_poly = mim.input_mpoly_for_orig_index(
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
f->orig, &orig_me, &orig_me_index, &index_in_orig_me);
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
MPoly *poly = &dst_polys[fi];
poly->totloop = f->size();
poly->loopstart = cur_loop_index;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
for (int j : f->index_range()) {
const Vert *vf = f->vert[j];
const int vfi = im->lookup_vert(vf);
l->v = vfi;
++l;
++cur_loop_index;
}
Fix T86427 Exact solver does not apply target material. I had done some experiments to see what Fast boolean did for material mapping and thought it just used the same slot in the target as the slot in the source. The truth is more complicated: if the target material exists in any slot of the destination, we need to remap to whatever slot has the matching material. I fixed Exact Boolean to do this. Since the materials may be in the object, this means that BKE_mesh_boolean had to get another argument, the remapping arrays. I will note that the current behavior of Fast, and now Exact, is not ideal. Ideally, if the source material does not exist in the target, a new material slot should be created in the target and the source material copied there (and incrementing the material's reference count). Maybe a future project, but for now, I want the behavior of Exact to match that of Fast.
2021-03-14 11:39:56 -04:00
Cleanup: Remove unecessary C API for direct mesh boolean The main goal here is to remove the need for a C API to the code in `mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c` to C++ and making the necessary changes for it to compile. On top of that there are some other slight simplifications possible to the direct mesh boolean code: it doesn't need to copy the material remaps, and the modifier code can use some other C++ types directly.
2021-04-02 00:16:01 -05:00
copy_poly_attributes(result,
orig_me,
fi,
index_in_orig_me,
(mim.material_remaps.size() > 0) ?
mim.material_remaps[orig_me_index].as_span() :
Mesh: Move material indices to a generic attribute 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-31 09:09:01 -05:00
Span<short>(),
dst_material_indices.span);
Cleanup: Standardize mesh edge and poly naming With the goal of clearly differentiating between arrays and single elements, improving consistency across Blender, and using wording that's easier to read and say, change variable names for Mesh edges and polygons/faces. Common renames are the following, with some extra prefixes, etc. - `mpoly` -> `polys` - `mpoly`/`mp`/`p` -> `poly` - `medge` -> `edges` - `med`/`ed`/`e` -> `edge` `MLoop` variables aren't affected because they will be replaced when they're split up into to arrays in #104424.
2023-03-01 15:57:50 -05:00
copy_or_interp_loop_attributes(result, f, poly, orig_poly, orig_me, orig_me_index, mim);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
Mesh: Move material indices to a generic attribute 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-31 09:09:01 -05:00
dst_material_indices.finish();
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
/* BKE_mesh_calc_edges will calculate and populate all the
* MEdges from the MPolys. */
BKE_mesh_calc_edges(result, false, false);
merge_edge_customdata_layers(result, mim);
/* Now that the MEdges are populated, we can copy over the required attributes and custom layers.
*/
for (int fi : im->face_index_range()) {
const Face *f = im->face(fi);
Cleanup: Use references for mesh poly variables Similar to the previous commit, this simplifies future refactoring to change the way edges are stored, and further differentiates single poly variables from array pointers.
2023-03-03 11:40:34 -05:00
const MPoly &poly = dst_polys[fi];
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
for (int j : f->index_range()) {
if (f->edge_orig[j] != NO_INDEX) {
const Mesh *orig_me;
int index_in_orig_me;
Mesh: Move edge UV seams to a generic attribute As part of #95966, move the `ME_SEAM` flag on mesh edges to a generic boolean attribute, called `.uv_seam`. This is the last bit of extra information stored in mesh edges. After this is committed we can switch to a different type for them and have a 1/3 improvement in memory consumption. It is also now possible to see that a mesh has no UV seams in constant time, and like other similar refactors, interacting with only the UV seams can be done with less memory. The attribute name starts with a `.` to signify that the attribute, like face sets, isn't meant to be used in arbitrary procedural situations (with geometry nodes for example). That gives us more freedom to change things in the future. Pull Request #104728
2023-03-01 14:13:05 +01:00
mim.input_medge_for_orig_index(f->edge_orig[j], &orig_me, &index_in_orig_me);
Cleanup: Use references for mesh poly variables Similar to the previous commit, this simplifies future refactoring to change the way edges are stored, and further differentiates single poly variables from array pointers.
2023-03-03 11:40:34 -05:00
int e_index = dst_loops[poly.loopstart + j].e;
Mesh: Move edge UV seams to a generic attribute As part of #95966, move the `ME_SEAM` flag on mesh edges to a generic boolean attribute, called `.uv_seam`. This is the last bit of extra information stored in mesh edges. After this is committed we can switch to a different type for them and have a 1/3 improvement in memory consumption. It is also now possible to see that a mesh has no UV seams in constant time, and like other similar refactors, interacting with only the UV seams can be done with less memory. The attribute name starts with a `.` to signify that the attribute, like face sets, isn't meant to be used in arbitrary procedural situations (with geometry nodes for example). That gives us more freedom to change things in the future. Pull Request #104728
2023-03-01 14:13:05 +01:00
copy_edge_attributes(result, orig_me, e_index, index_in_orig_me);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
}
}
if (dbg_level > 0) {
BKE_mesh_validate(result, true, true);
}
return result;
}
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
#endif // WITH_GMP
Mesh *direct_mesh_boolean(Span<const Mesh *> meshes,
Cleanup: Reword comment, rename variables Use "transform" instead of "obmat", because the meshes don't necessarily come from objects.
2022-04-27 18:52:56 -05:00
Span<const float4x4 *> transforms,
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
const float4x4 &target_transform,
Cleanup: Remove unecessary C API for direct mesh boolean The main goal here is to remove the need for a C API to the code in `mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c` to C++ and making the necessary changes for it to compile. On top of that there are some other slight simplifications possible to the direct mesh boolean code: it doesn't need to copy the material remaps, and the modifier code can use some other C++ types directly.
2021-04-02 00:16:01 -05:00
Span<Array<short>> material_remaps,
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
const bool use_self,
const bool hole_tolerant,
Geometry Nodes: add 'Intersecting Edges' output for boolean node This patch adds a 'Intersecting Edges' output with a boolean selection that only gives you the new edges on intersections. Will work on a couple of examples next, this should make some interesting effects possible (including getting us closer to the "bevel- after-boolean-usecase") To achieve this, a Vector is passed to `direct_mesh_boolean` when the iMesh is still available (and intersecting edges appended), then from those edge indices a selection will be stored as attribute. Differential Revision: https://developer.blender.org/D15151
2022-04-04 12:26:50 +02:00
const int boolean_mode,
Vector<int> *r_intersecting_edges)
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
{
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
#ifdef WITH_GMP
Cleanup: Reword comment, rename variables Use "transform" instead of "obmat", because the meshes don't necessarily come from objects.
2022-04-27 18:52:56 -05:00
BLI_assert(meshes.size() == transforms.size());
Cleanup: Remove unecessary C API for direct mesh boolean The main goal here is to remove the need for a C API to the code in `mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c` to C++ and making the necessary changes for it to compile. On top of that there are some other slight simplifications possible to the direct mesh boolean code: it doesn't need to copy the material remaps, and the modifier code can use some other C++ types directly.
2021-04-02 00:16:01 -05:00
BLI_assert(material_remaps.size() == 0 || material_remaps.size() == meshes.size());
if (meshes.size() <= 0) {
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
return nullptr;
}
Cleanup: Remove unecessary C API for direct mesh boolean The main goal here is to remove the need for a C API to the code in `mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c` to C++ and making the necessary changes for it to compile. On top of that there are some other slight simplifications possible to the direct mesh boolean code: it doesn't need to copy the material remaps, and the modifier code can use some other C++ types directly.
2021-04-02 00:16:01 -05:00
const int dbg_level = 0;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
if (dbg_level > 0) {
Cleanup: Remove unecessary C API for direct mesh boolean The main goal here is to remove the need for a C API to the code in `mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c` to C++ and making the necessary changes for it to compile. On top of that there are some other slight simplifications possible to the direct mesh boolean code: it doesn't need to copy the material remaps, and the modifier code can use some other C++ types directly.
2021-04-02 00:16:01 -05:00
std::cout << "\nDIRECT_MESH_INTERSECT, nmeshes = " << meshes.size() << "\n";
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
MeshesToIMeshInfo mim;
IMeshArena arena;
Cleanup: Reword comment, rename variables Use "transform" instead of "obmat", because the meshes don't necessarily come from objects.
2022-04-27 18:52:56 -05:00
IMesh m_in = meshes_to_imesh(meshes, transforms, material_remaps, target_transform, arena, &mim);
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
std::function<int(int)> shape_fn = [&mim](int f) {
for (int mi = 0; mi < mim.mesh_poly_offset.size() - 1; ++mi) {
if (f < mim.mesh_poly_offset[mi + 1]) {
return mi;
}
}
Cleanup: replace static_casts with functional casts for numeric types
2022-09-25 18:30:50 +10:00
return int(mim.mesh_poly_offset.size()) - 1;
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
};
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
IMesh m_out = boolean_mesh(m_in,
static_cast<BoolOpType>(boolean_mode),
Cleanup: Remove unecessary C API for direct mesh boolean The main goal here is to remove the need for a C API to the code in `mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c` to C++ and making the necessary changes for it to compile. On top of that there are some other slight simplifications possible to the direct mesh boolean code: it doesn't need to copy the material remaps, and the modifier code can use some other C++ types directly.
2021-04-02 00:16:01 -05:00
meshes.size(),
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
shape_fn,
use_self,
hole_tolerant,
nullptr,
&arena);
Cleanup: Remove unecessary C API for direct mesh boolean The main goal here is to remove the need for a C API to the code in `mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c` to C++ and making the necessary changes for it to compile. On top of that there are some other slight simplifications possible to the direct mesh boolean code: it doesn't need to copy the material remaps, and the modifier code can use some other C++ types directly.
2021-04-02 00:16:01 -05:00
if (dbg_level > 0) {
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
std::cout << m_out;
write_obj_mesh(m_out, "m_out");
}
Geometry Nodes: add 'Intersecting Edges' output for boolean node This patch adds a 'Intersecting Edges' output with a boolean selection that only gives you the new edges on intersections. Will work on a couple of examples next, this should make some interesting effects possible (including getting us closer to the "bevel- after-boolean-usecase") To achieve this, a Vector is passed to `direct_mesh_boolean` when the iMesh is still available (and intersecting edges appended), then from those edge indices a selection will be stored as attribute. Differential Revision: https://developer.blender.org/D15151
2022-04-04 12:26:50 +02:00
Mesh *result = imesh_to_mesh(&m_out, mim);
/* Store intersecting edge indices. */
if (r_intersecting_edges != nullptr) {
Cleanup: Tweak naming for recently added mesh accessors Use `verts` instead of `vertices` and `polys` instead of `polygons` in the API added in 05952aa94d33eeb50. This aligns better with existing naming where the shorter names are much more common.
2022-09-07 00:06:31 -05:00
const Span<MPoly> polys = result->polys();
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
const Span<MLoop> loops = result->loops();
Geometry Nodes: add 'Intersecting Edges' output for boolean node This patch adds a 'Intersecting Edges' output with a boolean selection that only gives you the new edges on intersections. Will work on a couple of examples next, this should make some interesting effects possible (including getting us closer to the "bevel- after-boolean-usecase") To achieve this, a Vector is passed to `direct_mesh_boolean` when the iMesh is still available (and intersecting edges appended), then from those edge indices a selection will be stored as attribute. Differential Revision: https://developer.blender.org/D15151
2022-04-04 12:26:50 +02:00
for (int fi : m_out.face_index_range()) {
const Face &face = *m_out.face(fi);
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
const MPoly &poly = polys[fi];
Geometry Nodes: add 'Intersecting Edges' output for boolean node This patch adds a 'Intersecting Edges' output with a boolean selection that only gives you the new edges on intersections. Will work on a couple of examples next, this should make some interesting effects possible (including getting us closer to the "bevel- after-boolean-usecase") To achieve this, a Vector is passed to `direct_mesh_boolean` when the iMesh is still available (and intersecting edges appended), then from those edge indices a selection will be stored as attribute. Differential Revision: https://developer.blender.org/D15151
2022-04-04 12:26:50 +02:00
for (int corner_i : face.index_range()) {
if (face.is_intersect[corner_i]) {
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
int e_index = loops[poly.loopstart + corner_i].e;
Geometry Nodes: add 'Intersecting Edges' output for boolean node This patch adds a 'Intersecting Edges' output with a boolean selection that only gives you the new edges on intersections. Will work on a couple of examples next, this should make some interesting effects possible (including getting us closer to the "bevel- after-boolean-usecase") To achieve this, a Vector is passed to `direct_mesh_boolean` when the iMesh is still available (and intersecting edges appended), then from those edge indices a selection will be stored as attribute. Differential Revision: https://developer.blender.org/D15151
2022-04-04 12:26:50 +02:00
r_intersecting_edges->append(e_index);
}
}
}
}
return result;
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
#else // WITH_GMP
Cleanup: Reword comment, rename variables Use "transform" instead of "obmat", because the meshes don't necessarily come from objects.
2022-04-27 18:52:56 -05:00
UNUSED_VARS(meshes,
transforms,
material_remaps,
target_transform,
use_self,
hole_tolerant,
Cleanup: unused variable warning
2022-06-17 07:23:21 +10:00
boolean_mode,
r_intersecting_edges);
Geometry Nodes: Improve speed of boolean node, use multi-input socket This commit improves the performance of the node by up to 40% in some cases when there are only two input meshes, mainly by skipping the conversion to and from BMesh. When there are more than two input meshes (note the distinction from "Geometries", a geometry set can have many mesh instances), the performance is actually worse, since boolean currently always does self intersection in that case. Theoretically this could be improved in the boolean code, or another option is automatically realizing instances for each input geometry set. Another improvement is using multi-input sockets for the inputs, which removes the need to have a separate boolean node for every operation, which can hopefully simplify some node trees. The changes necessary for transforms in `mesh_boolean_convert.cc` are somewhat subtle; they come from the fact that the collecting the geometry set instances already gives transforms in the local space of the modifier object. There is also a very small amount of cleanup to those lines, using `float4x4::identity()`. This commit also fixes T87078, where overlapping difference meshes makes the operation not work, though I haven't investigated why. Differential Revision: https://developer.blender.org/D10599
2021-04-01 15:00:47 -05:00
return nullptr;
#endif // WITH_GMP
Change Exact Boolean modifier to skip round trip through BMesh. The Exact modifier code had been written to avoid using BMesh but in the initial release the modifier still converted all Meshes to BMeshes, and then after running the boolean code on the BMeshes, converted the result back to a Mesh. This change skips that. Most of the work here is in getting the Custom Data layers right. The approach taken is to merge default layers from all operand meshes into the final result, and then use the original verts, edges, polys, and loops to copy or interpolate the appropriate custom data layers from all operands into the result.
2021-02-21 17:57:03 -05:00
}
} // namespace blender::meshintersect
Reference in New Issue Copy Permalink