2023-08-15 16:20:26 +02:00
|
|
|
/* SPDX-FileCopyrightText: 2005 Blender Authors
|
2023-05-31 16:19:06 +02:00
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2005-03-27 22:34:18 +02:00
|
|
|
|
2019-02-17 22:08:12 +01:00
|
|
|
/** \file
|
|
|
|
* \ingroup bke
|
2011-02-27 21:40:57 +01:00
|
|
|
*/
|
|
|
|
|
2020-12-14 13:00:28 +01:00
|
|
|
#include <climits>
|
|
|
|
#include <cstring>
|
2005-07-23 21:15:08 +02:00
|
|
|
|
2005-03-27 22:34:18 +02:00
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
2010-03-30 13:49:07 +02:00
|
|
|
#include "DNA_cloth_types.h"
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
#include "DNA_customdata_types.h"
|
2006-08-28 03:12:36 +02:00
|
|
|
#include "DNA_key_types.h"
|
2014-07-21 12:02:05 +02:00
|
|
|
#include "DNA_material_types.h"
|
2012-02-19 23:17:30 +01:00
|
|
|
#include "DNA_mesh_types.h"
|
2005-03-27 22:34:18 +02:00
|
|
|
#include "DNA_meshdata_types.h"
|
|
|
|
#include "DNA_object_types.h"
|
2014-04-27 18:22:03 +02:00
|
|
|
#include "DNA_scene_types.h"
|
2005-03-27 22:34:18 +02:00
|
|
|
|
2014-09-04 09:53:10 +02:00
|
|
|
#include "BLI_bitmap.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_blenlib.h"
|
2011-10-22 03:53:35 +02:00
|
|
|
#include "BLI_linklist.h"
|
Cleanup: reduce amount of math-related includes
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
2023-08-09 10:39:20 +02:00
|
|
|
#include "BLI_math_geom.h"
|
|
|
|
#include "BLI_math_matrix.h"
|
2023-01-04 00:14:55 +01:00
|
|
|
#include "BLI_math_vector_types.hh"
|
2023-08-22 03:51:53 +02:00
|
|
|
#include "BLI_span.hh"
|
2016-04-26 10:43:02 +02:00
|
|
|
#include "BLI_task.h"
|
2021-06-21 18:44:40 +02:00
|
|
|
#include "BLI_task.hh"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_utildefines.h"
|
2020-12-14 13:00:28 +01:00
|
|
|
#include "BLI_vector.hh"
|
2005-03-27 22:34:18 +02:00
|
|
|
|
2023-11-16 11:41:55 +01:00
|
|
|
#include "BKE_DerivedMesh.hh"
|
|
|
|
#include "BKE_bvhutils.hh"
|
2017-12-07 05:36:26 +01:00
|
|
|
#include "BKE_colorband.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BKE_deform.h"
|
2023-11-16 11:41:55 +01:00
|
|
|
#include "BKE_editmesh.hh"
|
2023-07-07 14:19:52 +02:00
|
|
|
#include "BKE_editmesh_cache.hh"
|
2020-12-15 12:42:10 +01:00
|
|
|
#include "BKE_geometry_set.hh"
|
2021-02-17 12:27:32 +01:00
|
|
|
#include "BKE_geometry_set_instances.hh"
|
2007-10-31 14:56:07 +01:00
|
|
|
#include "BKE_key.h"
|
2017-04-18 14:55:31 +02:00
|
|
|
#include "BKE_layer.h"
|
2020-02-10 12:58:59 +01:00
|
|
|
#include "BKE_lib_id.h"
|
2014-04-09 03:03:25 +02:00
|
|
|
#include "BKE_material.h"
|
2023-03-12 22:29:15 +01:00
|
|
|
#include "BKE_mesh.hh"
|
2023-08-02 22:14:18 +02:00
|
|
|
#include "BKE_mesh_iterators.hh"
|
|
|
|
#include "BKE_mesh_mapping.hh"
|
|
|
|
#include "BKE_mesh_runtime.hh"
|
|
|
|
#include "BKE_mesh_tangent.hh"
|
|
|
|
#include "BKE_mesh_wrapper.hh"
|
2023-11-14 09:30:40 +01:00
|
|
|
#include "BKE_modifier.hh"
|
2023-08-02 22:14:18 +02:00
|
|
|
#include "BKE_multires.hh"
|
2023-10-09 23:41:53 +02:00
|
|
|
#include "BKE_object.hh"
|
2012-09-05 05:45:32 +02:00
|
|
|
#include "BKE_object_deform.h"
|
2023-11-15 18:46:07 +01:00
|
|
|
#include "BKE_object_types.hh"
|
2023-08-02 22:14:18 +02:00
|
|
|
#include "BKE_paint.hh"
|
|
|
|
#include "BKE_subdiv_modifier.hh"
|
2005-03-27 22:34:18 +02:00
|
|
|
|
2013-05-28 21:35:26 +02:00
|
|
|
#include "BLI_sys_types.h" /* for intptr_t support */
|
2008-08-17 19:08:00 +02:00
|
|
|
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BKE_shrinkwrap.h"
|
2023-09-22 03:18:17 +02:00
|
|
|
#include "DEG_depsgraph.hh"
|
|
|
|
#include "DEG_depsgraph_query.hh"
|
2018-04-16 20:45:43 +02:00
|
|
|
|
2019-02-01 02:44:19 +01:00
|
|
|
#include "CLG_log.h"
|
|
|
|
|
2015-08-03 20:35:43 +02:00
|
|
|
#ifdef WITH_OPENSUBDIV
|
|
|
|
# include "DNA_userdef_types.h"
|
|
|
|
#endif
|
|
|
|
|
2022-07-08 14:45:48 +02:00
|
|
|
using blender::float3;
|
|
|
|
using blender::IndexRange;
|
2023-08-22 03:51:53 +02:00
|
|
|
using blender::MutableSpan;
|
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 18:56:34 +02:00
|
|
|
using blender::Span;
|
|
|
|
using blender::VArray;
|
2023-06-15 22:18:28 +02:00
|
|
|
using blender::bke::GeometryOwnershipType;
|
|
|
|
using blender::bke::GeometrySet;
|
|
|
|
using blender::bke::MeshComponent;
|
2022-07-08 14:45:48 +02:00
|
|
|
|
2013-09-04 03:29:34 +02:00
|
|
|
/* very slow! enable for testing only! */
|
2014-12-02 13:49:40 +01:00
|
|
|
//#define USE_MODIFIER_VALIDATE
|
2013-09-04 03:29:34 +02:00
|
|
|
|
|
|
|
#ifdef USE_MODIFIER_VALIDATE
|
2018-05-11 09:53:52 +02:00
|
|
|
# define ASSERT_IS_VALID_MESH(mesh) \
|
2020-12-14 13:00:28 +01:00
|
|
|
(BLI_assert((mesh == nullptr) || (BKE_mesh_is_valid(mesh) == true)))
|
2013-09-04 03:29:34 +02:00
|
|
|
#else
|
2018-05-11 09:53:52 +02:00
|
|
|
# define ASSERT_IS_VALID_MESH(mesh)
|
2013-09-04 03:29:34 +02:00
|
|
|
#endif
|
|
|
|
|
2018-05-11 09:53:52 +02:00
|
|
|
static void mesh_init_origspace(Mesh *mesh);
|
Mesh: Replace auto smooth with node group
Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
2023-10-20 16:54:08 +02:00
|
|
|
static void editbmesh_calc_modifier_final_normals(Mesh *mesh_final);
|
|
|
|
static void editbmesh_calc_modifier_final_normals_or_defer(Mesh *mesh_final);
|
2018-05-11 09:53:52 +02:00
|
|
|
|
2013-09-04 03:29:34 +02:00
|
|
|
/* -------------------------------------------------------------------- */
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01: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 06:10:43 +01:00
|
|
|
static float *dm_getVertArray(DerivedMesh *dm)
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
{
|
2023-01-14 00:21:20 +01:00
|
|
|
float(*positions)[3] = (float(*)[3])CustomData_get_layer_named_for_write(
|
|
|
|
&dm->vertData, CD_PROP_FLOAT3, "position", dm->getNumVerts(dm));
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01: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 06:10:43 +01:00
|
|
|
if (!positions) {
|
|
|
|
positions = (float(*)[3])CustomData_add_layer_named(
|
2023-03-14 15:30:26 +01:00
|
|
|
&dm->vertData, CD_PROP_FLOAT3, CD_SET_DEFAULT, dm->getNumVerts(dm), "position");
|
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 06:10:43 +01:00
|
|
|
CustomData_set_layer_flag(&dm->vertData, CD_PROP_FLOAT3, CD_FLAG_TEMPORARY);
|
|
|
|
dm->copyVertArray(dm, positions);
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01: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 06:10:43 +01:00
|
|
|
return (float *)positions;
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
}
|
|
|
|
|
Mesh: Move edges to a generic attribute
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
2023-04-17 13:47:41 +02:00
|
|
|
static vec2i *dm_getEdgeArray(DerivedMesh *dm)
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
{
|
Mesh: Move edges to a generic attribute
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
2023-04-17 13:47:41 +02:00
|
|
|
vec2i *edge = (vec2i *)CustomData_get_layer_named_for_write(
|
|
|
|
&dm->edgeData, CD_PROP_INT32_2D, ".edge_verts", dm->getNumEdges(dm));
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
|
2023-03-01 21:57:50 +01:00
|
|
|
if (!edge) {
|
Mesh: Move edges to a generic attribute
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
2023-04-17 13:47:41 +02:00
|
|
|
edge = (vec2i *)CustomData_add_layer_named(
|
|
|
|
&dm->edgeData, CD_PROP_INT32_2D, CD_SET_DEFAULT, dm->getNumEdges(dm), ".edge_verts");
|
|
|
|
CustomData_set_layer_flag(&dm->edgeData, CD_PROP_INT32_2D, CD_FLAG_TEMPORARY);
|
2023-03-01 21:57:50 +01:00
|
|
|
dm->copyEdgeArray(dm, edge);
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
}
|
|
|
|
|
2023-03-01 21:57:50 +01:00
|
|
|
return edge;
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
}
|
|
|
|
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
static int *dm_getCornerVertArray(DerivedMesh *dm)
|
2011-06-14 05:16:08 +02:00
|
|
|
{
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
int *corner_verts = (int *)CustomData_get_layer_named_for_write(
|
|
|
|
&dm->loopData, CD_PROP_INT32, ".corner_vert", dm->getNumLoops(dm));
|
2011-06-14 05:16:08 +02:00
|
|
|
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
if (!corner_verts) {
|
|
|
|
corner_verts = (int *)CustomData_add_layer_named(
|
|
|
|
&dm->loopData, CD_PROP_INT32, CD_SET_DEFAULT, dm->getNumLoops(dm), ".corner_vert");
|
|
|
|
dm->copyCornerVertArray(dm, corner_verts);
|
2011-06-14 05:16:08 +02:00
|
|
|
}
|
|
|
|
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
return corner_verts;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int *dm_getCornerEdgeArray(DerivedMesh *dm)
|
|
|
|
{
|
|
|
|
int *corner_edges = (int *)CustomData_get_layer_named(
|
|
|
|
&dm->loopData, CD_PROP_INT32, ".corner_edge");
|
|
|
|
|
|
|
|
if (!corner_edges) {
|
|
|
|
corner_edges = (int *)CustomData_add_layer_named(
|
|
|
|
&dm->loopData, CD_PROP_INT32, CD_SET_DEFAULT, dm->getNumLoops(dm), ".corner_edge");
|
|
|
|
dm->copyCornerEdgeArray(dm, corner_edges);
|
|
|
|
}
|
|
|
|
|
|
|
|
return corner_edges;
|
2011-06-14 05:16:08 +02:00
|
|
|
}
|
|
|
|
|
Mesh: Replace MPoly struct with offset indices
Implements #95967.
Currently the `MPoly` struct is 12 bytes, and stores the index of a
face's first corner and the number of corners/verts/edges. Polygons
and corners are always created in order by Blender, meaning each
face's corners will be after the previous face's corners. We can take
advantage of this fact and eliminate the redundancy in mesh face
storage by only storing a single integer corner offset for each face.
The size of the face is then encoded by the offset of the next face.
The size of a single integer is 4 bytes, so this reduces memory
usage by 3 times.
The same method is used for `CurvesGeometry`, so Blender already has
an abstraction to simplify using these offsets called `OffsetIndices`.
This class is used to easily retrieve a range of corner indices for
each face. This also gives the opportunity for sharing some logic with
curves.
Another benefit of the change is that the offsets and sizes stored in
`MPoly` can no longer disagree with each other. Storing faces in the
order of their corners can simplify some code too.
Face/polygon variables now use the `IndexRange` type, which comes with
quite a few utilities that can simplify code.
Some:
- The offset integer array has to be one longer than the face count to
avoid a branch for every face, which means the data is no longer part
of the mesh's `CustomData`.
- We lose the ability to "reference" an original mesh's offset array
until more reusable CoW from #104478 is committed. That will be added
in a separate commit.
- Since they aren't part of `CustomData`, poly offsets often have to be
copied manually.
- To simplify using `OffsetIndices` in many places, some functions and
structs in headers were moved to only compile in C++.
- All meshes created by Blender use the same order for faces and face
corners, but just in case, meshes with mismatched order are fixed by
versioning code.
- `MeshPolygon.totloop` is no longer editable in RNA. This API break is
necessary here unfortunately. It should be worth it in 3.6, since
that's the best way to allow loading meshes from 4.0, which is
important for an LTS version.
Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
|
|
|
static int *dm_getPolyArray(DerivedMesh *dm)
|
2011-06-14 05:16:08 +02:00
|
|
|
{
|
2023-07-24 22:06:55 +02:00
|
|
|
if (!dm->face_offsets) {
|
|
|
|
dm->face_offsets = MEM_cnew_array<int>(dm->getNumPolys(dm) + 1, __func__);
|
|
|
|
dm->copyPolyArray(dm, dm->face_offsets);
|
2011-06-14 05:16:08 +02:00
|
|
|
}
|
2023-07-24 22:06:55 +02:00
|
|
|
return dm->face_offsets;
|
2011-06-14 05:16:08 +02:00
|
|
|
}
|
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
void DM_init_funcs(DerivedMesh *dm)
|
|
|
|
{
|
|
|
|
/* default function implementations */
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
dm->getVertArray = dm_getVertArray;
|
|
|
|
dm->getEdgeArray = dm_getEdgeArray;
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
dm->getCornerVertArray = dm_getCornerVertArray;
|
|
|
|
dm->getCornerEdgeArray = dm_getCornerEdgeArray;
|
2011-06-14 05:16:08 +02:00
|
|
|
dm->getPolyArray = dm_getPolyArray;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
dm->getVertDataArray = DM_get_vert_data_layer;
|
|
|
|
dm->getEdgeDataArray = DM_get_edge_data_layer;
|
2012-10-30 20:20:17 +01:00
|
|
|
dm->getPolyDataArray = DM_get_poly_data_layer;
|
2013-04-03 22:10:08 +02:00
|
|
|
dm->getLoopDataArray = DM_get_loop_data_layer;
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
2015-07-02 08:20:22 +02:00
|
|
|
void DM_init(DerivedMesh *dm,
|
|
|
|
DerivedMeshType type,
|
|
|
|
int numVerts,
|
|
|
|
int numEdges,
|
|
|
|
int numTessFaces,
|
|
|
|
int numLoops,
|
|
|
|
int numPolys)
|
2006-08-28 03:12:36 +02:00
|
|
|
{
|
2010-01-06 13:05:46 +01:00
|
|
|
dm->type = type;
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
dm->numVertData = numVerts;
|
|
|
|
dm->numEdgeData = numEdges;
|
2011-11-30 19:03:56 +01:00
|
|
|
dm->numTessFaceData = numTessFaces;
|
(NOTE: DO NOT TEST)
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
2009-06-10 12:06:25 +02:00
|
|
|
dm->numLoopData = numLoops;
|
2011-11-30 19:03:56 +01:00
|
|
|
dm->numPolyData = numPolys;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
DM_init_funcs(dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-08-12 06:34:41 +02:00
|
|
|
/* Don't use #CustomData_reset because we don't want to touch custom-data. */
|
2015-05-05 09:08:29 +02:00
|
|
|
copy_vn_i(dm->vertData.typemap, CD_NUMTYPES, -1);
|
|
|
|
copy_vn_i(dm->edgeData.typemap, CD_NUMTYPES, -1);
|
|
|
|
copy_vn_i(dm->faceData.typemap, CD_NUMTYPES, -1);
|
|
|
|
copy_vn_i(dm->loopData.typemap, CD_NUMTYPES, -1);
|
|
|
|
copy_vn_i(dm->polyData.typemap, CD_NUMTYPES, -1);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
2022-01-31 01:15:38 +01:00
|
|
|
void DM_from_template(DerivedMesh *dm,
|
|
|
|
DerivedMesh *source,
|
|
|
|
DerivedMeshType type,
|
|
|
|
int numVerts,
|
|
|
|
int numEdges,
|
|
|
|
int numTessFaces,
|
|
|
|
int numLoops,
|
|
|
|
int numPolys)
|
2006-08-28 03:12:36 +02:00
|
|
|
{
|
2022-01-31 01:15:38 +01:00
|
|
|
const CustomData_MeshMasks *mask = &CD_MASK_DERIVEDMESH;
|
2023-04-13 14:57:57 +02:00
|
|
|
CustomData_copy_layout(&source->vertData, &dm->vertData, mask->vmask, CD_SET_DEFAULT, numVerts);
|
|
|
|
CustomData_copy_layout(&source->edgeData, &dm->edgeData, mask->emask, CD_SET_DEFAULT, numEdges);
|
|
|
|
CustomData_copy_layout(
|
|
|
|
&source->faceData, &dm->faceData, mask->fmask, CD_SET_DEFAULT, numTessFaces);
|
|
|
|
CustomData_copy_layout(&source->loopData, &dm->loopData, mask->lmask, CD_SET_DEFAULT, numLoops);
|
|
|
|
CustomData_copy_layout(&source->polyData, &dm->polyData, mask->pmask, CD_SET_DEFAULT, numPolys);
|
2023-07-24 22:06:55 +02:00
|
|
|
dm->face_offsets = static_cast<int *>(MEM_dupallocN(source->face_offsets));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2010-01-06 13:05:46 +01:00
|
|
|
dm->type = type;
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
dm->numVertData = numVerts;
|
|
|
|
dm->numEdgeData = numEdges;
|
2011-11-30 19:03:56 +01:00
|
|
|
dm->numTessFaceData = numTessFaces;
|
(NOTE: DO NOT TEST)
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
2009-06-10 12:06:25 +02:00
|
|
|
dm->numLoopData = numLoops;
|
|
|
|
dm->numPolyData = numPolys;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
DM_init_funcs(dm);
|
|
|
|
}
|
|
|
|
|
2023-04-04 20:47:39 +02:00
|
|
|
void DM_release(DerivedMesh *dm)
|
2006-08-28 03:12:36 +02:00
|
|
|
{
|
2023-04-04 20:47:39 +02:00
|
|
|
CustomData_free(&dm->vertData, dm->numVertData);
|
|
|
|
CustomData_free(&dm->edgeData, dm->numEdgeData);
|
|
|
|
CustomData_free(&dm->faceData, dm->numTessFaceData);
|
|
|
|
CustomData_free(&dm->loopData, dm->numLoopData);
|
|
|
|
CustomData_free(&dm->polyData, dm->numPolyData);
|
2023-07-24 22:06:55 +02:00
|
|
|
MEM_SAFE_FREE(dm->face_offsets);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
2018-06-21 18:24:32 +02:00
|
|
|
void BKE_mesh_runtime_eval_to_meshkey(Mesh *me_deformed, Mesh *me, KeyBlock *kb)
|
2009-11-22 14:44:09 +01:00
|
|
|
{
|
2021-12-07 07:19:15 +01:00
|
|
|
/* Just a shallow wrapper around #BKE_keyblock_convert_from_mesh,
|
|
|
|
* that ensures both evaluated mesh and original one has same number of vertices. */
|
|
|
|
|
2018-06-21 18:24:32 +02:00
|
|
|
const int totvert = me_deformed->totvert;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2015-07-02 08:20:22 +02:00
|
|
|
if (totvert == 0 || me->totvert == 0 || me->totvert != totvert) {
|
|
|
|
return;
|
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2018-06-21 18:24:32 +02:00
|
|
|
BKE_keyblock_convert_from_mesh(me_deformed, me->key, kb);
|
2009-11-22 14:44:09 +01:00
|
|
|
}
|
|
|
|
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
void DM_set_only_copy(DerivedMesh *dm, const CustomData_MeshMasks *mask)
|
2006-12-05 18:42:03 +01:00
|
|
|
{
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
CustomData_set_only_copy(&dm->vertData, mask->vmask);
|
|
|
|
CustomData_set_only_copy(&dm->edgeData, mask->emask);
|
|
|
|
CustomData_set_only_copy(&dm->faceData, mask->fmask);
|
2012-10-01 16:23:57 +02:00
|
|
|
/* this wasn't in 2.63 and is disabled for 2.64 because it gives problems with
|
|
|
|
* weight paint mode when there are modifiers applied, needs further investigation,
|
|
|
|
* see replies to r50969, Campbell */
|
|
|
|
#if 0
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
CustomData_set_only_copy(&dm->loopData, mask->lmask);
|
2022-01-31 00:01:03 +01:00
|
|
|
Custom(&dm->polyData, mask->pmask);
|
2012-10-01 16:23:57 +02:00
|
|
|
#endif
|
2006-12-05 18:42:03 +01:00
|
|
|
}
|
|
|
|
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
static void mesh_set_only_copy(Mesh *mesh, const CustomData_MeshMasks *mask)
|
2018-05-11 09:53:52 +02:00
|
|
|
{
|
2023-07-25 21:15:52 +02:00
|
|
|
CustomData_set_only_copy(&mesh->vert_data, mask->vmask);
|
|
|
|
CustomData_set_only_copy(&mesh->edge_data, mask->emask);
|
2023-07-24 22:06:55 +02:00
|
|
|
CustomData_set_only_copy(&mesh->fdata_legacy, mask->fmask);
|
2018-05-11 09:53:52 +02:00
|
|
|
/* this wasn't in 2.63 and is disabled for 2.64 because it gives problems with
|
|
|
|
* weight paint mode when there are modifiers applied, needs further investigation,
|
|
|
|
* see replies to r50969, Campbell */
|
|
|
|
#if 0
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
CustomData_set_only_copy(&mesh->ldata, mask->lmask);
|
|
|
|
CustomData_set_only_copy(&mesh->pdata, mask->pmask);
|
2018-05-11 09:53:52 +02:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2023-03-29 17:10:49 +02:00
|
|
|
void *DM_get_vert_data_layer(DerivedMesh *dm, const eCustomDataType type)
|
2006-08-28 03:12:36 +02:00
|
|
|
{
|
2023-01-14 00:21:20 +01:00
|
|
|
return CustomData_get_layer_for_write(&dm->vertData, type, dm->getNumVerts(dm));
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
2023-03-29 17:10:49 +02:00
|
|
|
void *DM_get_edge_data_layer(DerivedMesh *dm, const eCustomDataType type)
|
2006-08-28 03:12:36 +02:00
|
|
|
{
|
2023-01-14 00:21:20 +01:00
|
|
|
return CustomData_get_layer_for_write(&dm->edgeData, type, dm->getNumEdges(dm));
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
2023-03-29 17:10:49 +02:00
|
|
|
void *DM_get_poly_data_layer(DerivedMesh *dm, const eCustomDataType type)
|
2009-08-15 19:31:28 +02:00
|
|
|
{
|
2023-01-14 00:21:20 +01:00
|
|
|
return CustomData_get_layer_for_write(&dm->polyData, type, dm->getNumPolys(dm));
|
2009-08-15 19:31:28 +02:00
|
|
|
}
|
|
|
|
|
2023-03-29 17:10:49 +02:00
|
|
|
void *DM_get_loop_data_layer(DerivedMesh *dm, const eCustomDataType type)
|
2012-02-05 12:30:26 +01:00
|
|
|
{
|
2023-01-14 00:21:20 +01:00
|
|
|
return CustomData_get_layer_for_write(&dm->loopData, type, dm->getNumLoops(dm));
|
2012-02-05 12:30:26 +01:00
|
|
|
}
|
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
void DM_copy_vert_data(
|
2023-04-03 23:48:05 +02:00
|
|
|
const DerivedMesh *source, DerivedMesh *dest, int source_index, int dest_index, int count)
|
2006-08-28 03:12:36 +02:00
|
|
|
{
|
|
|
|
CustomData_copy_data(&source->vertData, &dest->vertData, source_index, dest_index, count);
|
|
|
|
}
|
|
|
|
|
2023-04-03 23:48:05 +02:00
|
|
|
void DM_interp_vert_data(const DerivedMesh *source,
|
2015-07-02 08:20:22 +02:00
|
|
|
DerivedMesh *dest,
|
|
|
|
int *src_indices,
|
|
|
|
float *weights,
|
|
|
|
int count,
|
|
|
|
int dest_index)
|
2006-08-28 03:12:36 +02:00
|
|
|
{
|
|
|
|
CustomData_interp(
|
2020-12-14 13:00:28 +01:00
|
|
|
&source->vertData, &dest->vertData, src_indices, weights, nullptr, count, dest_index);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
2012-12-21 08:28:14 +01:00
|
|
|
static float (*get_editbmesh_orco_verts(BMEditMesh *em))[3]
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
{
|
2009-05-16 18:18:08 +02:00
|
|
|
BMIter iter;
|
|
|
|
BMVert *eve;
|
2012-12-21 08:28:14 +01:00
|
|
|
float(*orco)[3];
|
|
|
|
int i;
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
|
|
|
|
/* these may not really be the orco's, but it's only for preview.
|
|
|
|
* could be solver better once, but isn't simple */
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2020-12-14 13:00:28 +01:00
|
|
|
orco = (float(*)[3])MEM_malloc_arrayN(em->bm->totvert, sizeof(float[3]), "BMEditMesh Orco");
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
|
2012-12-21 08:28:14 +01:00
|
|
|
BM_ITER_MESH_INDEX (eve, &iter, em->bm, BM_VERTS_OF_MESH, i) {
|
|
|
|
copy_v3_v3(orco[i], eve->co);
|
2011-11-06 16:39:20 +01:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
return orco;
|
|
|
|
}
|
|
|
|
|
2009-05-23 05:24:15 +02:00
|
|
|
/* orco custom data layer */
|
2018-10-09 06:04:51 +02:00
|
|
|
static float (*get_orco_coords(Object *ob, BMEditMesh *em, int layer, int *free))[3]
|
2010-03-30 13:49:07 +02:00
|
|
|
{
|
2012-05-12 21:18:02 +02:00
|
|
|
*free = 0;
|
2010-03-30 13:49:07 +02:00
|
|
|
|
2012-03-24 07:18:31 +01:00
|
|
|
if (layer == CD_ORCO) {
|
2010-03-30 13:49:07 +02:00
|
|
|
/* get original coordinates */
|
2012-05-12 21:18:02 +02:00
|
|
|
*free = 1;
|
2010-03-30 13:49:07 +02:00
|
|
|
|
2019-04-22 01:39:35 +02:00
|
|
|
if (em) {
|
2012-12-21 08:28:14 +01:00
|
|
|
return get_editbmesh_orco_verts(em);
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
2020-07-03 18:04:40 +02:00
|
|
|
return BKE_mesh_orco_verts_get(ob);
|
2010-03-30 13:49:07 +02:00
|
|
|
}
|
2020-07-03 18:04:40 +02:00
|
|
|
if (layer == CD_CLOTH_ORCO) {
|
2010-03-30 13:49:07 +02:00
|
|
|
/* apply shape key for cloth, this should really be solved
|
2012-03-09 19:28:30 +01:00
|
|
|
* by a more flexible customdata system, but not simple */
|
2012-03-24 07:18:31 +01:00
|
|
|
if (!em) {
|
2020-05-08 11:02:03 +02:00
|
|
|
ClothModifierData *clmd = (ClothModifierData *)BKE_modifiers_findby_type(
|
|
|
|
ob, eModifierType_Cloth);
|
2021-05-12 23:14:58 +02:00
|
|
|
if (clmd) {
|
|
|
|
KeyBlock *kb = BKE_keyblock_from_key(BKE_key_from_object(ob),
|
|
|
|
clmd->sim_parms->shapekey_rest);
|
2011-12-05 00:13:28 +01:00
|
|
|
|
2021-05-12 23:14:58 +02:00
|
|
|
if (kb && kb->data) {
|
|
|
|
return (float(*)[3])kb->data;
|
|
|
|
}
|
2015-04-13 07:54:37 +02:00
|
|
|
}
|
2010-03-30 13:49:07 +02:00
|
|
|
}
|
|
|
|
|
2020-12-14 13:00:28 +01:00
|
|
|
return nullptr;
|
2010-03-30 13:49:07 +02:00
|
|
|
}
|
|
|
|
|
2020-12-14 13:00:28 +01:00
|
|
|
return nullptr;
|
2010-03-30 13:49:07 +02:00
|
|
|
}
|
|
|
|
|
2018-05-11 09:53:52 +02:00
|
|
|
static Mesh *create_orco_mesh(Object *ob, Mesh *me, BMEditMesh *em, int layer)
|
|
|
|
{
|
|
|
|
Mesh *mesh;
|
|
|
|
float(*orco)[3];
|
|
|
|
int free;
|
|
|
|
|
|
|
|
if (em) {
|
2020-12-14 13:00:28 +01:00
|
|
|
mesh = BKE_mesh_from_bmesh_for_eval_nomain(em->bm, nullptr, me);
|
Mesh: Avoid creating incorrect original index layers
Currently, whenever any BMesh is converted to a Mesh (except for edit
mode switching), original index (`CD_ORIGINDEX`) layers are added.
This is incorrect, because many operations just convert some Mesh into
a BMesh and then back, but they shouldn't make any assumption about
where their input mesh came from. It might even come from a primitive
in geometry nodes, where there are no original indices at all.
Conceptually, mesh original indices should be filled by the modifier
stack when first creating the evaluated mesh. So that's where they're
moved in this patch. A separate function now fills the indices with their
default (0,1,2,3...) values. The way the mesh wrapper system defers
the BMesh to Mesh conversion makes this a bit less obvious though.
The old behavior is incorrect, but it's also slower, because three
arrays the size of the mesh's vertices, edges, and faces had to be
allocated and filled during the BMesh to Mesh conversion, which just
ends up putting more pressure on the cache. In the many cases where
original indices aren't used, I measured an **8% speedup** for the
conversion (from 76.5ms to 70.7ms).
Generally there is an assumption that BMesh is "original" and Mesh is
"evaluated". After this patch, that assumption isn't quite as strong,
but it still exists for two reasons. First, original indices are added
whenever converting a BMesh "wrapper" to a Mesh. Second, original
indices are not added to the BMesh at the beginning of evaluation,
which assumes that every BMesh in the viewport is original and doesn't
need the mapping.
Differential Revision: https://developer.blender.org/D14018
2022-02-18 17:51:00 +01:00
|
|
|
BKE_mesh_ensure_default_orig_index_customdata(mesh);
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
|
|
|
else {
|
2023-04-19 21:49:13 +02:00
|
|
|
mesh = BKE_mesh_copy_for_eval(me);
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
|
|
|
|
2018-10-09 06:04:51 +02:00
|
|
|
orco = get_orco_coords(ob, em, layer, &free);
|
2018-05-11 09:53:52 +02:00
|
|
|
|
|
|
|
if (orco) {
|
2019-08-21 22:28:35 +02:00
|
|
|
BKE_mesh_vert_coords_apply(mesh, orco);
|
2019-04-22 01:39:35 +02:00
|
|
|
if (free) {
|
2018-05-11 09:53:52 +02:00
|
|
|
MEM_freeN(orco);
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return mesh;
|
|
|
|
}
|
|
|
|
|
2023-08-22 03:51:53 +02:00
|
|
|
static MutableSpan<float3> orco_coord_layer_ensure(Mesh *mesh, const eCustomDataType layer)
|
|
|
|
{
|
|
|
|
void *data = CustomData_get_layer_for_write(&mesh->vert_data, layer, mesh->totvert);
|
|
|
|
if (!data) {
|
|
|
|
data = CustomData_add_layer(&mesh->vert_data, layer, CD_CONSTRUCT, mesh->totvert);
|
|
|
|
}
|
|
|
|
return MutableSpan(reinterpret_cast<float3 *>(data), mesh->totvert);
|
|
|
|
}
|
|
|
|
|
2023-03-29 17:10:49 +02:00
|
|
|
static void add_orco_mesh(
|
|
|
|
Object *ob, BMEditMesh *em, Mesh *mesh, Mesh *mesh_orco, const eCustomDataType layer)
|
2018-05-11 09:53:52 +02:00
|
|
|
{
|
2023-08-22 03:51:53 +02:00
|
|
|
const int totvert = mesh->totvert;
|
2018-05-11 09:53:52 +02:00
|
|
|
|
2023-08-22 03:51:53 +02:00
|
|
|
MutableSpan<float3> layer_orco;
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_orco) {
|
2023-08-22 03:51:53 +02:00
|
|
|
layer_orco = orco_coord_layer_ensure(mesh, layer);
|
2018-05-11 09:53:52 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_orco->totvert == totvert) {
|
2023-08-22 03:51:53 +02:00
|
|
|
layer_orco.copy_from(mesh_orco->vert_positions());
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
|
|
|
else {
|
2023-08-22 03:51:53 +02:00
|
|
|
layer_orco.copy_from(mesh->vert_positions());
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* TODO(sybren): totvert should potentially change here, as ob->data
|
|
|
|
* or em may have a different number of vertices than dm. */
|
2023-08-22 03:51:53 +02:00
|
|
|
int free = 0;
|
|
|
|
float(*orco)[3] = get_orco_coords(ob, em, layer, &free);
|
|
|
|
if (orco) {
|
|
|
|
layer_orco = orco_coord_layer_ensure(mesh, layer);
|
|
|
|
layer_orco.copy_from(Span<float3>(reinterpret_cast<float3 *>(orco), totvert));
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
2019-04-22 01:39:35 +02:00
|
|
|
if (free) {
|
2018-05-11 09:53:52 +02:00
|
|
|
MEM_freeN(orco);
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
2023-08-22 03:51:53 +02:00
|
|
|
|
|
|
|
if (!layer_orco.is_empty()) {
|
|
|
|
if (layer == CD_ORCO) {
|
|
|
|
BKE_mesh_orco_verts_transform(
|
2023-08-24 02:45:34 +02:00
|
|
|
(Mesh *)ob->data, reinterpret_cast<float(*)[3]>(layer_orco.data()), totvert, false);
|
2023-08-22 03:51:53 +02:00
|
|
|
}
|
|
|
|
}
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
|
|
|
|
2019-05-27 11:45:33 +02:00
|
|
|
/* Does final touches to the final evaluated mesh, making sure it is perfectly usable.
|
|
|
|
*
|
|
|
|
* This is needed because certain information is not passed along intermediate meshes allocated
|
|
|
|
* during stack evaluation.
|
|
|
|
*/
|
|
|
|
static void mesh_calc_finalize(const Mesh *mesh_input, Mesh *mesh_eval)
|
|
|
|
{
|
|
|
|
/* Make sure the name is the same. This is because mesh allocation from template does not
|
|
|
|
* take care of naming. */
|
2023-05-09 04:50:37 +02:00
|
|
|
STRNCPY(mesh_eval->id.name, mesh_input->id.name);
|
2019-05-27 11:45:33 +02:00
|
|
|
/* Make evaluated mesh to share same edit mesh pointer as original and copied meshes. */
|
|
|
|
mesh_eval->edit_mesh = mesh_input->edit_mesh;
|
|
|
|
}
|
|
|
|
|
Mesh: Replace auto smooth with node group
Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
2023-10-20 16:54:08 +02:00
|
|
|
void BKE_mesh_wrapper_deferred_finalize_mdata(Mesh *me_eval)
|
2020-05-25 12:16:42 +02:00
|
|
|
{
|
2022-10-13 03:55:26 +02:00
|
|
|
if (me_eval->runtime->wrapper_type_finalize & (1 << ME_WRAPPER_TYPE_BMESH)) {
|
Mesh: Replace auto smooth with node group
Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
2023-10-20 16:54:08 +02:00
|
|
|
editbmesh_calc_modifier_final_normals(me_eval);
|
2022-10-13 03:55:26 +02:00
|
|
|
me_eval->runtime->wrapper_type_finalize = eMeshWrapperType(
|
|
|
|
me_eval->runtime->wrapper_type_finalize & ~(1 << ME_WRAPPER_TYPE_BMESH));
|
2020-05-25 12:16:42 +02:00
|
|
|
}
|
2022-10-13 03:55:26 +02:00
|
|
|
BLI_assert(me_eval->runtime->wrapper_type_finalize == 0);
|
2020-05-25 12:16:42 +02:00
|
|
|
}
|
|
|
|
|
2020-12-15 12:42:10 +01:00
|
|
|
/**
|
2021-02-02 16:20:54 +01:00
|
|
|
* Modifies the given mesh and geometry set. The mesh is not passed as part of the mesh component
|
|
|
|
* in the \a geometry_set input, it is only passed in \a input_mesh and returned in the return
|
|
|
|
* value.
|
2020-12-15 12:42:10 +01:00
|
|
|
*
|
2021-02-02 16:20:54 +01:00
|
|
|
* The purpose of the geometry set is to store all geometry components that are generated
|
|
|
|
* by modifiers to allow outputting non-mesh data from modifiers.
|
2020-12-15 12:42:10 +01:00
|
|
|
*/
|
|
|
|
static Mesh *modifier_modify_mesh_and_geometry_set(ModifierData *md,
|
|
|
|
const ModifierEvalContext &mectx,
|
|
|
|
Mesh *input_mesh,
|
|
|
|
GeometrySet &geometry_set)
|
|
|
|
{
|
|
|
|
Mesh *mesh_output = nullptr;
|
|
|
|
const ModifierTypeInfo *mti = BKE_modifier_get_info((ModifierType)md->type);
|
2023-07-27 04:04:18 +02:00
|
|
|
if (mti->modify_geometry_set == nullptr) {
|
2021-10-19 15:39:10 +02:00
|
|
|
mesh_output = BKE_modifier_modify_mesh(md, &mectx, input_mesh);
|
2020-12-15 12:42:10 +01:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* For performance reasons, this should be called by the modifier and/or nodes themselves at
|
|
|
|
* some point. */
|
|
|
|
BKE_mesh_wrapper_ensure_mdata(input_mesh);
|
|
|
|
|
2021-02-02 16:20:54 +01:00
|
|
|
/* Replace only the mesh rather than the whole component, because the entire #MeshComponent
|
|
|
|
* might have been replaced by data from a different object in the node tree, which means the
|
|
|
|
* component contains vertex group name data for that object that should not be removed. */
|
2023-07-07 15:59:55 +02:00
|
|
|
geometry_set.replace_mesh(input_mesh, GeometryOwnershipType::Editable);
|
2020-12-15 12:42:10 +01:00
|
|
|
|
|
|
|
/* Let the modifier change the geometry set. */
|
2023-07-27 04:04:18 +02:00
|
|
|
mti->modify_geometry_set(md, &mectx, &geometry_set);
|
2020-12-15 12:42:10 +01:00
|
|
|
|
|
|
|
/* Release the mesh from the geometry set again. */
|
|
|
|
if (geometry_set.has<MeshComponent>()) {
|
|
|
|
MeshComponent &mesh_component = geometry_set.get_component_for_write<MeshComponent>();
|
2023-08-03 17:09:18 +02:00
|
|
|
if (mesh_component.get() != input_mesh) {
|
2021-11-03 10:42:48 +01:00
|
|
|
/* Make sure the mesh component actually owns the mesh before taking over ownership. */
|
|
|
|
mesh_component.ensure_owns_direct_data();
|
|
|
|
}
|
2020-12-15 12:42:10 +01:00
|
|
|
mesh_output = mesh_component.release();
|
|
|
|
}
|
2023-10-02 17:43:22 +02:00
|
|
|
/* Need to ensure that non-mesh data is also owned by the geometry set. Otherwise it might be
|
|
|
|
* freed while there is still a reference to it in the geometry. */
|
|
|
|
geometry_set.ensure_owns_direct_data();
|
2020-12-15 12:42:10 +01:00
|
|
|
|
2021-06-24 07:56:58 +02:00
|
|
|
/* Return an empty mesh instead of null. */
|
2020-12-15 12:42:10 +01:00
|
|
|
if (mesh_output == nullptr) {
|
2023-02-27 17:09:26 +01:00
|
|
|
mesh_output = BKE_mesh_new_nomain(0, 0, 0, 0);
|
2021-06-17 06:56:39 +02:00
|
|
|
BKE_mesh_copy_parameters_for_eval(mesh_output, input_mesh);
|
2020-12-15 12:42:10 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return mesh_output;
|
|
|
|
}
|
|
|
|
|
2023-04-20 20:18:02 +02:00
|
|
|
static void set_rest_position(Mesh &mesh)
|
|
|
|
{
|
|
|
|
using namespace blender;
|
|
|
|
using namespace blender::bke;
|
|
|
|
MutableAttributeAccessor attributes = mesh.attributes_for_write();
|
|
|
|
const AttributeReader positions = attributes.lookup<float3>("position");
|
|
|
|
attributes.remove("rest_position");
|
|
|
|
if (positions) {
|
|
|
|
if (positions.sharing_info && positions.varray.is_span()) {
|
|
|
|
attributes.add<float3>("rest_position",
|
|
|
|
ATTR_DOMAIN_POINT,
|
|
|
|
AttributeInitShared(positions.varray.get_internal_span().data(),
|
|
|
|
*positions.sharing_info));
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
attributes.add<float3>(
|
|
|
|
"rest_position", ATTR_DOMAIN_POINT, AttributeInitVArray(positions.varray));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-06-03 00:36:28 +02:00
|
|
|
static void mesh_calc_modifiers(Depsgraph *depsgraph,
|
2022-02-14 19:05:54 +01:00
|
|
|
const Scene *scene,
|
2019-03-27 19:07:16 +01:00
|
|
|
Object *ob,
|
2021-06-30 23:41:53 +02:00
|
|
|
const bool use_deform,
|
2019-03-27 19:07:16 +01:00
|
|
|
const bool need_mapping,
|
|
|
|
const CustomData_MeshMasks *dataMask,
|
2019-03-28 11:42:53 +01:00
|
|
|
const bool use_cache,
|
2019-05-31 10:05:56 +02:00
|
|
|
const bool allow_shared_mesh,
|
2015-07-02 08:20:22 +02:00
|
|
|
/* return args */
|
2019-03-27 19:07:16 +01:00
|
|
|
Mesh **r_deform,
|
2020-12-15 12:42:10 +01:00
|
|
|
Mesh **r_final,
|
|
|
|
GeometrySet **r_geometry_set)
|
2005-03-27 22:34:18 +02:00
|
|
|
{
|
2022-08-30 22:38:38 +02:00
|
|
|
using namespace blender::bke;
|
2023-02-06 20:34:16 +01:00
|
|
|
/* Input mesh shouldn't be modified. */
|
2020-12-14 13:00:28 +01:00
|
|
|
Mesh *mesh_input = (Mesh *)ob->data;
|
2023-02-06 20:34:16 +01:00
|
|
|
/* The final mesh is the result of calculating all enabled modifiers. */
|
2020-12-14 13:00:28 +01:00
|
|
|
Mesh *mesh_final = nullptr;
|
2023-02-06 20:34:16 +01:00
|
|
|
/* The result of calculating all leading deform modifiers. */
|
2020-12-14 13:00:28 +01:00
|
|
|
Mesh *mesh_deform = nullptr;
|
2020-12-15 12:42:10 +01:00
|
|
|
/* This geometry set contains the non-mesh data that might be generated by modifiers. */
|
|
|
|
GeometrySet geometry_set_final;
|
2021-02-02 16:20:54 +01:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
BLI_assert((mesh_input->id.tag & LIB_TAG_COPIED_ON_WRITE_EVAL_RESULT) == 0);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Mesh with constructive modifiers but no deformation applied. Tracked
|
|
|
|
* along with final mesh if undeformed / orco coordinates are requested
|
|
|
|
* for texturing. */
|
2020-12-14 13:00:28 +01:00
|
|
|
Mesh *mesh_orco = nullptr;
|
|
|
|
Mesh *mesh_orco_cloth = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Modifier evaluation modes. */
|
|
|
|
const bool use_render = (DEG_get_mode(depsgraph) == DAG_EVAL_RENDER);
|
|
|
|
const int required_mode = use_render ? eModifierMode_Render : eModifierMode_Realtime;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Sculpt can skip certain modifiers. */
|
2020-12-14 13:00:28 +01:00
|
|
|
const bool has_multires = BKE_sculpt_multires_active(scene, ob) != nullptr;
|
2014-01-27 17:52:21 +01:00
|
|
|
bool multires_applied = false;
|
2019-03-28 11:42:53 +01:00
|
|
|
const bool sculpt_mode = ob->mode & OB_MODE_SCULPT && ob->sculpt && !use_render;
|
|
|
|
const bool sculpt_dyntopo = (sculpt_mode && ob->sculpt->bm) && !use_render;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Modifier evaluation contexts for different types of modifiers. */
|
2023-05-26 22:11:54 +02:00
|
|
|
ModifierApplyFlag apply_render = use_render ? MOD_APPLY_RENDER : ModifierApplyFlag(0);
|
|
|
|
ModifierApplyFlag apply_cache = use_cache ? MOD_APPLY_USECACHE : ModifierApplyFlag(0);
|
|
|
|
const ModifierEvalContext mectx = {depsgraph, ob, apply_render | apply_cache};
|
|
|
|
const ModifierEvalContext mectx_orco = {depsgraph, ob, apply_render | MOD_APPLY_ORCO};
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Get effective list of modifiers to execute. Some effects like shape keys
|
|
|
|
* are added as virtual modifiers before the user created modifiers. */
|
2023-07-27 04:04:18 +02:00
|
|
|
VirtualModifierData virtual_modifier_data;
|
|
|
|
ModifierData *firstmd = BKE_modifiers_get_virtual_modifierlist(ob, &virtual_modifier_data);
|
2019-03-28 11:42:53 +01:00
|
|
|
ModifierData *md = firstmd;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Preview colors by modifiers such as dynamic paint, to show the results
|
|
|
|
* even if the resulting data is not used in a material. Only in object mode.
|
|
|
|
* TODO: this is broken, not drawn by the drawn manager. */
|
|
|
|
const bool do_mod_mcol = (ob->mode == OB_MODE_OBJECT);
|
2020-12-14 13:00:28 +01:00
|
|
|
ModifierData *previewmd = nullptr;
|
2019-03-28 11:42:53 +01:00
|
|
|
CustomData_MeshMasks previewmask = {0};
|
2018-09-30 17:07:38 +02:00
|
|
|
if (do_mod_mcol) {
|
2020-12-14 13:00:28 +01:00
|
|
|
/* Find the last active modifier generating a preview, or nullptr if none. */
|
Add weight preview to WeightVG modifiers, and first, simple/basic refactor of how modifiers can generate preview.
User side:
* Preview for DynamicPaint should keep the same behavior (for now). Weight preview should be somawhat quicker, though.
* Preview for WeightVG modifiers is only active in WeightPaint mode, and if the affected vgroup is the active one.
* Last active preview modifier in stack wins!
Note: that modifier preview topic is yet to be further refined, quite raw/incomplete for now.
Dev side:
* In draw code, renamed DRAW_DYNAMIC_PAINT_PREVIEW flag to DRAW_MODIFIERS_PREVIEW
* Removed use of MOD_DPAINT_PREVIEW_READY in DynamicPaint code (seems unecessary, and if it was, should be of more general scope).
* Added eModifierTypeFlag_UsesPreview to ModifierTypeFlag, for modifiers that can generate some preview data.
* Added three new modifier funcs, to handle preview modifiers in draw code / mod stack.
* For weights preview: added the generic DM_update_weight_mcol func, which can update WEIGHT_MCOL layer with either a given array of weights (currently used by DynamicPaint only), or from current active vgroup(s).
So now, draw code is fully generic (i.e. no more modifier-type checking in it). Mod stack code is generic to some extent, but will need more work.
2012-01-22 18:54:23 +01:00
|
|
|
/* XXX Currently, DPaint modifier just ignores this.
|
|
|
|
* Needs a stupid hack...
|
|
|
|
* The whole "modifier preview" thing has to be (re?)designed, anyway! */
|
2020-05-08 10:14:02 +02:00
|
|
|
previewmd = BKE_modifier_get_last_preview(scene, md, required_mode);
|
Add weight preview to WeightVG modifiers, and first, simple/basic refactor of how modifiers can generate preview.
User side:
* Preview for DynamicPaint should keep the same behavior (for now). Weight preview should be somawhat quicker, though.
* Preview for WeightVG modifiers is only active in WeightPaint mode, and if the affected vgroup is the active one.
* Last active preview modifier in stack wins!
Note: that modifier preview topic is yet to be further refined, quite raw/incomplete for now.
Dev side:
* In draw code, renamed DRAW_DYNAMIC_PAINT_PREVIEW flag to DRAW_MODIFIERS_PREVIEW
* Removed use of MOD_DPAINT_PREVIEW_READY in DynamicPaint code (seems unecessary, and if it was, should be of more general scope).
* Added eModifierTypeFlag_UsesPreview to ModifierTypeFlag, for modifiers that can generate some preview data.
* Added three new modifier funcs, to handle preview modifiers in draw code / mod stack.
* For weights preview: added the generic DM_update_weight_mcol func, which can update WEIGHT_MCOL layer with either a given array of weights (currently used by DynamicPaint only), or from current active vgroup(s).
So now, draw code is fully generic (i.e. no more modifier-type checking in it). Mod stack code is generic to some extent, but will need more work.
2012-01-22 18:54:23 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Compute accumulated datamasks needed by each modifier. It helps to do
|
|
|
|
* this fine grained so that for example vertex groups are preserved up to
|
|
|
|
* an armature modifier, but not through a following subsurf modifier where
|
|
|
|
* subdividing them is expensive. */
|
2019-06-10 15:42:15 +02:00
|
|
|
CustomData_MeshMasks final_datamask = *dataMask;
|
2020-05-08 10:14:02 +02:00
|
|
|
CDMaskLink *datamasks = BKE_modifier_calc_data_masks(
|
2022-09-14 21:49:40 +02:00
|
|
|
scene, md, &final_datamask, required_mode, previewmd, &previewmask);
|
2019-03-28 11:42:53 +01:00
|
|
|
CDMaskLink *md_datamask = datamasks;
|
|
|
|
/* XXX Always copying POLYINDEX, else tessellated data are no more valid! */
|
|
|
|
CustomData_MeshMasks append_mask = CD_MASK_BAREMESH_ORIGINDEX;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Clear errors before evaluation. */
|
2020-05-08 10:14:02 +02:00
|
|
|
BKE_modifiers_clear_errors(ob);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-07-08 14:45:48 +02:00
|
|
|
if (ob->modifier_flag & OB_MODIFIER_FLAG_ADD_REST_POSITION) {
|
|
|
|
if (mesh_final == nullptr) {
|
2023-04-19 21:49:13 +02:00
|
|
|
mesh_final = BKE_mesh_copy_for_eval(mesh_input);
|
2022-07-08 14:45:48 +02:00
|
|
|
ASSERT_IS_VALID_MESH(mesh_final);
|
|
|
|
}
|
2023-04-20 20:18:02 +02:00
|
|
|
set_rest_position(*mesh_final);
|
2022-07-08 14:45:48 +02:00
|
|
|
}
|
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Apply all leading deform modifiers. */
|
2021-06-30 23:41:53 +02:00
|
|
|
if (use_deform) {
|
2019-03-28 11:42:53 +01:00
|
|
|
for (; md; md = md->next, md_datamask = md_datamask->next) {
|
2020-12-14 13:00:28 +01:00
|
|
|
const ModifierTypeInfo *mti = BKE_modifier_get_info((ModifierType)md->type);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-05-08 10:14:02 +02:00
|
|
|
if (!BKE_modifier_is_enabled(scene, md, required_mode)) {
|
2015-07-02 08:20:22 +02:00
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-11-14 10:03:56 +01:00
|
|
|
if (mti->type == ModifierTypeType::OnlyDeform && !sculpt_dyntopo) {
|
Modifiers: measure execution time and provide Python access
The goal is to give technical artists the ability to optimize modifier usage
and/or geometry node groups for performance. In the long term, it
would be useful if Blender could provide its own UI to display profiling
information to users. However, right now, there are too many open
design questions making it infeasible to tackle this in the short term.
This commit uses a simpler approach: Instead of adding new ui for
profiling data, it exposes the execution-time of modifiers in the Python
API. This allows technical artists to access the information and to build
their own UI to display the relevant information. In the long term this
will hopefully also help us to integrate a native ui for this in Blender
by observing how users use this information.
Note: The execution time of a modifier highly depends on what other
things the CPU is doing at the same time. For example, in many more
complex files, many objects and therefore modifiers are evaluated at
the same time by multiple threads which makes the measurement
much less reliable. For best results, make sure that only one object
is evaluated at a time (e.g. by changing it in isolation) and that no
other process on the system keeps the CPU busy.
As shown below, the execution time has to be accessed on the
evaluated object, not the original object.
```lang=python
import bpy
depsgraph = bpy.context.view_layer.depsgraph
ob = bpy.context.active_object
ob_eval = ob.evaluated_get(depsgraph)
modifier_eval = ob_eval.modifiers[0]
print(modifier_eval.execution_time, "s")
```
Differential Revision: https://developer.blender.org/D17185
2023-02-06 15:39:59 +01:00
|
|
|
blender::bke::ScopedModifierTimer modifier_timer{*md};
|
2023-02-06 20:34:16 +01:00
|
|
|
if (!mesh_final) {
|
2023-04-19 21:49:13 +02:00
|
|
|
mesh_final = BKE_mesh_copy_for_eval(mesh_input);
|
2023-02-06 20:34:16 +01:00
|
|
|
ASSERT_IS_VALID_MESH(mesh_final);
|
2019-03-18 15:37:46 +01:00
|
|
|
}
|
2023-10-13 20:35:16 +02:00
|
|
|
|
|
|
|
if (mti->required_data_mask) {
|
|
|
|
CustomData_MeshMasks mask{};
|
|
|
|
mti->required_data_mask(md, &mask);
|
|
|
|
if (mask.vmask & CD_MASK_ORCO) {
|
|
|
|
add_orco_mesh(ob, nullptr, mesh_final, nullptr, CD_ORCO);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-11-14 10:54:57 +01:00
|
|
|
BKE_modifier_deform_verts(md, &mectx, mesh_final, mesh_final->vert_positions_for_write());
|
2012-03-24 07:18:31 +01:00
|
|
|
}
|
|
|
|
else {
|
2005-07-19 22:14:17 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
/* Result of all leading deforming modifiers is cached for
|
|
|
|
* places that wish to use the original mesh but with deformed
|
2019-03-28 11:42:53 +01:00
|
|
|
* coordinates (like vertex paint). */
|
2018-10-10 06:00:37 +02:00
|
|
|
if (r_deform) {
|
2023-04-19 21:49:13 +02:00
|
|
|
mesh_deform = BKE_mesh_copy_for_eval(mesh_final ? mesh_final : mesh_input);
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2006-09-07 08:44:25 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Apply all remaining constructive and deforming modifiers. */
|
2023-07-17 11:40:08 +02:00
|
|
|
bool have_non_onlydeform_modifiers_applied = false;
|
2019-03-28 11:42:53 +01:00
|
|
|
for (; md; md = md->next, md_datamask = md_datamask->next) {
|
2020-12-14 13:00:28 +01:00
|
|
|
const ModifierTypeInfo *mti = BKE_modifier_get_info((ModifierType)md->type);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-05-08 10:14:02 +02:00
|
|
|
if (!BKE_modifier_is_enabled(scene, md, required_mode)) {
|
2015-07-02 08:20:22 +02:00
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-11-14 10:03:56 +01:00
|
|
|
if (mti->type == ModifierTypeType::OnlyDeform && !use_deform) {
|
2015-07-02 08:20:22 +02:00
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-11-13 11:29:19 +01:00
|
|
|
if ((mti->flags & eModifierTypeFlag_RequiresOriginalData) &&
|
2023-07-17 11:40:08 +02:00
|
|
|
have_non_onlydeform_modifiers_applied) {
|
2020-10-26 07:07:58 +01:00
|
|
|
BKE_modifier_set_error(ob, md, "Modifier requires original data, bad stack position");
|
- added eModifierTypeFlag_RequiresOriginalData for modifiers that
can only follow deform (for example, they store mesh vertex
indices)
- added ModifierType.foreachObjectLink for iterating over Object
links inside modifier data (used for file load, relinking, etc)
- switched various modifiers_ functions to take object argument
instead of ListBase
- added user editable name field to modifiers
- bug fix, duplicate and make single user didn't relink object
pointers in modifier data
- added modifiers to outliner, needs icon
- added armature, hook, and softbody modifiers (softbody doesn't
do anything atm). added conversion of old hooks to modifiers.
NOTE-THE-FIRST: User name field is not initialized on loading 2.38 files
so if you have saved stuff with a cvs blender you will see blank names.
NOTE-THE-SECOND: Since modifiers aren't evaluated yet for non-Mesh
objects, hooks for lattices and curves are broken. Don't updated if
you actually, say, *use* Blender.
NOTE-THE-THIRD: Old hooks used a quirky weighting system during
deformation which can't be extended to modifiers. On the upside,
I doubt anyone relied on the old quirky system and the new system
makes much more sense. (Although the way falloff works is still
quite stupid I think).
2005-08-11 00:05:52 +02:00
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-05-09 10:29:21 +02:00
|
|
|
if (sculpt_mode && (!has_multires || multires_applied || sculpt_dyntopo)) {
|
2014-01-27 17:52:21 +01:00
|
|
|
bool unsupported = false;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-04-30 15:41:45 +02:00
|
|
|
if (md->type == eModifierType_Multires && ((MultiresModifierData *)md)->sculptlvl == 0) {
|
2013-06-03 10:26:12 +02:00
|
|
|
/* If multires is on level 0 skip it silently without warning message. */
|
2015-07-02 08:20:22 +02:00
|
|
|
if (!sculpt_dyntopo) {
|
2014-05-08 18:25:46 +02:00
|
|
|
continue;
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2015-07-02 08:20:22 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 01:39:35 +02:00
|
|
|
if (sculpt_dyntopo) {
|
2014-01-27 17:52:21 +01:00
|
|
|
unsupported = true;
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 01:39:35 +02:00
|
|
|
if (scene->toolsettings->sculpt->flags & SCULPT_ONLY_DEFORM) {
|
2023-11-14 10:03:56 +01:00
|
|
|
unsupported |= (mti->type != ModifierTypeType::OnlyDeform);
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-05-12 21:18:02 +02:00
|
|
|
unsupported |= multires_applied;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-24 07:18:31 +01:00
|
|
|
if (unsupported) {
|
2019-04-22 01:39:35 +02:00
|
|
|
if (sculpt_dyntopo) {
|
2020-10-26 07:07:58 +01:00
|
|
|
BKE_modifier_set_error(ob, md, "Not supported in dyntopo");
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
|
|
|
else {
|
2020-10-26 07:07:58 +01:00
|
|
|
BKE_modifier_set_error(ob, md, "Not supported in sculpt mode");
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
2011-01-31 21:02:51 +01:00
|
|
|
continue;
|
|
|
|
}
|
2014-05-08 18:15:36 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-05-08 10:14:02 +02:00
|
|
|
if (need_mapping && !BKE_modifier_supports_mapping(md)) {
|
2015-07-02 08:20:22 +02:00
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Modifiers: measure execution time and provide Python access
The goal is to give technical artists the ability to optimize modifier usage
and/or geometry node groups for performance. In the long term, it
would be useful if Blender could provide its own UI to display profiling
information to users. However, right now, there are too many open
design questions making it infeasible to tackle this in the short term.
This commit uses a simpler approach: Instead of adding new ui for
profiling data, it exposes the execution-time of modifiers in the Python
API. This allows technical artists to access the information and to build
their own UI to display the relevant information. In the long term this
will hopefully also help us to integrate a native ui for this in Blender
by observing how users use this information.
Note: The execution time of a modifier highly depends on what other
things the CPU is doing at the same time. For example, in many more
complex files, many objects and therefore modifiers are evaluated at
the same time by multiple threads which makes the measurement
much less reliable. For best results, make sure that only one object
is evaluated at a time (e.g. by changing it in isolation) and that no
other process on the system keeps the CPU busy.
As shown below, the execution time has to be accessed on the
evaluated object, not the original object.
```lang=python
import bpy
depsgraph = bpy.context.view_layer.depsgraph
ob = bpy.context.active_object
ob_eval = ob.evaluated_get(depsgraph)
modifier_eval = ob_eval.modifiers[0]
print(modifier_eval.execution_time, "s")
```
Differential Revision: https://developer.blender.org/D17185
2023-02-06 15:39:59 +01:00
|
|
|
blender::bke::ScopedModifierTimer modifier_timer{*md};
|
|
|
|
|
2019-06-10 15:42:15 +02:00
|
|
|
/* Add orco mesh as layer if needed by this modifier. */
|
2023-07-27 04:04:18 +02:00
|
|
|
if (mesh_final && mesh_orco && mti->required_data_mask) {
|
2019-03-28 11:42:53 +01:00
|
|
|
CustomData_MeshMasks mask = {0};
|
2023-07-27 04:04:18 +02:00
|
|
|
mti->required_data_mask(md, &mask);
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mask.vmask & CD_MASK_ORCO) {
|
2020-12-14 13:00:28 +01:00
|
|
|
add_orco_mesh(ob, nullptr, mesh_final, mesh_orco, CD_ORCO);
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2019-03-28 11:42:53 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-11-14 10:03:56 +01:00
|
|
|
if (mti->type == ModifierTypeType::OnlyDeform) {
|
2023-02-06 20:34:16 +01:00
|
|
|
if (!mesh_final) {
|
2023-04-19 21:49:13 +02:00
|
|
|
mesh_final = BKE_mesh_copy_for_eval(mesh_input);
|
2023-02-06 20:34:16 +01:00
|
|
|
ASSERT_IS_VALID_MESH(mesh_final);
|
2010-09-30 12:51:36 +02:00
|
|
|
}
|
2023-11-14 10:54:57 +01:00
|
|
|
BKE_modifier_deform_verts(md, &mectx, mesh_final, mesh_final->vert_positions_for_write());
|
2012-03-24 07:18:31 +01:00
|
|
|
}
|
|
|
|
else {
|
2020-09-23 07:09:53 +02:00
|
|
|
bool check_for_needs_mapping = false;
|
2020-12-14 13:00:28 +01:00
|
|
|
if (mesh_final != nullptr) {
|
2023-07-17 11:40:08 +02:00
|
|
|
if (have_non_onlydeform_modifiers_applied == false) {
|
2020-09-23 07:12:28 +02:00
|
|
|
/* If we only deformed, we won't have initialized #CD_ORIGINDEX.
|
|
|
|
* as this is the only part of the function that initializes mapping. */
|
|
|
|
check_for_needs_mapping = true;
|
|
|
|
}
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
2012-03-24 07:18:31 +01:00
|
|
|
else {
|
2023-04-19 21:49:13 +02:00
|
|
|
mesh_final = BKE_mesh_copy_for_eval(mesh_input);
|
2019-03-28 11:42:53 +01:00
|
|
|
ASSERT_IS_VALID_MESH(mesh_final);
|
2020-09-23 07:09:53 +02:00
|
|
|
check_for_needs_mapping = true;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 11:40:08 +02:00
|
|
|
have_non_onlydeform_modifiers_applied = true;
|
2020-09-23 07:09:53 +02:00
|
|
|
|
|
|
|
/* determine which data layers are needed by following modifiers */
|
|
|
|
CustomData_MeshMasks nextmask = md_datamask->next ? md_datamask->next->mask : final_datamask;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-09-23 07:09:53 +02:00
|
|
|
if (check_for_needs_mapping) {
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Initialize original indices the first time we evaluate a
|
|
|
|
* constructive modifier. Modifiers will then do mapping mostly
|
|
|
|
* automatic by copying them through CustomData_copy_data along
|
|
|
|
* with other data.
|
2010-10-21 03:08:12 +02:00
|
|
|
*
|
2019-03-28 11:42:53 +01:00
|
|
|
* These are created when either requested by evaluation, or if
|
|
|
|
* following modifiers requested them. */
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
if (need_mapping ||
|
|
|
|
((nextmask.vmask | nextmask.emask | nextmask.pmask) & CD_MASK_ORIGINDEX)) {
|
2010-10-21 03:08:12 +02:00
|
|
|
/* calc */
|
2019-03-28 11:42:53 +01:00
|
|
|
CustomData_add_layer(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh_final->vert_data, CD_ORIGINDEX, CD_CONSTRUCT, mesh_final->totvert);
|
2019-03-28 11:42:53 +01:00
|
|
|
CustomData_add_layer(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh_final->edge_data, CD_ORIGINDEX, CD_CONSTRUCT, mesh_final->totedge);
|
2019-03-28 11:42:53 +01:00
|
|
|
CustomData_add_layer(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh_final->face_data, CD_ORIGINDEX, CD_CONSTRUCT, mesh_final->faces_num);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-27 04:07:07 +02:00
|
|
|
/* Not worth parallelizing this,
|
|
|
|
* gives less than 0.1% overall speedup in best of best cases... */
|
2023-01-14 00:21:20 +01:00
|
|
|
range_vn_i((int *)CustomData_get_layer_for_write(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh_final->vert_data, CD_ORIGINDEX, mesh_final->totvert),
|
2020-12-14 13:00:28 +01:00
|
|
|
mesh_final->totvert,
|
|
|
|
0);
|
2023-01-14 00:21:20 +01:00
|
|
|
range_vn_i((int *)CustomData_get_layer_for_write(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh_final->edge_data, CD_ORIGINDEX, mesh_final->totedge),
|
2020-12-14 13:00:28 +01:00
|
|
|
mesh_final->totedge,
|
|
|
|
0);
|
2023-01-14 00:21:20 +01:00
|
|
|
range_vn_i((int *)CustomData_get_layer_for_write(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh_final->face_data, CD_ORIGINDEX, mesh_final->faces_num),
|
2023-07-24 22:06:55 +02:00
|
|
|
mesh_final->faces_num,
|
2020-12-14 13:00:28 +01:00
|
|
|
0);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
2018-05-11 09:53:52 +02:00
|
|
|
/* set the Mesh to only copy needed data */
|
2019-03-28 11:42:53 +01:00
|
|
|
CustomData_MeshMasks mask = md_datamask->mask;
|
2023-02-12 04:37:16 +01:00
|
|
|
/* needMapping check here fixes bug #28112, otherwise it's
|
2016-01-28 06:30:50 +01:00
|
|
|
* possible that it won't be copied */
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
CustomData_MeshMasks_update(&mask, &append_mask);
|
|
|
|
if (need_mapping) {
|
|
|
|
mask.vmask |= CD_MASK_ORIGINDEX;
|
|
|
|
mask.emask |= CD_MASK_ORIGINDEX;
|
|
|
|
mask.pmask |= CD_MASK_ORIGINDEX;
|
|
|
|
}
|
2019-03-28 11:42:53 +01:00
|
|
|
mesh_set_only_copy(mesh_final, &mask);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-01-28 06:30:50 +01:00
|
|
|
/* add cloth rest shape key if needed */
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
if (mask.vmask & CD_MASK_CLOTH_ORCO) {
|
2020-12-14 13:00:28 +01:00
|
|
|
add_orco_mesh(ob, nullptr, mesh_final, mesh_orco, CD_CLOTH_ORCO);
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2007-12-05 13:40:54 +01:00
|
|
|
/* add an origspace layer if needed */
|
2019-03-28 11:42:53 +01:00
|
|
|
if ((md_datamask->mask.lmask) & CD_MASK_ORIGSPACE_MLOOP) {
|
2023-07-25 21:15:52 +02:00
|
|
|
if (!CustomData_has_layer(&mesh_final->loop_data, CD_ORIGSPACE_MLOOP)) {
|
2023-03-14 15:30:26 +01:00
|
|
|
CustomData_add_layer(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh_final->loop_data, CD_ORIGSPACE_MLOOP, CD_SET_DEFAULT, mesh_final->totloop);
|
2019-03-28 11:42:53 +01:00
|
|
|
mesh_init_origspace(mesh_final);
|
2012-02-05 12:30:26 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
2020-12-15 12:42:10 +01:00
|
|
|
Mesh *mesh_next = modifier_modify_mesh_and_geometry_set(
|
2021-02-02 16:20:54 +01:00
|
|
|
md, mectx, mesh_final, geometry_set_final);
|
2019-03-28 11:42:53 +01:00
|
|
|
ASSERT_IS_VALID_MESH(mesh_next);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_next) {
|
2018-05-11 09:53:52 +02:00
|
|
|
/* if the modifier returned a new mesh, release the old one */
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_final != mesh_next) {
|
|
|
|
BLI_assert(mesh_final != mesh_input);
|
2020-12-14 13:00:28 +01:00
|
|
|
BKE_id_free(nullptr, mesh_final);
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
2019-03-28 11:42:53 +01:00
|
|
|
mesh_final = mesh_next;
|
2012-04-01 17:02:19 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-11 09:53:52 +02:00
|
|
|
/* create an orco mesh in parallel */
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
if (nextmask.vmask & CD_MASK_ORCO) {
|
2019-03-28 11:42:53 +01:00
|
|
|
if (!mesh_orco) {
|
2020-12-14 13:00:28 +01:00
|
|
|
mesh_orco = create_orco_mesh(ob, mesh_input, nullptr, CD_ORCO);
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
nextmask.vmask &= ~CD_MASK_ORCO;
|
2020-12-14 13:00:28 +01:00
|
|
|
CustomData_MeshMasks temp_cddata_masks = {0};
|
|
|
|
temp_cddata_masks.vmask = CD_MASK_ORIGINDEX;
|
|
|
|
temp_cddata_masks.emask = CD_MASK_ORIGINDEX;
|
|
|
|
temp_cddata_masks.fmask = CD_MASK_ORIGINDEX;
|
|
|
|
temp_cddata_masks.pmask = CD_MASK_ORIGINDEX;
|
|
|
|
|
2023-07-27 04:04:18 +02:00
|
|
|
if (mti->required_data_mask != nullptr) {
|
|
|
|
mti->required_data_mask(md, &temp_cddata_masks);
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
}
|
|
|
|
CustomData_MeshMasks_update(&temp_cddata_masks, &nextmask);
|
2019-03-28 11:42:53 +01:00
|
|
|
mesh_set_only_copy(mesh_orco, &temp_cddata_masks);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-05-08 10:14:02 +02:00
|
|
|
mesh_next = BKE_modifier_modify_mesh(md, &mectx_orco, mesh_orco);
|
2019-03-28 11:42:53 +01:00
|
|
|
ASSERT_IS_VALID_MESH(mesh_next);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_next) {
|
2018-05-11 09:53:52 +02:00
|
|
|
/* if the modifier returned a new mesh, release the old one */
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_orco != mesh_next) {
|
|
|
|
BLI_assert(mesh_orco != mesh_input);
|
2020-12-14 13:00:28 +01:00
|
|
|
BKE_id_free(nullptr, mesh_orco);
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
mesh_orco = mesh_next;
|
2010-03-30 13:49:07 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
2018-05-11 09:53:52 +02:00
|
|
|
/* create cloth orco mesh in parallel */
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
if (nextmask.vmask & CD_MASK_CLOTH_ORCO) {
|
2019-03-28 11:42:53 +01:00
|
|
|
if (!mesh_orco_cloth) {
|
2020-12-14 13:00:28 +01:00
|
|
|
mesh_orco_cloth = create_orco_mesh(ob, mesh_input, nullptr, CD_CLOTH_ORCO);
|
2018-05-16 17:35:54 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
nextmask.vmask &= ~CD_MASK_CLOTH_ORCO;
|
|
|
|
nextmask.vmask |= CD_MASK_ORIGINDEX;
|
|
|
|
nextmask.emask |= CD_MASK_ORIGINDEX;
|
|
|
|
nextmask.pmask |= CD_MASK_ORIGINDEX;
|
2019-03-28 11:42:53 +01:00
|
|
|
mesh_set_only_copy(mesh_orco_cloth, &nextmask);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-05-08 10:14:02 +02:00
|
|
|
mesh_next = BKE_modifier_modify_mesh(md, &mectx_orco, mesh_orco_cloth);
|
2019-03-28 11:42:53 +01:00
|
|
|
ASSERT_IS_VALID_MESH(mesh_next);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_next) {
|
2018-05-11 09:53:52 +02:00
|
|
|
/* if the modifier returned a new mesh, release the old one */
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_orco_cloth != mesh_next) {
|
|
|
|
BLI_assert(mesh_orco != mesh_input);
|
2020-12-14 13:00:28 +01:00
|
|
|
BKE_id_free(nullptr, mesh_orco_cloth);
|
2015-07-02 08:20:22 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
mesh_orco_cloth = mesh_next;
|
2010-03-30 13:49:07 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
2011-07-08 13:03:37 +02:00
|
|
|
/* in case of dynamic paint, make sure preview mask remains for following modifiers */
|
Add weight preview to WeightVG modifiers, and first, simple/basic refactor of how modifiers can generate preview.
User side:
* Preview for DynamicPaint should keep the same behavior (for now). Weight preview should be somawhat quicker, though.
* Preview for WeightVG modifiers is only active in WeightPaint mode, and if the affected vgroup is the active one.
* Last active preview modifier in stack wins!
Note: that modifier preview topic is yet to be further refined, quite raw/incomplete for now.
Dev side:
* In draw code, renamed DRAW_DYNAMIC_PAINT_PREVIEW flag to DRAW_MODIFIERS_PREVIEW
* Removed use of MOD_DPAINT_PREVIEW_READY in DynamicPaint code (seems unecessary, and if it was, should be of more general scope).
* Added eModifierTypeFlag_UsesPreview to ModifierTypeFlag, for modifiers that can generate some preview data.
* Added three new modifier funcs, to handle preview modifiers in draw code / mod stack.
* For weights preview: added the generic DM_update_weight_mcol func, which can update WEIGHT_MCOL layer with either a given array of weights (currently used by DynamicPaint only), or from current active vgroup(s).
So now, draw code is fully generic (i.e. no more modifier-type checking in it). Mod stack code is generic to some extent, but will need more work.
2012-01-22 18:54:23 +01:00
|
|
|
/* XXX Temp and hackish solution! */
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
if (md->type == eModifierType_DynamicPaint) {
|
|
|
|
append_mask.lmask |= CD_MASK_PREVIEW_MLOOPCOL;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-10-13 03:55:26 +02:00
|
|
|
mesh_final->runtime->deformed_only = false;
|
2005-07-19 22:14:17 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-01-27 17:52:21 +01:00
|
|
|
if (sculpt_mode && md->type == eModifierType_Multires) {
|
|
|
|
multires_applied = true;
|
|
|
|
}
|
2005-07-19 22:14:17 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-12-14 13:00:28 +01:00
|
|
|
BLI_linklist_free((LinkNode *)datamasks, nullptr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 01:39:35 +02:00
|
|
|
for (md = firstmd; md; md = md->next) {
|
2020-05-08 10:14:02 +02:00
|
|
|
BKE_modifier_free_temporary_data(md);
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-12-14 13:00:28 +01:00
|
|
|
if (mesh_final == nullptr) {
|
2023-02-06 20:34:16 +01:00
|
|
|
if (allow_shared_mesh) {
|
2019-05-27 11:45:33 +02:00
|
|
|
mesh_final = mesh_input;
|
|
|
|
}
|
|
|
|
else {
|
2023-04-19 21:49:13 +02:00
|
|
|
mesh_final = BKE_mesh_copy_for_eval(mesh_input);
|
2019-05-27 11:45:33 +02:00
|
|
|
}
|
2012-03-24 07:18:31 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-05-27 11:45:33 +02:00
|
|
|
/* Denotes whether the object which the modifier stack came from owns the mesh or whether the
|
|
|
|
* mesh is shared across multiple objects since there are no effective modifiers. */
|
|
|
|
const bool is_own_mesh = (mesh_final != mesh_input);
|
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Add orco coordinates to final and deformed mesh if requested. */
|
2019-06-10 15:42:15 +02:00
|
|
|
if (final_datamask.vmask & CD_MASK_ORCO) {
|
2019-05-27 11:45:33 +02:00
|
|
|
/* No need in ORCO layer if the mesh was not deformed or modified: undeformed mesh in this case
|
|
|
|
* matches input mesh. */
|
|
|
|
if (is_own_mesh) {
|
2020-12-14 13:00:28 +01:00
|
|
|
add_orco_mesh(ob, nullptr, mesh_final, mesh_orco, CD_ORCO);
|
2019-05-27 11:45:33 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 01:39:35 +02:00
|
|
|
if (mesh_deform) {
|
2020-12-14 13:00:28 +01:00
|
|
|
add_orco_mesh(ob, nullptr, mesh_deform, nullptr, CD_ORCO);
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
2008-01-09 15:40:25 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_orco) {
|
2020-12-14 13:00:28 +01:00
|
|
|
BKE_id_free(nullptr, mesh_orco);
|
2014-04-13 12:18:51 +02:00
|
|
|
}
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_orco_cloth) {
|
2020-12-14 13:00:28 +01:00
|
|
|
BKE_id_free(nullptr, mesh_orco_cloth);
|
2012-02-06 07:56:54 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-14 16:33:52 +01:00
|
|
|
/* Remove temporary data layer only needed for modifier evaluation.
|
|
|
|
* Save some memory, and ensure GPU subdivision does not need to deal with this. */
|
2023-07-25 21:15:52 +02:00
|
|
|
CustomData_free_layers(&mesh_final->vert_data, CD_CLOTH_ORCO, mesh_final->totvert);
|
2021-01-14 16:33:52 +01:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Compute normals. */
|
2019-05-27 11:45:33 +02:00
|
|
|
if (is_own_mesh) {
|
2022-04-06 20:02:04 +02:00
|
|
|
mesh_calc_finalize(mesh_input, mesh_final);
|
2019-05-27 11:45:33 +02:00
|
|
|
}
|
|
|
|
else {
|
2022-10-13 03:55:26 +02:00
|
|
|
blender::bke::MeshRuntime *runtime = mesh_input->runtime;
|
2020-12-14 13:00:28 +01:00
|
|
|
if (runtime->mesh_eval == nullptr) {
|
2022-10-13 05:31:02 +02:00
|
|
|
std::lock_guard lock{mesh_input->runtime->eval_mutex};
|
2020-12-14 13:00:28 +01:00
|
|
|
if (runtime->mesh_eval == nullptr) {
|
2022-04-06 20:29:28 +02:00
|
|
|
/* Not yet finalized by any instance, do it now
|
|
|
|
* Isolate since computing normals is multithreaded and we are holding a lock. */
|
2021-06-21 18:44:40 +02:00
|
|
|
blender::threading::isolate_task([&] {
|
2023-04-19 21:49:13 +02:00
|
|
|
mesh_final = BKE_mesh_copy_for_eval(mesh_input);
|
2021-06-21 18:44:40 +02:00
|
|
|
mesh_calc_finalize(mesh_input, mesh_final);
|
|
|
|
runtime->mesh_eval = mesh_final;
|
|
|
|
});
|
2019-05-27 11:45:33 +02:00
|
|
|
}
|
2022-04-06 20:29:28 +02:00
|
|
|
else {
|
|
|
|
/* Already finalized by another instance, reuse. */
|
|
|
|
mesh_final = runtime->mesh_eval;
|
|
|
|
}
|
2019-05-27 11:45:33 +02:00
|
|
|
}
|
2022-04-06 20:29:28 +02:00
|
|
|
else {
|
|
|
|
/* Already finalized by another instance, reuse. */
|
|
|
|
mesh_final = runtime->mesh_eval;
|
|
|
|
}
|
2019-05-27 11:45:33 +02:00
|
|
|
}
|
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Return final mesh */
|
|
|
|
*r_final = mesh_final;
|
|
|
|
if (r_deform) {
|
|
|
|
*r_deform = mesh_deform;
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
2020-12-15 12:42:10 +01:00
|
|
|
if (r_geometry_set) {
|
|
|
|
*r_geometry_set = new GeometrySet(std::move(geometry_set_final));
|
|
|
|
}
|
2005-03-27 22:34:18 +02:00
|
|
|
}
|
|
|
|
|
2023-07-10 19:49:54 +02:00
|
|
|
static blender::Array<float3> editbmesh_vert_coords_alloc(const BMEditMesh *em)
|
- added data arguments to deformer modifiers, in case someone wants
to write one that is based on geometry (and not just vertex position)
- added editmode versions of modifier deform/apply calls and flag
to tag modifiers that support editmode
- added isFinalCalc param to applyModifier, basically a switch to let
subsurf know if it is calc'ng orco or not (so it can deal with cache
appropriately). This is kinda hacky and perhaps I can come up with
a better solution (its also a waste to do a complete subdivide just
to get vertex locations).
- changed ccgsubsurf to not preallocate hash's to be approximately correct
size... this was probably not a big performance savings but means that
the order of faces returned by the iterator can vary after the first
call, this messes up orco calculation so dropped for time being.
- minor bug fix, meshes with only key didn't get vertex normals correctly
calc'd
- updated editmesh derivedmesh to support auxiliary locations
- changed mesh_calc_modifiers to alloc deformVerts on demand
- added editmesh_calc_modifiers for calculating editmesh cage and final
derivedmesh's
- bug fix, update shadedisplist to always calc colors (even if totvert==0)
- changed load_editMesh and make_edge to build me->medge even if totedge==0
(incremental subsurf checks this)
todo: add drawFacesTex for ccgderivedmesh
So, modifiers in editmode are back (which means auto-mirror
in edit mode works now) although still not finished. Currently
no cage is computed, the cage is always the base mesh (in
other words, Optimal edge style editing is off), and the final
mesh currently includes all modifiers that work in edit mode
(including lattice and curve). At some point there will be toggles
for which modifiers affect the final/cage editmode derivedmesh's.
Also, very nice new feature is that incremental subsurf in object
mode returns a ccgderivedmesh object instead of copying to a new
displistmesh. This can make a *huge* speed difference, and is very
nice for working with deformed armatures (esp. with only small
per frame changes).
2005-07-22 09:37:15 +02:00
|
|
|
{
|
2023-07-10 19:49:54 +02:00
|
|
|
blender::Array<float3> cos(em->bm->totvert);
|
2009-05-16 18:18:08 +02:00
|
|
|
BMIter iter;
|
|
|
|
BMVert *eve;
|
2012-12-21 08:28:14 +01:00
|
|
|
int i;
|
|
|
|
BM_ITER_MESH_INDEX (eve, &iter, em->bm, BM_VERTS_OF_MESH, i) {
|
2023-07-10 19:49:54 +02:00
|
|
|
cos[i] = eve->co;
|
- added data arguments to deformer modifiers, in case someone wants
to write one that is based on geometry (and not just vertex position)
- added editmode versions of modifier deform/apply calls and flag
to tag modifiers that support editmode
- added isFinalCalc param to applyModifier, basically a switch to let
subsurf know if it is calc'ng orco or not (so it can deal with cache
appropriately). This is kinda hacky and perhaps I can come up with
a better solution (its also a waste to do a complete subdivide just
to get vertex locations).
- changed ccgsubsurf to not preallocate hash's to be approximately correct
size... this was probably not a big performance savings but means that
the order of faces returned by the iterator can vary after the first
call, this messes up orco calculation so dropped for time being.
- minor bug fix, meshes with only key didn't get vertex normals correctly
calc'd
- updated editmesh derivedmesh to support auxiliary locations
- changed mesh_calc_modifiers to alloc deformVerts on demand
- added editmesh_calc_modifiers for calculating editmesh cage and final
derivedmesh's
- bug fix, update shadedisplist to always calc colors (even if totvert==0)
- changed load_editMesh and make_edge to build me->medge even if totedge==0
(incremental subsurf checks this)
todo: add drawFacesTex for ccgderivedmesh
So, modifiers in editmode are back (which means auto-mirror
in edit mode works now) although still not finished. Currently
no cage is computed, the cage is always the base mesh (in
other words, Optimal edge style editing is off), and the final
mesh currently includes all modifiers that work in edit mode
(including lattice and curve). At some point there will be toggles
for which modifiers affect the final/cage editmode derivedmesh's.
Also, very nice new feature is that incremental subsurf in object
mode returns a ccgderivedmesh object instead of copying to a new
displistmesh. This can make a *huge* speed difference, and is very
nice for working with deformed armatures (esp. with only small
per frame changes).
2005-07-22 09:37:15 +02:00
|
|
|
}
|
2005-10-09 18:59:10 +02:00
|
|
|
return cos;
|
- added data arguments to deformer modifiers, in case someone wants
to write one that is based on geometry (and not just vertex position)
- added editmode versions of modifier deform/apply calls and flag
to tag modifiers that support editmode
- added isFinalCalc param to applyModifier, basically a switch to let
subsurf know if it is calc'ng orco or not (so it can deal with cache
appropriately). This is kinda hacky and perhaps I can come up with
a better solution (its also a waste to do a complete subdivide just
to get vertex locations).
- changed ccgsubsurf to not preallocate hash's to be approximately correct
size... this was probably not a big performance savings but means that
the order of faces returned by the iterator can vary after the first
call, this messes up orco calculation so dropped for time being.
- minor bug fix, meshes with only key didn't get vertex normals correctly
calc'd
- updated editmesh derivedmesh to support auxiliary locations
- changed mesh_calc_modifiers to alloc deformVerts on demand
- added editmesh_calc_modifiers for calculating editmesh cage and final
derivedmesh's
- bug fix, update shadedisplist to always calc colors (even if totvert==0)
- changed load_editMesh and make_edge to build me->medge even if totedge==0
(incremental subsurf checks this)
todo: add drawFacesTex for ccgderivedmesh
So, modifiers in editmode are back (which means auto-mirror
in edit mode works now) although still not finished. Currently
no cage is computed, the cage is always the base mesh (in
other words, Optimal edge style editing is off), and the final
mesh currently includes all modifiers that work in edit mode
(including lattice and curve). At some point there will be toggles
for which modifiers affect the final/cage editmode derivedmesh's.
Also, very nice new feature is that incremental subsurf in object
mode returns a ccgderivedmesh object instead of copying to a new
displistmesh. This can make a *huge* speed difference, and is very
nice for working with deformed armatures (esp. with only small
per frame changes).
2005-07-22 09:37:15 +02:00
|
|
|
}
|
|
|
|
|
2022-02-14 19:05:54 +01:00
|
|
|
bool editbmesh_modifier_is_enabled(const Scene *scene,
|
2020-10-26 07:07:58 +01:00
|
|
|
const Object *ob,
|
|
|
|
ModifierData *md,
|
|
|
|
bool has_prev_mesh)
|
2007-07-28 23:04:30 +02:00
|
|
|
{
|
2020-12-14 13:00:28 +01:00
|
|
|
const ModifierTypeInfo *mti = BKE_modifier_get_info((ModifierType)md->type);
|
2015-07-02 08:20:22 +02:00
|
|
|
const int required_mode = eModifierMode_Realtime | eModifierMode_Editmode;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-05-08 10:14:02 +02:00
|
|
|
if (!BKE_modifier_is_enabled(scene, md, required_mode)) {
|
2015-07-02 08:20:22 +02:00
|
|
|
return false;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-10-09 06:04:51 +02:00
|
|
|
if ((mti->flags & eModifierTypeFlag_RequiresOriginalData) && has_prev_mesh) {
|
2020-10-26 07:07:58 +01:00
|
|
|
BKE_modifier_set_error(ob, md, "Modifier requires original data, bad stack position");
|
2014-12-01 17:11:18 +01:00
|
|
|
return false;
|
2007-07-28 23:04:30 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-12-01 17:11:18 +01:00
|
|
|
return true;
|
2007-07-28 23:04:30 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Mesh: Replace auto smooth with node group
Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
2023-10-20 16:54:08 +02:00
|
|
|
static void editbmesh_calc_modifier_final_normals(Mesh *mesh_final)
|
2019-03-28 11:42:53 +01:00
|
|
|
{
|
Mesh: Replace auto smooth with node group
Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
2023-10-20 16:54:08 +02:00
|
|
|
switch (mesh_final->runtime->wrapper_type) {
|
|
|
|
case ME_WRAPPER_TYPE_SUBD:
|
|
|
|
case ME_WRAPPER_TYPE_MDATA:
|
|
|
|
break;
|
|
|
|
case ME_WRAPPER_TYPE_BMESH: {
|
|
|
|
BMEditMesh *em = mesh_final->edit_mesh;
|
|
|
|
blender::bke::EditMeshData *emd = mesh_final->runtime->edit_data;
|
|
|
|
if (!emd->vertexCos.is_empty()) {
|
|
|
|
BKE_editmesh_cache_ensure_vert_normals(em, emd);
|
|
|
|
BKE_editmesh_cache_ensure_face_normals(em, emd);
|
|
|
|
}
|
|
|
|
return;
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2019-03-28 11:42:53 +01:00
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Mesh: Replace auto smooth with node group
Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
2023-10-20 16:54:08 +02:00
|
|
|
static void editbmesh_calc_modifier_final_normals_or_defer(Mesh *mesh_final)
|
2022-07-11 17:25:13 +02:00
|
|
|
{
|
2022-10-13 03:55:26 +02:00
|
|
|
if (mesh_final->runtime->wrapper_type != ME_WRAPPER_TYPE_MDATA) {
|
2022-07-11 17:25:13 +02:00
|
|
|
/* Generated at draw time. */
|
2022-10-13 03:55:26 +02:00
|
|
|
mesh_final->runtime->wrapper_type_finalize = eMeshWrapperType(
|
|
|
|
1 << mesh_final->runtime->wrapper_type);
|
2022-07-11 17:25:13 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
Mesh: Replace auto smooth with node group
Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
2023-10-20 16:54:08 +02:00
|
|
|
editbmesh_calc_modifier_final_normals(mesh_final);
|
2022-07-11 17:25:13 +02:00
|
|
|
}
|
|
|
|
|
2023-08-22 03:51:53 +02:00
|
|
|
static MutableSpan<float3> mesh_wrapper_vert_coords_ensure_for_write(Mesh *mesh)
|
2023-07-07 13:07:15 +02:00
|
|
|
{
|
|
|
|
switch (mesh->runtime->wrapper_type) {
|
|
|
|
case ME_WRAPPER_TYPE_BMESH:
|
2023-07-10 19:49:54 +02:00
|
|
|
if (mesh->runtime->edit_data->vertexCos.is_empty()) {
|
2023-07-07 13:07:15 +02:00
|
|
|
mesh->runtime->edit_data->vertexCos = editbmesh_vert_coords_alloc(mesh->edit_mesh);
|
|
|
|
}
|
|
|
|
return mesh->runtime->edit_data->vertexCos;
|
|
|
|
case ME_WRAPPER_TYPE_MDATA:
|
|
|
|
case ME_WRAPPER_TYPE_SUBD:
|
2023-07-10 19:49:54 +02:00
|
|
|
return mesh->vert_positions_for_write();
|
2023-07-07 13:07:15 +02:00
|
|
|
}
|
2023-07-10 19:49:54 +02:00
|
|
|
BLI_assert_unreachable();
|
|
|
|
return {};
|
2023-07-07 13:07:15 +02:00
|
|
|
}
|
|
|
|
|
2023-06-03 00:36:28 +02:00
|
|
|
static void editbmesh_calc_modifiers(Depsgraph *depsgraph,
|
2022-02-14 19:05:54 +01:00
|
|
|
const Scene *scene,
|
2019-03-27 19:07:16 +01:00
|
|
|
Object *ob,
|
2019-03-28 11:42:53 +01:00
|
|
|
BMEditMesh *em_input,
|
2019-03-27 19:07:16 +01:00
|
|
|
const CustomData_MeshMasks *dataMask,
|
2015-07-02 08:20:22 +02:00
|
|
|
/* return args */
|
2019-03-27 19:07:16 +01:00
|
|
|
Mesh **r_cage,
|
2020-12-15 12:42:10 +01:00
|
|
|
Mesh **r_final,
|
|
|
|
GeometrySet **r_geometry_set)
|
2013-07-05 02:13:14 +02:00
|
|
|
{
|
2020-12-14 13:00:28 +01:00
|
|
|
Mesh *mesh_input = (Mesh *)ob->data;
|
|
|
|
Mesh *mesh_cage = nullptr;
|
2020-12-15 12:42:10 +01:00
|
|
|
/* This geometry set contains the non-mesh data that might be generated by modifiers. */
|
|
|
|
GeometrySet geometry_set_final;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Mesh with constructive modifiers but no deformation applied. Tracked
|
|
|
|
* along with final mesh if undeformed / orco coordinates are requested
|
|
|
|
* for texturing. */
|
2020-12-14 13:00:28 +01:00
|
|
|
Mesh *mesh_orco = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Modifier evaluation modes. */
|
|
|
|
const int required_mode = eModifierMode_Realtime | eModifierMode_Editmode;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-10-15 09:32:13 +02:00
|
|
|
const bool use_render = (DEG_get_mode(depsgraph) == DAG_EVAL_RENDER);
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Modifier evaluation contexts for different types of modifiers. */
|
2023-05-26 22:11:54 +02:00
|
|
|
ModifierApplyFlag apply_render = use_render ? MOD_APPLY_RENDER : ModifierApplyFlag(0);
|
|
|
|
const ModifierEvalContext mectx = {depsgraph, ob, MOD_APPLY_USECACHE | apply_render};
|
2019-03-28 11:42:53 +01:00
|
|
|
const ModifierEvalContext mectx_orco = {depsgraph, ob, MOD_APPLY_ORCO};
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Get effective list of modifiers to execute. Some effects like shape keys
|
|
|
|
* are added as virtual modifiers before the user created modifiers. */
|
2023-07-27 04:04:18 +02:00
|
|
|
VirtualModifierData virtual_modifier_data;
|
|
|
|
ModifierData *md = BKE_modifiers_get_virtual_modifierlist(ob, &virtual_modifier_data);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Compute accumulated datamasks needed by each modifier. It helps to do
|
|
|
|
* this fine grained so that for example vertex groups are preserved up to
|
|
|
|
* an armature modifier, but not through a following subsurf modifier where
|
|
|
|
* subdividing them is expensive. */
|
2019-06-10 15:42:15 +02:00
|
|
|
CustomData_MeshMasks final_datamask = *dataMask;
|
2020-05-08 10:14:02 +02:00
|
|
|
CDMaskLink *datamasks = BKE_modifier_calc_data_masks(
|
2022-09-14 21:49:40 +02:00
|
|
|
scene, md, &final_datamask, required_mode, nullptr, nullptr);
|
2019-03-28 11:42:53 +01:00
|
|
|
CDMaskLink *md_datamask = datamasks;
|
|
|
|
CustomData_MeshMasks append_mask = CD_MASK_BAREMESH;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-07 13:07:15 +02:00
|
|
|
Mesh *mesh_final = BKE_mesh_wrapper_from_editmesh(em_input, &final_datamask, mesh_input);
|
|
|
|
|
2020-12-14 13:00:28 +01:00
|
|
|
int cageIndex = BKE_modifiers_get_cage_index(scene, ob, nullptr, true);
|
2019-06-10 15:42:15 +02:00
|
|
|
if (r_cage && cageIndex == -1) {
|
2023-07-07 13:07:15 +02:00
|
|
|
mesh_cage = mesh_final;
|
2019-06-10 15:42:15 +02:00
|
|
|
}
|
|
|
|
|
Mesh: Avoid creating incorrect original index layers
Currently, whenever any BMesh is converted to a Mesh (except for edit
mode switching), original index (`CD_ORIGINDEX`) layers are added.
This is incorrect, because many operations just convert some Mesh into
a BMesh and then back, but they shouldn't make any assumption about
where their input mesh came from. It might even come from a primitive
in geometry nodes, where there are no original indices at all.
Conceptually, mesh original indices should be filled by the modifier
stack when first creating the evaluated mesh. So that's where they're
moved in this patch. A separate function now fills the indices with their
default (0,1,2,3...) values. The way the mesh wrapper system defers
the BMesh to Mesh conversion makes this a bit less obvious though.
The old behavior is incorrect, but it's also slower, because three
arrays the size of the mesh's vertices, edges, and faces had to be
allocated and filled during the BMesh to Mesh conversion, which just
ends up putting more pressure on the cache. In the many cases where
original indices aren't used, I measured an **8% speedup** for the
conversion (from 76.5ms to 70.7ms).
Generally there is an assumption that BMesh is "original" and Mesh is
"evaluated". After this patch, that assumption isn't quite as strong,
but it still exists for two reasons. First, original indices are added
whenever converting a BMesh "wrapper" to a Mesh. Second, original
indices are not added to the BMesh at the beginning of evaluation,
which assumes that every BMesh in the viewport is original and doesn't
need the mapping.
Differential Revision: https://developer.blender.org/D14018
2022-02-18 17:51:00 +01:00
|
|
|
/* The mesh from edit mode should not have any original index layers already, since those
|
|
|
|
* are added during evaluation when necessary and are redundant on an original mesh. */
|
|
|
|
BLI_assert(CustomData_get_layer(&em_input->bm->pdata, CD_ORIGINDEX) == nullptr &&
|
|
|
|
CustomData_get_layer(&em_input->bm->edata, CD_ORIGINDEX) == nullptr &&
|
|
|
|
CustomData_get_layer(&em_input->bm->pdata, CD_ORIGINDEX) == nullptr);
|
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Clear errors before evaluation. */
|
2020-05-08 10:14:02 +02:00
|
|
|
BKE_modifiers_clear_errors(ob);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-04-20 20:18:02 +02:00
|
|
|
if (ob->modifier_flag & OB_MODIFIER_FLAG_ADD_REST_POSITION) {
|
2023-07-07 13:07:15 +02:00
|
|
|
BKE_mesh_wrapper_ensure_mdata(mesh_final);
|
2023-04-20 20:18:02 +02:00
|
|
|
set_rest_position(*mesh_final);
|
|
|
|
}
|
|
|
|
|
2023-07-07 13:07:15 +02:00
|
|
|
bool non_deform_modifier_applied = false;
|
2019-03-28 11:42:53 +01:00
|
|
|
for (int i = 0; md; i++, md = md->next, md_datamask = md_datamask->next) {
|
2020-12-14 13:00:28 +01:00
|
|
|
const ModifierTypeInfo *mti = BKE_modifier_get_info((ModifierType)md->type);
|
2023-07-07 13:07:15 +02:00
|
|
|
if (!editbmesh_modifier_is_enabled(scene, ob, md, non_deform_modifier_applied)) {
|
- added eModifierTypeFlag_RequiresOriginalData for modifiers that
can only follow deform (for example, they store mesh vertex
indices)
- added ModifierType.foreachObjectLink for iterating over Object
links inside modifier data (used for file load, relinking, etc)
- switched various modifiers_ functions to take object argument
instead of ListBase
- added user editable name field to modifiers
- bug fix, duplicate and make single user didn't relink object
pointers in modifier data
- added modifiers to outliner, needs icon
- added armature, hook, and softbody modifiers (softbody doesn't
do anything atm). added conversion of old hooks to modifiers.
NOTE-THE-FIRST: User name field is not initialized on loading 2.38 files
so if you have saved stuff with a cvs blender you will see blank names.
NOTE-THE-SECOND: Since modifiers aren't evaluated yet for non-Mesh
objects, hooks for lattices and curves are broken. Don't updated if
you actually, say, *use* Blender.
NOTE-THE-THIRD: Old hooks used a quirky weighting system during
deformation which can't be extended to modifiers. On the upside,
I doubt anyone relied on the old quirky system and the new system
makes much more sense. (Although the way falloff works is still
quite stupid I think).
2005-08-11 00:05:52 +02:00
|
|
|
continue;
|
2015-07-02 08:20:22 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Modifiers: measure execution time and provide Python access
The goal is to give technical artists the ability to optimize modifier usage
and/or geometry node groups for performance. In the long term, it
would be useful if Blender could provide its own UI to display profiling
information to users. However, right now, there are too many open
design questions making it infeasible to tackle this in the short term.
This commit uses a simpler approach: Instead of adding new ui for
profiling data, it exposes the execution-time of modifiers in the Python
API. This allows technical artists to access the information and to build
their own UI to display the relevant information. In the long term this
will hopefully also help us to integrate a native ui for this in Blender
by observing how users use this information.
Note: The execution time of a modifier highly depends on what other
things the CPU is doing at the same time. For example, in many more
complex files, many objects and therefore modifiers are evaluated at
the same time by multiple threads which makes the measurement
much less reliable. For best results, make sure that only one object
is evaluated at a time (e.g. by changing it in isolation) and that no
other process on the system keeps the CPU busy.
As shown below, the execution time has to be accessed on the
evaluated object, not the original object.
```lang=python
import bpy
depsgraph = bpy.context.view_layer.depsgraph
ob = bpy.context.active_object
ob_eval = ob.evaluated_get(depsgraph)
modifier_eval = ob_eval.modifiers[0]
print(modifier_eval.execution_time, "s")
```
Differential Revision: https://developer.blender.org/D17185
2023-02-06 15:39:59 +01:00
|
|
|
blender::bke::ScopedModifierTimer modifier_timer{*md};
|
|
|
|
|
2019-06-10 15:42:15 +02:00
|
|
|
/* Add an orco mesh as layer if needed by this modifier. */
|
2023-07-27 04:04:18 +02:00
|
|
|
if (mesh_orco && mti->required_data_mask) {
|
2019-03-28 11:42:53 +01:00
|
|
|
CustomData_MeshMasks mask = {0};
|
2023-07-27 04:04:18 +02:00
|
|
|
mti->required_data_mask(md, &mask);
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
if (mask.vmask & CD_MASK_ORCO) {
|
2019-03-28 11:42:53 +01:00
|
|
|
add_orco_mesh(ob, em_input, mesh_final, mesh_orco, CD_ORCO);
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2018-10-09 06:04:51 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-07 13:07:15 +02:00
|
|
|
if (mesh_final == mesh_cage) {
|
|
|
|
/* If the cage mesh has already been assigned, we have passed the cage index in the modifier
|
|
|
|
* list. If the cage and final meshes are still the same, duplicate the final mesh so the
|
|
|
|
* cage mesh isn't modified anymore. */
|
|
|
|
mesh_final = BKE_mesh_copy_for_eval(mesh_final);
|
|
|
|
if (mesh_cage->edit_mesh) {
|
|
|
|
mesh_final->edit_mesh = static_cast<BMEditMesh *>(MEM_dupallocN(mesh_cage->edit_mesh));
|
|
|
|
mesh_final->edit_mesh->is_shallow_copy = true;
|
|
|
|
mesh_final->runtime->is_original_bmesh = true;
|
|
|
|
BKE_mesh_runtime_ensure_edit_data(mesh_final);
|
2019-03-18 15:37:46 +01:00
|
|
|
}
|
2023-07-07 13:07:15 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-11-14 10:03:56 +01:00
|
|
|
if (mti->type == ModifierTypeType::OnlyDeform) {
|
2023-07-27 04:04:18 +02:00
|
|
|
if (mti->deform_verts_EM) {
|
2023-11-14 10:54:57 +01:00
|
|
|
BKE_modifier_deform_vertsEM(md,
|
|
|
|
&mectx,
|
|
|
|
em_input,
|
|
|
|
mesh_final,
|
|
|
|
|
|
|
|
mesh_wrapper_vert_coords_ensure_for_write(mesh_final));
|
2023-07-07 13:07:15 +02:00
|
|
|
BKE_mesh_wrapper_tag_positions_changed(mesh_final);
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
|
|
|
else {
|
2023-07-07 13:07:15 +02:00
|
|
|
BKE_mesh_wrapper_ensure_mdata(mesh_final);
|
2023-11-14 10:54:57 +01:00
|
|
|
BKE_modifier_deform_verts(md, &mectx, mesh_final, mesh_final->vert_positions_for_write());
|
2023-07-07 13:07:15 +02:00
|
|
|
BKE_mesh_tag_positions_changed(mesh_final);
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
2012-03-24 07:18:31 +01:00
|
|
|
}
|
|
|
|
else {
|
2023-07-07 13:07:15 +02:00
|
|
|
non_deform_modifier_applied = true;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
/* create an orco derivedmesh in parallel */
|
2019-03-28 11:42:53 +01:00
|
|
|
CustomData_MeshMasks mask = md_datamask->mask;
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
if (mask.vmask & CD_MASK_ORCO) {
|
2019-03-28 11:42:53 +01:00
|
|
|
if (!mesh_orco) {
|
|
|
|
mesh_orco = create_orco_mesh(ob, mesh_input, em_input, CD_ORCO);
|
2018-10-09 06:04:51 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
mask.vmask &= ~CD_MASK_ORCO;
|
|
|
|
mask.vmask |= CD_MASK_ORIGINDEX;
|
|
|
|
mask.emask |= CD_MASK_ORIGINDEX;
|
|
|
|
mask.pmask |= CD_MASK_ORIGINDEX;
|
2019-03-28 11:42:53 +01:00
|
|
|
mesh_set_only_copy(mesh_orco, &mask);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-05-08 10:14:02 +02:00
|
|
|
Mesh *mesh_next = BKE_modifier_modify_mesh(md, &mectx_orco, mesh_orco);
|
2019-03-28 11:42:53 +01:00
|
|
|
ASSERT_IS_VALID_MESH(mesh_next);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_next) {
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
/* if the modifier returned a new dm, release the old one */
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_orco && mesh_orco != mesh_next) {
|
2020-12-14 13:00:28 +01:00
|
|
|
BKE_id_free(nullptr, mesh_orco);
|
2018-10-09 06:04:51 +02:00
|
|
|
}
|
2019-03-28 11:42:53 +01:00
|
|
|
mesh_orco = mesh_next;
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2006-12-05 18:42:03 +01:00
|
|
|
/* set the DerivedMesh to only copy needed data */
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
CustomData_MeshMasks_update(&mask, &append_mask);
|
2022-03-07 17:25:50 +01:00
|
|
|
/* XXX WHAT? overwrites mask ??? */
|
2019-04-16 17:55:11 +02:00
|
|
|
/* CD_MASK_ORCO may have been cleared above */
|
|
|
|
mask = md_datamask->mask;
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
mask.vmask |= CD_MASK_ORIGINDEX;
|
|
|
|
mask.emask |= CD_MASK_ORIGINDEX;
|
|
|
|
mask.pmask |= CD_MASK_ORIGINDEX;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
mesh_set_only_copy(mesh_final, &mask);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
if (mask.lmask & CD_MASK_ORIGSPACE_MLOOP) {
|
2023-07-25 21:15:52 +02:00
|
|
|
if (!CustomData_has_layer(&mesh_final->loop_data, CD_ORIGSPACE_MLOOP)) {
|
2023-03-14 15:30:26 +01:00
|
|
|
CustomData_add_layer(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh_final->loop_data, CD_ORIGSPACE_MLOOP, CD_SET_DEFAULT, mesh_final->totloop);
|
2019-03-28 11:42:53 +01:00
|
|
|
mesh_init_origspace(mesh_final);
|
2012-02-05 12:30:26 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
2020-12-15 12:42:10 +01:00
|
|
|
Mesh *mesh_next = modifier_modify_mesh_and_geometry_set(
|
2021-02-02 16:20:54 +01:00
|
|
|
md, mectx, mesh_final, geometry_set_final);
|
2019-03-28 11:42:53 +01:00
|
|
|
ASSERT_IS_VALID_MESH(mesh_next);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_next) {
|
2023-07-07 13:07:15 +02:00
|
|
|
if (mesh_final != mesh_next) {
|
2020-12-14 13:00:28 +01:00
|
|
|
BKE_id_free(nullptr, mesh_final);
|
2018-10-09 06:04:51 +02:00
|
|
|
}
|
2019-03-28 11:42:53 +01:00
|
|
|
mesh_final = mesh_next;
|
2005-08-03 06:04:05 +02:00
|
|
|
}
|
2022-10-13 03:55:26 +02:00
|
|
|
mesh_final->runtime->deformed_only = false;
|
2005-08-03 06:04:05 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-07-02 08:20:22 +02:00
|
|
|
if (r_cage && i == cageIndex) {
|
2023-07-07 13:07:15 +02:00
|
|
|
mesh_cage = mesh_final;
|
- added data arguments to deformer modifiers, in case someone wants
to write one that is based on geometry (and not just vertex position)
- added editmode versions of modifier deform/apply calls and flag
to tag modifiers that support editmode
- added isFinalCalc param to applyModifier, basically a switch to let
subsurf know if it is calc'ng orco or not (so it can deal with cache
appropriately). This is kinda hacky and perhaps I can come up with
a better solution (its also a waste to do a complete subdivide just
to get vertex locations).
- changed ccgsubsurf to not preallocate hash's to be approximately correct
size... this was probably not a big performance savings but means that
the order of faces returned by the iterator can vary after the first
call, this messes up orco calculation so dropped for time being.
- minor bug fix, meshes with only key didn't get vertex normals correctly
calc'd
- updated editmesh derivedmesh to support auxiliary locations
- changed mesh_calc_modifiers to alloc deformVerts on demand
- added editmesh_calc_modifiers for calculating editmesh cage and final
derivedmesh's
- bug fix, update shadedisplist to always calc colors (even if totvert==0)
- changed load_editMesh and make_edge to build me->medge even if totedge==0
(incremental subsurf checks this)
todo: add drawFacesTex for ccgderivedmesh
So, modifiers in editmode are back (which means auto-mirror
in edit mode works now) although still not finished. Currently
no cage is computed, the cage is always the base mesh (in
other words, Optimal edge style editing is off), and the final
mesh currently includes all modifiers that work in edit mode
(including lattice and curve). At some point there will be toggles
for which modifiers affect the final/cage editmode derivedmesh's.
Also, very nice new feature is that incremental subsurf in object
mode returns a ccgderivedmesh object instead of copying to a new
displistmesh. This can make a *huge* speed difference, and is very
nice for working with deformed armatures (esp. with only small
per frame changes).
2005-07-22 09:37:15 +02:00
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-12-14 13:00:28 +01:00
|
|
|
BLI_linklist_free((LinkNode *)datamasks, nullptr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Add orco coordinates to final and deformed mesh if requested. */
|
2019-06-10 15:42:15 +02:00
|
|
|
if (final_datamask.vmask & CD_MASK_ORCO) {
|
2023-02-09 01:30:25 +01:00
|
|
|
/* FIXME(@ideasman42): avoid the need to convert to mesh data just to add an orco layer. */
|
2020-05-25 12:16:42 +02:00
|
|
|
BKE_mesh_wrapper_ensure_mdata(mesh_final);
|
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
add_orco_mesh(ob, em_input, mesh_final, mesh_orco, CD_ORCO);
|
2012-02-28 11:22:21 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_orco) {
|
2020-12-14 13:00:28 +01:00
|
|
|
BKE_id_free(nullptr, mesh_orco);
|
2014-04-13 12:18:51 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Compute normals. */
|
Mesh: Replace auto smooth with node group
Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
2023-10-20 16:54:08 +02:00
|
|
|
editbmesh_calc_modifier_final_normals_or_defer(mesh_final);
|
2019-03-28 11:42:53 +01:00
|
|
|
if (mesh_cage && (mesh_cage != mesh_final)) {
|
Mesh: Replace auto smooth with node group
Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
2023-10-20 16:54:08 +02:00
|
|
|
editbmesh_calc_modifier_final_normals_or_defer(mesh_cage);
|
2018-10-09 06:04:51 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 11:42:53 +01:00
|
|
|
/* Return final mesh. */
|
|
|
|
*r_final = mesh_final;
|
|
|
|
if (r_cage) {
|
|
|
|
*r_cage = mesh_cage;
|
2018-10-09 06:04:51 +02:00
|
|
|
}
|
2020-12-15 12:42:10 +01:00
|
|
|
if (r_geometry_set) {
|
|
|
|
*r_geometry_set = new GeometrySet(std::move(geometry_set_final));
|
|
|
|
}
|
- added data arguments to deformer modifiers, in case someone wants
to write one that is based on geometry (and not just vertex position)
- added editmode versions of modifier deform/apply calls and flag
to tag modifiers that support editmode
- added isFinalCalc param to applyModifier, basically a switch to let
subsurf know if it is calc'ng orco or not (so it can deal with cache
appropriately). This is kinda hacky and perhaps I can come up with
a better solution (its also a waste to do a complete subdivide just
to get vertex locations).
- changed ccgsubsurf to not preallocate hash's to be approximately correct
size... this was probably not a big performance savings but means that
the order of faces returned by the iterator can vary after the first
call, this messes up orco calculation so dropped for time being.
- minor bug fix, meshes with only key didn't get vertex normals correctly
calc'd
- updated editmesh derivedmesh to support auxiliary locations
- changed mesh_calc_modifiers to alloc deformVerts on demand
- added editmesh_calc_modifiers for calculating editmesh cage and final
derivedmesh's
- bug fix, update shadedisplist to always calc colors (even if totvert==0)
- changed load_editMesh and make_edge to build me->medge even if totedge==0
(incremental subsurf checks this)
todo: add drawFacesTex for ccgderivedmesh
So, modifiers in editmode are back (which means auto-mirror
in edit mode works now) although still not finished. Currently
no cage is computed, the cage is always the base mesh (in
other words, Optimal edge style editing is off), and the final
mesh currently includes all modifiers that work in edit mode
(including lattice and curve). At some point there will be toggles
for which modifiers affect the final/cage editmode derivedmesh's.
Also, very nice new feature is that incremental subsurf in object
mode returns a ccgderivedmesh object instead of copying to a new
displistmesh. This can make a *huge* speed difference, and is very
nice for working with deformed armatures (esp. with only small
per frame changes).
2005-07-22 09:37:15 +02:00
|
|
|
}
|
|
|
|
|
2023-06-03 00:36:28 +02:00
|
|
|
static void mesh_build_extra_data(Depsgraph *depsgraph, Object *ob, Mesh *mesh_eval)
|
Shrinkwrap: new mode that projects along the target normal.
The Nearest Surface Point shrink method, while fast, is neither
smooth nor continuous: as the source point moves, the projected
point can both stop and jump. This causes distortions in the
deformation of the shrinkwrap modifier, and the motion of an
animated object with a shrinkwrap constraint.
This patch implements a new mode, which, instead of using the simple
nearest point search, iteratively solves an equation for each triangle
to find a point which has its interpolated normal point to or from the
original vertex. Non-manifold boundary edges are treated as infinitely
thin cylinders that cast normals in all perpendicular directions.
Since this is useful for the constraint, and having multiple
objects with constraints targeting the same guide mesh is a quite
reasonable use case, rather than calculating the mesh boundary edge
data over and over again, it is precomputed and cached in the mesh.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D3836
2018-11-06 19:04:53 +01:00
|
|
|
{
|
|
|
|
uint32_t eval_flags = DEG_get_eval_flags_for_id(depsgraph, &ob->id);
|
|
|
|
|
|
|
|
if (eval_flags & DAG_EVAL_NEED_SHRINKWRAP_BOUNDARY) {
|
2020-02-27 11:23:15 +01:00
|
|
|
BKE_shrinkwrap_compute_boundary_data(mesh_eval);
|
Shrinkwrap: new mode that projects along the target normal.
The Nearest Surface Point shrink method, while fast, is neither
smooth nor continuous: as the source point moves, the projected
point can both stop and jump. This causes distortions in the
deformation of the shrinkwrap modifier, and the motion of an
animated object with a shrinkwrap constraint.
This patch implements a new mode, which, instead of using the simple
nearest point search, iteratively solves an equation for each triangle
to find a point which has its interpolated normal point to or from the
original vertex. Non-manifold boundary edges are treated as infinitely
thin cylinders that cast normals in all perpendicular directions.
Since this is useful for the constraint, and having multiple
objects with constraints targeting the same guide mesh is a quite
reasonable use case, rather than calculating the mesh boundary edge
data over and over again, it is precomputed and cached in the mesh.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D3836
2018-11-06 19:04:53 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-06-03 00:36:28 +02:00
|
|
|
static void mesh_build_data(Depsgraph *depsgraph,
|
2022-02-14 19:05:54 +01:00
|
|
|
const Scene *scene,
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
Object *ob,
|
|
|
|
const CustomData_MeshMasks *dataMask,
|
2019-03-27 19:07:16 +01:00
|
|
|
const bool need_mapping)
|
- shuffled editmesh derived function name/function
- added ModifierTypeInfo.freeData function
- added modifier_{new,free] utility function
- added ccgSubSurf_getUseAgeCounts to query info
- removed subsurf modifier faking (ME_SUBSURF flag is no
longer valid). subsurf modifier gets converted on file load
although there is obscure linked mesh situation where this
can go wrong, will fix shortly. this also means that some
places in the code that test/copy subsurf settings are broken
for the time being.
- shuffled modifier calculation to be simpler. note that
all modifiers are currently disabled in editmode (including
subsurf). don't worry, will return shortly.
- bug fix, build modifier didn't randomize meshes with only verts
- cleaned up subsurf_ccg and adapted for future editmode modifier
work
- added editmesh.derived{Cage,Final}, not used yet
- added SubsurfModifierData.{mCache,emCache}, will be used to cache
subsurf instead of caching in derivedmesh itself
- removed old subsurf buttons
- added do_modifiers_buttons to handle modifier events
- removed count_object counting of modifier (subsurfed) objects...
this would be nice to add back at some point but requires care.
probably requires rewrite of counting system.
New feature: Incremental Subsurf in Object Mode
The previous release introduce incremental subsurf calculation during
editmode but it was not turned on during object mode. In general it
does not make sense to have it always enabled during object mode because
it requires caching a fair amount of information about the mesh which
is a waste of memory unless the mesh is often recalculated.
However, for mesh's that have subsurfed armatures for example, or that
have other modifiers so that the mesh is essentially changing on every
frame, it makes a lot of sense to keep the subsurf'd object around and
that is what the new incremental subsurf modifier toggle is for. The
intent is that the user will enable this option for (a) a mesh that is
currently under active editing or (b) a mesh that is heavily updated
in the scene, such as a character.
I will try to write more about this feature for release, because it
has advantages and disadvantages that are not immediately obvious (the
first user reaction will be to turn it on for ever object, which is
probably not correct).
2005-07-21 22:30:33 +02:00
|
|
|
{
|
2022-04-21 19:02:13 +02:00
|
|
|
#if 0 /* XXX This is already taken care of in #mesh_calc_modifiers... */
|
2018-12-01 10:12:18 +01:00
|
|
|
if (need_mapping) {
|
|
|
|
/* Also add the flag so that it is recorded in lastDataMask. */
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
dataMask->vmask |= CD_MASK_ORIGINDEX;
|
|
|
|
dataMask->emask |= CD_MASK_ORIGINDEX;
|
|
|
|
dataMask->pmask |= CD_MASK_ORIGINDEX;
|
2018-12-01 10:12:18 +01:00
|
|
|
}
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
#endif
|
2018-12-01 10:12:18 +01:00
|
|
|
|
2020-12-14 13:00:28 +01:00
|
|
|
Mesh *mesh_eval = nullptr, *mesh_deform_eval = nullptr;
|
2020-12-15 12:42:10 +01:00
|
|
|
GeometrySet *geometry_set_eval = nullptr;
|
2018-05-30 12:56:20 +02:00
|
|
|
mesh_calc_modifiers(depsgraph,
|
2019-03-27 19:07:16 +01:00
|
|
|
scene,
|
|
|
|
ob,
|
2021-07-01 02:08:24 +02:00
|
|
|
true,
|
2019-03-27 19:07:16 +01:00
|
|
|
need_mapping,
|
|
|
|
dataMask,
|
|
|
|
true,
|
2019-05-31 10:05:56 +02:00
|
|
|
true,
|
2020-02-27 11:23:15 +01:00
|
|
|
&mesh_deform_eval,
|
2020-12-15 12:42:10 +01:00
|
|
|
&mesh_eval,
|
|
|
|
&geometry_set_eval);
|
2018-11-25 18:39:57 +01:00
|
|
|
|
2020-02-27 11:23:15 +01:00
|
|
|
/* The modifier stack evaluation is storing result in mesh->runtime.mesh_eval, but this result
|
|
|
|
* is not guaranteed to be owned by object.
|
|
|
|
*
|
|
|
|
* Check ownership now, since later on we can not go to a mesh owned by someone else via
|
|
|
|
* object's runtime: this could cause access freed data on depsgraph destruction (mesh who owns
|
|
|
|
* the final result might be freed prior to object). */
|
2020-12-14 13:00:28 +01:00
|
|
|
Mesh *mesh = (Mesh *)ob->data;
|
2022-10-13 03:55:26 +02:00
|
|
|
const bool is_mesh_eval_owned = (mesh_eval != mesh->runtime->mesh_eval);
|
2020-02-27 11:23:15 +01:00
|
|
|
BKE_object_eval_assign_data(ob, &mesh_eval->id, is_mesh_eval_owned);
|
|
|
|
|
2021-11-05 17:51:34 +01:00
|
|
|
/* Add the final mesh as a non-owning component to the geometry set. */
|
2020-12-15 12:42:10 +01:00
|
|
|
MeshComponent &mesh_component = geometry_set_eval->get_component_for_write<MeshComponent>();
|
2021-11-05 17:51:34 +01:00
|
|
|
mesh_component.replace(mesh_eval, GeometryOwnershipType::Editable);
|
2023-11-15 18:46:07 +01:00
|
|
|
ob->runtime->geometry_set_eval = geometry_set_eval;
|
2020-12-15 12:42:10 +01:00
|
|
|
|
2023-11-15 18:46:07 +01:00
|
|
|
ob->runtime->mesh_deform_eval = mesh_deform_eval;
|
|
|
|
ob->runtime->last_data_mask = *dataMask;
|
|
|
|
ob->runtime->last_need_mapping = need_mapping;
|
2012-03-14 07:30:55 +01:00
|
|
|
|
2020-02-27 11:23:15 +01:00
|
|
|
BKE_object_boundbox_calc_from_mesh(ob, mesh_eval);
|
|
|
|
|
2020-08-13 12:53:21 +02:00
|
|
|
/* Make sure that drivers can target shapekey properties.
|
|
|
|
* Note that this causes a potential inconsistency, as the shapekey may have a
|
|
|
|
* different topology than the evaluated mesh. */
|
2020-12-14 13:00:28 +01:00
|
|
|
BLI_assert(mesh->key == nullptr || DEG_is_evaluated_id(&mesh->key->id));
|
2020-08-13 12:53:21 +02:00
|
|
|
mesh_eval->key = mesh->key;
|
|
|
|
|
2018-04-05 18:20:27 +02:00
|
|
|
if ((ob->mode & OB_MODE_ALL_SCULPT) && ob->sculpt) {
|
2019-05-31 12:50:15 +02:00
|
|
|
if (DEG_is_active(depsgraph)) {
|
|
|
|
BKE_sculpt_update_object_after_eval(depsgraph, ob);
|
|
|
|
}
|
2012-03-14 07:30:55 +01:00
|
|
|
}
|
2013-05-30 19:36:43 +02:00
|
|
|
|
2020-02-27 11:23:15 +01:00
|
|
|
mesh_build_extra_data(depsgraph, ob, mesh_eval);
|
- shuffled editmesh derived function name/function
- added ModifierTypeInfo.freeData function
- added modifier_{new,free] utility function
- added ccgSubSurf_getUseAgeCounts to query info
- removed subsurf modifier faking (ME_SUBSURF flag is no
longer valid). subsurf modifier gets converted on file load
although there is obscure linked mesh situation where this
can go wrong, will fix shortly. this also means that some
places in the code that test/copy subsurf settings are broken
for the time being.
- shuffled modifier calculation to be simpler. note that
all modifiers are currently disabled in editmode (including
subsurf). don't worry, will return shortly.
- bug fix, build modifier didn't randomize meshes with only verts
- cleaned up subsurf_ccg and adapted for future editmode modifier
work
- added editmesh.derived{Cage,Final}, not used yet
- added SubsurfModifierData.{mCache,emCache}, will be used to cache
subsurf instead of caching in derivedmesh itself
- removed old subsurf buttons
- added do_modifiers_buttons to handle modifier events
- removed count_object counting of modifier (subsurfed) objects...
this would be nice to add back at some point but requires care.
probably requires rewrite of counting system.
New feature: Incremental Subsurf in Object Mode
The previous release introduce incremental subsurf calculation during
editmode but it was not turned on during object mode. In general it
does not make sense to have it always enabled during object mode because
it requires caching a fair amount of information about the mesh which
is a waste of memory unless the mesh is often recalculated.
However, for mesh's that have subsurfed armatures for example, or that
have other modifiers so that the mesh is essentially changing on every
frame, it makes a lot of sense to keep the subsurf'd object around and
that is what the new incremental subsurf modifier toggle is for. The
intent is that the user will enable this option for (a) a mesh that is
currently under active editing or (b) a mesh that is heavily updated
in the scene, such as a character.
I will try to write more about this feature for release, because it
has advantages and disadvantages that are not immediately obvious (the
first user reaction will be to turn it on for ever object, which is
probably not correct).
2005-07-21 22:30:33 +02:00
|
|
|
}
|
|
|
|
|
2023-06-03 00:36:28 +02:00
|
|
|
static void editbmesh_build_data(Depsgraph *depsgraph,
|
2022-02-14 19:05:54 +01:00
|
|
|
const Scene *scene,
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
Object *obedit,
|
|
|
|
BMEditMesh *em,
|
|
|
|
CustomData_MeshMasks *dataMask)
|
- shuffled editmesh derived function name/function
- added ModifierTypeInfo.freeData function
- added modifier_{new,free] utility function
- added ccgSubSurf_getUseAgeCounts to query info
- removed subsurf modifier faking (ME_SUBSURF flag is no
longer valid). subsurf modifier gets converted on file load
although there is obscure linked mesh situation where this
can go wrong, will fix shortly. this also means that some
places in the code that test/copy subsurf settings are broken
for the time being.
- shuffled modifier calculation to be simpler. note that
all modifiers are currently disabled in editmode (including
subsurf). don't worry, will return shortly.
- bug fix, build modifier didn't randomize meshes with only verts
- cleaned up subsurf_ccg and adapted for future editmode modifier
work
- added editmesh.derived{Cage,Final}, not used yet
- added SubsurfModifierData.{mCache,emCache}, will be used to cache
subsurf instead of caching in derivedmesh itself
- removed old subsurf buttons
- added do_modifiers_buttons to handle modifier events
- removed count_object counting of modifier (subsurfed) objects...
this would be nice to add back at some point but requires care.
probably requires rewrite of counting system.
New feature: Incremental Subsurf in Object Mode
The previous release introduce incremental subsurf calculation during
editmode but it was not turned on during object mode. In general it
does not make sense to have it always enabled during object mode because
it requires caching a fair amount of information about the mesh which
is a waste of memory unless the mesh is often recalculated.
However, for mesh's that have subsurfed armatures for example, or that
have other modifiers so that the mesh is essentially changing on every
frame, it makes a lot of sense to keep the subsurf'd object around and
that is what the new incremental subsurf modifier toggle is for. The
intent is that the user will enable this option for (a) a mesh that is
currently under active editing or (b) a mesh that is heavily updated
in the scene, such as a character.
I will try to write more about this feature for release, because it
has advantages and disadvantages that are not immediately obvious (the
first user reaction will be to turn it on for ever object, which is
probably not correct).
2005-07-21 22:30:33 +02:00
|
|
|
{
|
2022-01-11 15:42:07 +01:00
|
|
|
Mesh *mesh = static_cast<Mesh *>(obedit->data);
|
2018-10-09 06:04:51 +02:00
|
|
|
Mesh *me_cage;
|
|
|
|
Mesh *me_final;
|
2020-12-15 12:42:10 +01:00
|
|
|
GeometrySet *non_mesh_components;
|
2018-10-09 06:04:51 +02:00
|
|
|
|
2020-12-15 12:42:10 +01:00
|
|
|
editbmesh_calc_modifiers(
|
|
|
|
depsgraph, scene, obedit, em, dataMask, &me_cage, &me_final, &non_mesh_components);
|
2018-10-09 06:04:51 +02:00
|
|
|
|
2022-01-11 15:42:07 +01:00
|
|
|
/* The modifier stack result is expected to share edit mesh pointer with the input.
|
|
|
|
* This is similar `mesh_calc_finalize()`. */
|
|
|
|
BKE_mesh_free_editmesh(me_final);
|
|
|
|
BKE_mesh_free_editmesh(me_cage);
|
|
|
|
me_final->edit_mesh = me_cage->edit_mesh = em;
|
|
|
|
|
|
|
|
/* Object has edit_mesh but is not in edit mode (object shares mesh datablock with another object
|
|
|
|
* with is in edit mode).
|
|
|
|
* Convert edit mesh to mesh until the draw manager can draw mesh wrapper which is not in the
|
|
|
|
* edit mode. */
|
|
|
|
if (!(obedit->mode & OB_MODE_EDIT)) {
|
|
|
|
BKE_mesh_wrapper_ensure_mdata(me_final);
|
|
|
|
if (me_final != me_cage) {
|
|
|
|
BKE_mesh_wrapper_ensure_mdata(me_cage);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-10-13 03:55:26 +02:00
|
|
|
const bool is_mesh_eval_owned = (me_final != mesh->runtime->mesh_eval);
|
2022-01-11 15:42:07 +01:00
|
|
|
BKE_object_eval_assign_data(obedit, &me_final->id, is_mesh_eval_owned);
|
|
|
|
|
2022-11-03 15:48:54 +01:00
|
|
|
/* Make sure that drivers can target shapekey properties.
|
|
|
|
* Note that this causes a potential inconsistency, as the shapekey may have a
|
|
|
|
* different topology than the evaluated mesh. */
|
|
|
|
BLI_assert(mesh->key == nullptr || DEG_is_evaluated_id(&mesh->key->id));
|
|
|
|
me_final->key = mesh->key;
|
|
|
|
|
2023-11-15 18:46:07 +01:00
|
|
|
obedit->runtime->editmesh_eval_cage = me_cage;
|
2022-01-11 15:42:07 +01:00
|
|
|
|
2023-11-15 18:46:07 +01:00
|
|
|
obedit->runtime->geometry_set_eval = non_mesh_components;
|
2015-07-02 08:20:22 +02:00
|
|
|
|
2022-01-11 15:42:07 +01:00
|
|
|
BKE_object_boundbox_calc_from_mesh(obedit, me_final);
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
|
2023-11-15 18:46:07 +01:00
|
|
|
obedit->runtime->last_data_mask = *dataMask;
|
2005-07-19 04:36:21 +02:00
|
|
|
}
|
|
|
|
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
static void object_get_datamask(const Depsgraph *depsgraph,
|
|
|
|
Object *ob,
|
|
|
|
CustomData_MeshMasks *r_mask,
|
|
|
|
bool *r_need_mapping)
|
2013-05-01 16:34:12 +02:00
|
|
|
{
|
2022-09-14 21:33:51 +02:00
|
|
|
Scene *scene = DEG_get_evaluated_scene(depsgraph);
|
2018-04-06 12:07:27 +02:00
|
|
|
ViewLayer *view_layer = DEG_get_evaluated_view_layer(depsgraph);
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
|
|
|
|
DEG_get_customdata_mask_for_object(depsgraph, ob, r_mask);
|
2015-06-04 17:39:43 +02:00
|
|
|
|
2015-07-02 08:20:22 +02:00
|
|
|
if (r_need_mapping) {
|
|
|
|
*r_need_mapping = false;
|
|
|
|
}
|
2013-05-01 16:34:12 +02:00
|
|
|
|
2019-05-24 10:48:19 +02:00
|
|
|
/* Must never access original objects when dependency graph is not active: it might be already
|
|
|
|
* freed. */
|
2019-05-27 12:39:26 +02:00
|
|
|
if (!DEG_is_active(depsgraph)) {
|
2019-05-24 10:48:19 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2022-09-14 21:33:51 +02:00
|
|
|
BKE_view_layer_synced_ensure(scene, view_layer);
|
|
|
|
Object *actob = BKE_view_layer_active_object_get(view_layer);
|
|
|
|
if (actob) {
|
|
|
|
actob = DEG_get_original_object(actob);
|
|
|
|
}
|
2018-06-19 18:29:40 +02:00
|
|
|
if (DEG_get_original_object(ob) == actob) {
|
2018-12-01 10:12:18 +01:00
|
|
|
bool editing = BKE_paint_select_face_test(actob);
|
2015-06-04 17:39:43 +02:00
|
|
|
|
|
|
|
/* weight paint and face select need original indices because of selection buffer drawing */
|
2015-07-02 08:20:22 +02:00
|
|
|
if (r_need_mapping) {
|
2018-04-05 18:20:27 +02:00
|
|
|
*r_need_mapping = (editing || (ob->mode & (OB_MODE_WEIGHT_PAINT | OB_MODE_VERTEX_PAINT)));
|
2015-07-02 08:20:22 +02:00
|
|
|
}
|
2015-06-04 17:39:43 +02:00
|
|
|
|
2023-11-09 23:24:19 +01:00
|
|
|
/* Check if we need #MTFace & loop-color due to face select or texture paint. */
|
2018-04-05 18:20:27 +02:00
|
|
|
if ((ob->mode & OB_MODE_TEXTURE_PAINT) || editing) {
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
r_mask->lmask |= CD_MASK_PROP_FLOAT2 | CD_MASK_PROP_BYTE_COLOR;
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
r_mask->fmask |= CD_MASK_MTFACE;
|
2013-05-01 16:34:12 +02:00
|
|
|
}
|
|
|
|
|
2023-09-03 13:35:03 +02:00
|
|
|
/* Check if we need mcols due to vertex paint or weight-paint. */
|
2018-04-05 18:20:27 +02:00
|
|
|
if (ob->mode & OB_MODE_VERTEX_PAINT) {
|
2022-04-20 16:10:10 +02:00
|
|
|
r_mask->lmask |= CD_MASK_PROP_BYTE_COLOR;
|
2013-05-01 16:34:12 +02:00
|
|
|
}
|
|
|
|
|
2018-10-09 13:21:23 +02:00
|
|
|
if (ob->mode & OB_MODE_WEIGHT_PAINT) {
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
r_mask->vmask |= CD_MASK_MDEFORMVERT;
|
2018-10-09 13:21:23 +02:00
|
|
|
}
|
|
|
|
|
2019-04-22 01:39:35 +02:00
|
|
|
if (ob->mode & OB_MODE_EDIT) {
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
r_mask->vmask |= CD_MASK_MVERT_SKIN;
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
2013-05-01 16:34:12 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-06-03 00:36:28 +02:00
|
|
|
void makeDerivedMesh(Depsgraph *depsgraph,
|
2022-02-14 19:05:54 +01:00
|
|
|
const Scene *scene,
|
2018-04-06 12:07:27 +02:00
|
|
|
Object *ob,
|
2019-03-27 19:07:16 +01:00
|
|
|
const CustomData_MeshMasks *dataMask)
|
2005-07-19 04:36:21 +02:00
|
|
|
{
|
2022-01-11 15:42:07 +01:00
|
|
|
BLI_assert(ob->type == OB_MESH);
|
|
|
|
|
|
|
|
/* Evaluated meshes aren't supposed to be created on original instances. If you do,
|
2023-02-12 04:37:16 +01:00
|
|
|
* they aren't cleaned up properly on mode switch, causing crashes, e.g #58150. */
|
2022-01-11 15:42:07 +01:00
|
|
|
BLI_assert(ob->id.tag & LIB_TAG_COPIED_ON_WRITE);
|
|
|
|
|
|
|
|
BKE_object_free_derived_caches(ob);
|
|
|
|
if (DEG_is_active(depsgraph)) {
|
2022-09-12 19:48:35 +02:00
|
|
|
BKE_sculpt_update_object_before_eval(ob);
|
2022-01-11 15:42:07 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* NOTE: Access the `edit_mesh` after freeing the derived caches, so that `ob->data` is restored
|
|
|
|
* to the pre-evaluated state. This is because the evaluated state is not necessarily sharing the
|
|
|
|
* `edit_mesh` pointer with the input. For example, if the object is first evaluated in the
|
|
|
|
* object mode, and then user in another scene moves object to edit mode. */
|
|
|
|
BMEditMesh *em = ((Mesh *)ob->data)->edit_mesh;
|
|
|
|
|
2015-07-02 08:20:22 +02:00
|
|
|
bool need_mapping;
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
CustomData_MeshMasks cddata_masks = *dataMask;
|
|
|
|
object_get_datamask(depsgraph, ob, &cddata_masks, &need_mapping);
|
2013-05-01 16:34:12 +02:00
|
|
|
|
2008-12-31 18:11:42 +01:00
|
|
|
if (em) {
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
editbmesh_build_data(depsgraph, scene, ob, em, &cddata_masks);
|
2012-03-24 07:18:31 +01:00
|
|
|
}
|
|
|
|
else {
|
2019-03-27 19:07:16 +01:00
|
|
|
mesh_build_data(depsgraph, scene, ob, &cddata_masks, need_mapping);
|
- shuffled editmesh derived function name/function
- added ModifierTypeInfo.freeData function
- added modifier_{new,free] utility function
- added ccgSubSurf_getUseAgeCounts to query info
- removed subsurf modifier faking (ME_SUBSURF flag is no
longer valid). subsurf modifier gets converted on file load
although there is obscure linked mesh situation where this
can go wrong, will fix shortly. this also means that some
places in the code that test/copy subsurf settings are broken
for the time being.
- shuffled modifier calculation to be simpler. note that
all modifiers are currently disabled in editmode (including
subsurf). don't worry, will return shortly.
- bug fix, build modifier didn't randomize meshes with only verts
- cleaned up subsurf_ccg and adapted for future editmode modifier
work
- added editmesh.derived{Cage,Final}, not used yet
- added SubsurfModifierData.{mCache,emCache}, will be used to cache
subsurf instead of caching in derivedmesh itself
- removed old subsurf buttons
- added do_modifiers_buttons to handle modifier events
- removed count_object counting of modifier (subsurfed) objects...
this would be nice to add back at some point but requires care.
probably requires rewrite of counting system.
New feature: Incremental Subsurf in Object Mode
The previous release introduce incremental subsurf calculation during
editmode but it was not turned on during object mode. In general it
does not make sense to have it always enabled during object mode because
it requires caching a fair amount of information about the mesh which
is a waste of memory unless the mesh is often recalculated.
However, for mesh's that have subsurfed armatures for example, or that
have other modifiers so that the mesh is essentially changing on every
frame, it makes a lot of sense to keep the subsurf'd object around and
that is what the new incremental subsurf modifier toggle is for. The
intent is that the user will enable this option for (a) a mesh that is
currently under active editing or (b) a mesh that is heavily updated
in the scene, such as a character.
I will try to write more about this feature for release, because it
has advantages and disadvantages that are not immediately obvious (the
first user reaction will be to turn it on for ever object, which is
probably not correct).
2005-07-21 22:30:33 +02:00
|
|
|
}
|
2005-07-19 04:36:21 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/***/
|
|
|
|
|
2023-06-03 00:36:28 +02:00
|
|
|
Mesh *mesh_get_eval_deform(Depsgraph *depsgraph,
|
2022-02-14 19:05:54 +01:00
|
|
|
const Scene *scene,
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
Object *ob,
|
|
|
|
const CustomData_MeshMasks *dataMask)
|
2018-06-01 12:34:50 +02:00
|
|
|
{
|
2022-01-11 15:42:07 +01:00
|
|
|
BMEditMesh *em = ((Mesh *)ob->data)->edit_mesh;
|
|
|
|
if (em != nullptr) {
|
|
|
|
/* There is no such a concept as deformed mesh in edit mode.
|
|
|
|
* Explicitly disallow this request so that the evaluated result is not modified with evaluated
|
|
|
|
* result from the wrong mode. */
|
|
|
|
BLI_assert_msg(0, "Request of derformed mesh of object which is in edit mode");
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
2018-12-03 13:22:19 +01:00
|
|
|
/* This function isn't thread-safe and can't be used during evaluation. */
|
2019-10-10 11:03:58 +02:00
|
|
|
BLI_assert(DEG_is_evaluating(depsgraph) == false);
|
2018-12-03 13:22:19 +01:00
|
|
|
|
|
|
|
/* Evaluated meshes aren't supposed to be created on original instances. If you do,
|
2023-02-12 04:37:16 +01:00
|
|
|
* they aren't cleaned up properly on mode switch, causing crashes, e.g #58150. */
|
2018-12-03 13:22:19 +01:00
|
|
|
BLI_assert(ob->id.tag & LIB_TAG_COPIED_ON_WRITE);
|
|
|
|
|
2018-06-01 12:34:50 +02:00
|
|
|
/* if there's no derived mesh or the last data mask used doesn't include
|
|
|
|
* the data we need, rebuild the derived mesh
|
|
|
|
*/
|
|
|
|
bool need_mapping;
|
|
|
|
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
CustomData_MeshMasks cddata_masks = *dataMask;
|
|
|
|
object_get_datamask(depsgraph, ob, &cddata_masks, &need_mapping);
|
2018-06-01 12:34:50 +02:00
|
|
|
|
2023-11-15 18:46:07 +01:00
|
|
|
if (!ob->runtime->mesh_deform_eval ||
|
|
|
|
!CustomData_MeshMasks_are_matching(&(ob->runtime->last_data_mask), &cddata_masks) ||
|
|
|
|
(need_mapping && !ob->runtime->last_need_mapping))
|
2018-12-03 16:09:45 +01:00
|
|
|
{
|
2023-11-15 18:46:07 +01:00
|
|
|
CustomData_MeshMasks_update(&cddata_masks, &ob->runtime->last_data_mask);
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
mesh_build_data(
|
2023-11-15 18:46:07 +01:00
|
|
|
depsgraph, scene, ob, &cddata_masks, need_mapping || ob->runtime->last_need_mapping);
|
2018-06-01 12:34:50 +02:00
|
|
|
}
|
|
|
|
|
2023-11-15 18:46:07 +01:00
|
|
|
return ob->runtime->mesh_deform_eval;
|
2018-06-01 12:34:50 +02:00
|
|
|
}
|
|
|
|
|
2020-08-18 12:58:48 +02:00
|
|
|
Mesh *mesh_create_eval_final(Depsgraph *depsgraph,
|
2022-02-14 19:05:54 +01:00
|
|
|
const Scene *scene,
|
2020-08-20 08:09:48 +02:00
|
|
|
Object *ob,
|
|
|
|
const CustomData_MeshMasks *dataMask)
|
2018-10-12 09:05:26 +02:00
|
|
|
{
|
2021-12-02 17:20:22 +01:00
|
|
|
Mesh *result;
|
2020-12-15 12:42:10 +01:00
|
|
|
mesh_calc_modifiers(
|
2022-04-21 19:02:13 +02:00
|
|
|
depsgraph, scene, ob, true, false, dataMask, false, false, nullptr, &result, nullptr);
|
2021-12-02 17:20:22 +01:00
|
|
|
return result;
|
2018-10-12 09:05:26 +02:00
|
|
|
}
|
2008-07-28 13:01:34 +02:00
|
|
|
|
2018-12-04 23:47:13 +01:00
|
|
|
Mesh *mesh_create_eval_no_deform(Depsgraph *depsgraph,
|
2022-02-14 19:05:54 +01:00
|
|
|
const Scene *scene,
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
Object *ob,
|
2019-03-27 19:07:16 +01:00
|
|
|
const CustomData_MeshMasks *dataMask)
|
2005-07-17 03:18:59 +02:00
|
|
|
{
|
2021-12-02 17:20:22 +01:00
|
|
|
Mesh *result;
|
2020-12-15 12:42:10 +01:00
|
|
|
mesh_calc_modifiers(
|
2022-04-21 19:02:13 +02:00
|
|
|
depsgraph, scene, ob, false, false, dataMask, false, false, nullptr, &result, nullptr);
|
2021-12-02 17:20:22 +01:00
|
|
|
return result;
|
2018-12-04 23:47:13 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
Mesh *mesh_create_eval_no_deform_render(Depsgraph *depsgraph,
|
2022-02-14 19:05:54 +01:00
|
|
|
const Scene *scene,
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
Object *ob,
|
2019-03-27 19:07:16 +01:00
|
|
|
const CustomData_MeshMasks *dataMask)
|
2018-12-04 23:47:13 +01:00
|
|
|
{
|
2021-12-02 17:20:22 +01:00
|
|
|
Mesh *result;
|
2020-12-15 12:42:10 +01:00
|
|
|
mesh_calc_modifiers(
|
2022-04-21 19:02:13 +02:00
|
|
|
depsgraph, scene, ob, false, false, dataMask, false, false, nullptr, &result, nullptr);
|
2021-12-02 17:20:22 +01:00
|
|
|
return result;
|
2005-07-19 02:21:01 +02:00
|
|
|
}
|
2005-04-04 05:38:21 +02:00
|
|
|
|
2005-07-19 02:21:01 +02:00
|
|
|
/***/
|
|
|
|
|
2023-06-03 00:36:28 +02:00
|
|
|
Mesh *editbmesh_get_eval_cage(Depsgraph *depsgraph,
|
2022-02-14 19:05:54 +01:00
|
|
|
const Scene *scene,
|
2018-04-06 12:07:27 +02:00
|
|
|
Object *obedit,
|
|
|
|
BMEditMesh *em,
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
const CustomData_MeshMasks *dataMask)
|
2005-03-28 07:58:43 +02:00
|
|
|
{
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
CustomData_MeshMasks cddata_masks = *dataMask;
|
|
|
|
|
2006-12-05 18:42:03 +01:00
|
|
|
/* if there's no derived mesh or the last data mask used doesn't include
|
|
|
|
* the data we need, rebuild the derived mesh
|
|
|
|
*/
|
2020-12-14 13:00:28 +01:00
|
|
|
object_get_datamask(depsgraph, obedit, &cddata_masks, nullptr);
|
2013-05-01 16:34:12 +02:00
|
|
|
|
2023-11-15 18:46:07 +01:00
|
|
|
if (!obedit->runtime->editmesh_eval_cage ||
|
|
|
|
!CustomData_MeshMasks_are_matching(&(obedit->runtime->last_data_mask), &cddata_masks))
|
2022-01-11 15:42:07 +01:00
|
|
|
{
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
editbmesh_build_data(depsgraph, scene, obedit, em, &cddata_masks);
|
2012-04-28 08:31:57 +02:00
|
|
|
}
|
2005-03-28 07:58:43 +02:00
|
|
|
|
2023-11-15 18:46:07 +01:00
|
|
|
return obedit->runtime->editmesh_eval_cage;
|
2005-03-28 07:58:43 +02:00
|
|
|
}
|
2005-08-06 22:44:59 +02:00
|
|
|
|
2023-06-03 00:36:28 +02:00
|
|
|
Mesh *editbmesh_get_eval_cage_from_orig(Depsgraph *depsgraph,
|
2022-02-14 19:05:54 +01:00
|
|
|
const Scene *scene,
|
2018-12-05 23:38:08 +01:00
|
|
|
Object *obedit,
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
const CustomData_MeshMasks *dataMask)
|
2018-12-05 23:38:08 +01:00
|
|
|
{
|
|
|
|
BLI_assert((obedit->id.tag & LIB_TAG_COPIED_ON_WRITE) == 0);
|
2022-02-14 19:05:54 +01:00
|
|
|
const Scene *scene_eval = (const Scene *)DEG_get_evaluated_id(depsgraph, (ID *)&scene->id);
|
2018-12-05 23:38:08 +01:00
|
|
|
Object *obedit_eval = (Object *)DEG_get_evaluated_id(depsgraph, &obedit->id);
|
|
|
|
BMEditMesh *em_eval = BKE_editmesh_from_object(obedit_eval);
|
|
|
|
return editbmesh_get_eval_cage(depsgraph, scene_eval, obedit_eval, em_eval, dataMask);
|
|
|
|
}
|
|
|
|
|
2014-08-01 15:42:17 +02:00
|
|
|
/***/
|
|
|
|
|
2014-09-04 09:53:10 +02:00
|
|
|
/* same as above but for vert coords */
|
2020-12-14 13:00:28 +01:00
|
|
|
struct MappedUserData {
|
2014-09-04 09:53:10 +02:00
|
|
|
float (*vertexcos)[3];
|
|
|
|
BLI_bitmap *vertex_visit;
|
2020-12-14 13:00:28 +01:00
|
|
|
};
|
2014-09-04 09:53:10 +02:00
|
|
|
|
2023-07-27 04:04:18 +02:00
|
|
|
static void make_vertexcos__mapFunc(void *user_data,
|
2015-07-02 08:20:22 +02:00
|
|
|
int index,
|
|
|
|
const float co[3],
|
2022-10-12 01:27:27 +02:00
|
|
|
const float /*no*/[3])
|
2014-09-04 09:53:10 +02:00
|
|
|
{
|
2023-07-27 04:04:18 +02:00
|
|
|
MappedUserData *mappedData = (MappedUserData *)user_data;
|
2014-09-04 09:53:10 +02:00
|
|
|
|
|
|
|
if (BLI_BITMAP_TEST(mappedData->vertex_visit, index) == 0) {
|
|
|
|
/* we need coord from prototype vertex, not from copies,
|
|
|
|
* assume they stored in the beginning of vertex array stored in DM
|
|
|
|
* (mirror modifier for eg does this) */
|
|
|
|
copy_v3_v3(mappedData->vertexcos[index], co);
|
|
|
|
BLI_BITMAP_ENABLE(mappedData->vertex_visit, index);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-11-16 18:29:52 +01:00
|
|
|
void mesh_get_mapped_verts_coords(Mesh *me_eval, blender::MutableSpan<blender::float3> r_cos)
|
2014-09-04 09:53:10 +02:00
|
|
|
{
|
2022-10-13 03:55:26 +02:00
|
|
|
if (me_eval->runtime->deformed_only == false) {
|
2023-07-27 04:04:18 +02:00
|
|
|
MappedUserData user_data;
|
2023-11-16 18:29:52 +01:00
|
|
|
r_cos.fill(float3(0));
|
|
|
|
user_data.vertexcos = reinterpret_cast<float(*)[3]>(r_cos.data());
|
|
|
|
user_data.vertex_visit = BLI_BITMAP_NEW(r_cos.size(), "vertexcos flags");
|
2023-07-27 04:04:18 +02:00
|
|
|
BKE_mesh_foreach_mapped_vert(me_eval, make_vertexcos__mapFunc, &user_data, MESH_FOREACH_NOP);
|
|
|
|
MEM_freeN(user_data.vertex_visit);
|
2014-09-04 09:53:10 +02:00
|
|
|
}
|
|
|
|
else {
|
2023-11-16 18:29:52 +01:00
|
|
|
r_cos.copy_from(me_eval->vert_positions());
|
2014-09-04 09:53:10 +02:00
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-11 09:53:52 +02:00
|
|
|
static void mesh_init_origspace(Mesh *mesh)
|
|
|
|
{
|
|
|
|
const float default_osf[4][2] = {{0, 0}, {1, 0}, {1, 1}, {0, 1}};
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-01-14 00:21:20 +01:00
|
|
|
OrigSpaceLoop *lof_array = (OrigSpaceLoop *)CustomData_get_layer_for_write(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh->loop_data, CD_ORIGSPACE_MLOOP, mesh->totloop);
|
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 06:10:43 +01:00
|
|
|
const Span<float3> positions = mesh->vert_positions();
|
2023-07-24 22:06:55 +02:00
|
|
|
const blender::OffsetIndices faces = mesh->faces();
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
const Span<int> corner_verts = mesh->corner_verts();
|
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 18:56:34 +02:00
|
|
|
|
2023-03-03 16:50:54 +01:00
|
|
|
int j, k;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-12-14 13:00:28 +01:00
|
|
|
blender::Vector<blender::float2, 64> vcos_2d;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-24 22:06:55 +02:00
|
|
|
for (const int i : faces.index_range()) {
|
|
|
|
const blender::IndexRange face = faces[i];
|
|
|
|
OrigSpaceLoop *lof = lof_array + face.start();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-24 22:06:55 +02:00
|
|
|
if (ELEM(face.size(), 3, 4)) {
|
|
|
|
for (j = 0; j < face.size(); j++, lof++) {
|
2018-05-11 09:53:52 +02:00
|
|
|
copy_v2_v2(lof->uv, default_osf[j]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
2023-03-12 22:29:15 +01:00
|
|
|
float co[3];
|
2018-05-11 09:53:52 +02:00
|
|
|
float mat[3][3];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-11 09:53:52 +02:00
|
|
|
float min[2] = {FLT_MAX, FLT_MAX}, max[2] = {-FLT_MAX, -FLT_MAX};
|
|
|
|
float translate[2], scale[2];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-24 22:06:55 +02:00
|
|
|
const float3 p_nor = blender::bke::mesh::face_normal_calc(positions,
|
|
|
|
corner_verts.slice(face));
|
2023-03-12 22:29:15 +01:00
|
|
|
|
2018-05-11 09:53:52 +02:00
|
|
|
axis_dominant_v3_to_m3(mat, p_nor);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-24 22:06:55 +02:00
|
|
|
vcos_2d.resize(face.size());
|
|
|
|
for (j = 0; j < face.size(); j++) {
|
|
|
|
mul_v3_m3v3(co, mat, positions[corner_verts[face[j]]]);
|
2018-05-11 09:53:52 +02:00
|
|
|
copy_v2_v2(vcos_2d[j], co);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-11 09:53:52 +02:00
|
|
|
for (k = 0; k < 2; k++) {
|
2019-04-22 01:39:35 +02:00
|
|
|
if (co[k] > max[k]) {
|
2018-05-11 09:53:52 +02:00
|
|
|
max[k] = co[k];
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
|
|
|
else if (co[k] < min[k]) {
|
2018-05-11 09:53:52 +02:00
|
|
|
min[k] = co[k];
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-11 09:53:52 +02:00
|
|
|
/* Brings min to (0, 0). */
|
|
|
|
negate_v2_v2(translate, min);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-11 09:53:52 +02:00
|
|
|
/* Scale will bring max to (1, 1). */
|
|
|
|
sub_v2_v2v2(scale, max, min);
|
2019-04-22 01:39:35 +02:00
|
|
|
if (scale[0] == 0.0f) {
|
2018-05-11 09:53:52 +02:00
|
|
|
scale[0] = 1e-9f;
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
|
|
|
if (scale[1] == 0.0f) {
|
2018-05-11 09:53:52 +02:00
|
|
|
scale[1] = 1e-9f;
|
2019-04-22 01:39:35 +02:00
|
|
|
}
|
2018-05-11 09:53:52 +02:00
|
|
|
invert_v2(scale);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-27 04:07:07 +02:00
|
|
|
/* Finally, transform all vcos_2d into ((0, 0), (1, 1))
|
|
|
|
* square and assign them as origspace. */
|
2023-07-24 22:06:55 +02:00
|
|
|
for (j = 0; j < face.size(); j++, lof++) {
|
2018-05-11 09:53:52 +02:00
|
|
|
add_v2_v2v2(lof->uv, vcos_2d[j], translate);
|
|
|
|
mul_v2_v2(lof->uv, scale);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-22 17:53:18 +02:00
|
|
|
BKE_mesh_tessface_clear(mesh);
|
2018-05-11 09:53:52 +02:00
|
|
|
}
|