tornavis/source/blender/blenkernel/intern/DerivedMesh.cc

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

2085 lines
72 KiB
C++
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0-or-later
* Copyright 2005 Blender Foundation. All rights reserved. */
/** \file
* \ingroup bke
2011-02-27 21:40:57 +01:00
*/
#include <climits>
#include <cstring>
#include "MEM_guardedalloc.h"
#include "DNA_cloth_types.h"
#include "DNA_customdata_types.h"
#include "DNA_key_types.h"
#include "DNA_material_types.h"
#include "DNA_mesh_types.h"
#include "DNA_meshdata_types.h"
#include "DNA_object_types.h"
#include "DNA_scene_types.h"
Fix T47038: Particles in Particle Edit Mode get added in completely wrong location. It also fixes another issue (crash) related to symmetric editing. Quite involved, we (try to!) fix complete broken logic of parts of particle code, which would use poly index as tessface one (or vice-versa). Issue most probably goes back to BMesh integration time... This patch mostly fixes particle editing mode: - Adding/removing particles when using generative modifiers (like subsurf) should now work. - Adding/removing particles with a non-tessellated mesh (i.e. one having ngons) should also mostly work. - X-axis-mirror-editing particles over ngons does not really work, not sure why currently. - All this in both 'modes' (with or without using modifier stack for particles). Tech side: - Store a deformed-only DM in particle modifier data. - Rename existing DM to make it clear it's a final one. - Use deformed-only DM's tessface2poly mapping to 'solve' poly/tessface mismatches. - Make (part of) mirror-editing code able to use a DM instead of raw mesh, so that we can mirror based on final DM when editing particles using modifier stack (mandatory, since there is no way currently to find orig tessface from an final DM tessface index). Note that this patch is not really nice and clean (current particles are beyond hope on this side anyway), it's more like some urgency bandage. Whole crap needs complete rewrite anyway, BMesh's polygons make it really hard to work with current system (and looptri would not help much here). Also, did not test everything possibly affected by those changes, so it needs some users' testing & validation too. Reviewers: psy-fi Subscribers: dfelinto, eyecandy Maniphest Tasks: T47038 Differential Revision: https://developer.blender.org/D1685
2016-01-04 12:19:45 +01:00
#include "BLI_array.h"
#include "BLI_bitmap.h"
#include "BLI_blenlib.h"
2011-10-22 03:53:35 +02:00
#include "BLI_linklist.h"
#include "BLI_math.h"
BLI: Refactor vector types & functions to use templates This patch implements the vector types (i.e:`float2`) by making heavy usage of templating. All vector functions are now outside of the vector classes (inside the `blender::math` namespace) and are not vector size dependent for the most part. In the ongoing effort to make shaders less GL centric, we are aiming to share more code between GLSL and C++ to avoid code duplication. ####Motivations: - We are aiming to share UBO and SSBO structures between GLSL and C++. This means we will use many of the existing vector types and others we currently don't have (uintX, intX). All these variations were asking for many more code duplication. - Deduplicate existing code which is duplicated for each vector size. - We also want to share small functions. Which means that vector functions should be static and not in the class namespace. - Reduce friction to use these types in new projects due to their incompleteness. - The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a bit of a let down. Most clases are incomplete, out of sync with each others with different codestyles, and some functions that should be static are not (i.e: `float3::reflect()`). ####Upsides: - Still support `.x, .y, .z, .w` for readability. - Compact, readable and easilly extendable. - All of the vector functions are available for all the vectors types and can be restricted to certain types. Also template specialization let us define exception for special class (like mpq). - With optimization ON, the compiler unroll the loops and performance is the same. ####Downsides: - Might impact debugability. Though I would arge that the bugs are rarelly caused by the vector class itself (since the operations are quite trivial) but by the type conversions. - Might impact compile time. I did not saw a significant impact since the usage is not really widespread. - Functions needs to be rewritten to support arbitrary vector length. For instance, one can't call `len_squared_v3v3` in `math::length_squared()` and call it a day. - Type cast does not work with the template version of the `math::` vector functions. Meaning you need to manually cast `float *` and `(float *)[3]` to `float3` for the function calls. i.e: `math::distance_squared(float3(nearest.co), positions[i]);` - Some parts might loose in readability: `float3::dot(v1.normalized(), v2.normalized())` becoming `math::dot(math::normalize(v1), math::normalize(v2))` But I propose, when appropriate, to use `using namespace blender::math;` on function local or file scope to increase readability. `dot(normalize(v1), normalize(v2))` ####Consideration: - Include back `.length()` method. It is quite handy and is more C++ oriented. - I considered the GLM library as a candidate for replacement. It felt like too much for what we need and would be difficult to extend / modify to our needs. - I used Macros to reduce code in operators declaration and potential copy paste bugs. This could reduce debugability and could be reverted. - This touches `delaunay_2d.cc` and the intersection code. I would like to know @howardt opinion on the matter. - The `noexcept` on the copy constructor of `mpq(2|3)` is being removed. But according to @JacquesLucke it is not a real problem for now. I would like to give a huge thanks to @JacquesLucke who helped during this and pushed me to reduce the duplication further. Reviewed By: brecht, sergey, JacquesLucke Differential Revision: https://developer.blender.org/D13791
2022-01-12 12:57:07 +01:00
#include "BLI_math_vec_types.hh"
#include "BLI_task.h"
#include "BLI_task.hh"
#include "BLI_utildefines.h"
#include "BLI_vector.hh"
#include "BKE_DerivedMesh.h"
#include "BKE_bvhutils.h"
#include "BKE_colorband.h"
#include "BKE_deform.h"
2013-04-18 19:09:56 +02:00
#include "BKE_editmesh.h"
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
#include "BKE_geometry_set.hh"
#include "BKE_geometry_set_instances.hh"
#include "BKE_key.h"
#include "BKE_layer.h"
#include "BKE_lib_id.h"
#include "BKE_material.h"
#include "BKE_mesh.h"
#include "BKE_mesh_iterators.h"
#include "BKE_mesh_mapping.h"
#include "BKE_mesh_runtime.h"
#include "BKE_mesh_tangent.h"
#include "BKE_mesh_wrapper.h"
#include "BKE_modifier.h"
#include "BKE_multires.h"
#include "BKE_object.h"
#include "BKE_object_deform.h"
#include "BKE_paint.h"
#include "BKE_subdiv_modifier.h"
#include "BLI_sys_types.h" /* for intptr_t support */
#include "BKE_shrinkwrap.h"
2018-04-16 20:45:43 +02:00
#include "DEG_depsgraph.h"
#include "DEG_depsgraph_query.h"
#include "CLG_log.h"
#ifdef WITH_OPENSUBDIV
# include "DNA_userdef_types.h"
#endif
Curves: support deforming curves on surface Curves that are attached to a surface can now follow the surface when it is modified using shape keys or modifiers (but not when the original surface is deformed in edit or sculpt mode). The surface is allowed to be changed in any way that keeps uv maps intact. So deformation is allowed, but also some topology changes like subdivision. The following features are added: * A new `Deform Curves on Surface` node, which deforms curves with attachment information based on the surface object and uv map set in the properties panel. * A new `Add Rest Position` checkbox in the shape keys panel. When checked, a new `rest_position` vector attribute is added to the mesh before shape keys and modifiers are applied. This is necessary to support proper deformation of the curves, but can also be used for other purposes. * The `Add > Curve > Empty Hair` operator now sets up a simple geometry nodes setup that deforms the hair. It also makes sure that the rest position attribute is added to the surface. * A new `Object (Attach Curves to Surface)` operator in the `Set Parent To` (ctrl+P) menu, which attaches existing curves to the surface and sets the surface object as parent. Limitations: * Sculpting the procedurally deformed curves will be implemented separately. * The `Deform Curves on Surface` node is not generic and can only be used for one specific purpose currently. We plan to generalize this more in the future by adding support by exposing more inputs and/or by turning it into a node group. Differential Revision: https://developer.blender.org/D14864
2022-07-08 14:45:48 +02:00
using blender::float3;
using blender::IndexRange;
/* very slow! enable for testing only! */
//#define USE_MODIFIER_VALIDATE
#ifdef USE_MODIFIER_VALIDATE
# define ASSERT_IS_VALID_MESH(mesh) \
(BLI_assert((mesh == nullptr) || (BKE_mesh_is_valid(mesh) == true)))
#else
# define ASSERT_IS_VALID_MESH(mesh)
#endif
static ThreadRWMutex loops_cache_lock = PTHREAD_RWLOCK_INITIALIZER;
static void mesh_init_origspace(Mesh *mesh);
static void editbmesh_calc_modifier_final_normals(Mesh *mesh_final,
const CustomData_MeshMasks *final_datamask);
static void editbmesh_calc_modifier_final_normals_or_defer(
Mesh *mesh_final, const CustomData_MeshMasks *final_datamask);
/* -------------------------------------------------------------------- */
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
static MVert *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
{
MVert *mvert = (MVert *)CustomData_get_layer(&dm->vertData, CD_MVERT);
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
if (!mvert) {
mvert = (MVert *)CustomData_add_layer(
2022-08-30 21:54:53 +02:00
&dm->vertData, CD_MVERT, CD_SET_DEFAULT, nullptr, dm->getNumVerts(dm));
CustomData_set_layer_flag(&dm->vertData, CD_MVERT, CD_FLAG_TEMPORARY);
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->copyVertArray(dm, mvert);
}
return mvert;
}
static MEdge *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
{
MEdge *medge = (MEdge *)CustomData_get_layer(&dm->edgeData, CD_MEDGE);
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
if (!medge) {
medge = (MEdge *)CustomData_add_layer(
2022-08-30 21:54:53 +02:00
&dm->edgeData, CD_MEDGE, CD_SET_DEFAULT, nullptr, dm->getNumEdges(dm));
CustomData_set_layer_flag(&dm->edgeData, CD_MEDGE, CD_FLAG_TEMPORARY);
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->copyEdgeArray(dm, medge);
}
return medge;
}
static MLoop *dm_getLoopArray(DerivedMesh *dm)
{
MLoop *mloop = (MLoop *)CustomData_get_layer(&dm->loopData, CD_MLOOP);
if (!mloop) {
mloop = (MLoop *)CustomData_add_layer(
2022-08-30 21:54:53 +02:00
&dm->loopData, CD_MLOOP, CD_SET_DEFAULT, nullptr, dm->getNumLoops(dm));
CustomData_set_layer_flag(&dm->loopData, CD_MLOOP, CD_FLAG_TEMPORARY);
dm->copyLoopArray(dm, mloop);
}
return mloop;
}
static MPoly *dm_getPolyArray(DerivedMesh *dm)
{
MPoly *mpoly = (MPoly *)CustomData_get_layer(&dm->polyData, CD_MPOLY);
if (!mpoly) {
mpoly = (MPoly *)CustomData_add_layer(
2022-08-30 21:54:53 +02:00
&dm->polyData, CD_MPOLY, CD_SET_DEFAULT, nullptr, dm->getNumPolys(dm));
CustomData_set_layer_flag(&dm->polyData, CD_MPOLY, CD_FLAG_TEMPORARY);
dm->copyPolyArray(dm, mpoly);
}
return mpoly;
}
static MVert *dm_dupVertArray(DerivedMesh *dm)
{
MVert *tmp = (MVert *)MEM_malloc_arrayN(
dm->getNumVerts(dm), sizeof(*tmp), "dm_dupVertArray tmp");
if (tmp) {
dm->copyVertArray(dm, tmp);
}
return tmp;
}
static MEdge *dm_dupEdgeArray(DerivedMesh *dm)
{
MEdge *tmp = (MEdge *)MEM_malloc_arrayN(
dm->getNumEdges(dm), sizeof(*tmp), "dm_dupEdgeArray tmp");
if (tmp) {
dm->copyEdgeArray(dm, tmp);
}
return tmp;
}
static MLoop *dm_dupLoopArray(DerivedMesh *dm)
{
MLoop *tmp = (MLoop *)MEM_malloc_arrayN(
dm->getNumLoops(dm), sizeof(*tmp), "dm_dupLoopArray tmp");
if (tmp) {
dm->copyLoopArray(dm, tmp);
}
return tmp;
}
static MPoly *dm_dupPolyArray(DerivedMesh *dm)
{
MPoly *tmp = (MPoly *)MEM_malloc_arrayN(
dm->getNumPolys(dm), sizeof(*tmp), "dm_dupPolyArray tmp");
if (tmp) {
dm->copyPolyArray(dm, tmp);
}
return tmp;
}
static int dm_getNumLoopTri(DerivedMesh *dm)
{
const int numlooptris = poly_to_tri_count(dm->getNumPolys(dm), dm->getNumLoops(dm));
BLI_assert(ELEM(dm->looptris.num, 0, numlooptris));
return numlooptris;
}
static const MLoopTri *dm_getLoopTriArray(DerivedMesh *dm)
{
MLoopTri *looptri;
BLI_rw_mutex_lock(&loops_cache_lock, THREAD_LOCK_READ);
looptri = dm->looptris.array;
BLI_rw_mutex_unlock(&loops_cache_lock);
if (looptri != nullptr) {
BLI_assert(dm->getNumLoopTri(dm) == dm->looptris.num);
}
else {
BLI_rw_mutex_lock(&loops_cache_lock, THREAD_LOCK_WRITE);
/* We need to ensure array is still nullptr inside mutex-protected code,
* some other thread might have already recomputed those looptris. */
if (dm->looptris.array == nullptr) {
dm->recalcLoopTri(dm);
}
looptri = dm->looptris.array;
BLI_rw_mutex_unlock(&loops_cache_lock);
}
return looptri;
}
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;
dm->getLoopArray = dm_getLoopArray;
dm->getPolyArray = dm_getPolyArray;
dm->dupVertArray = dm_dupVertArray;
dm->dupEdgeArray = dm_dupEdgeArray;
dm->dupLoopArray = dm_dupLoopArray;
dm->dupPolyArray = dm_dupPolyArray;
dm->getLoopTriArray = dm_getLoopTriArray;
/* subtypes handle getting actual data */
dm->getNumLoopTri = dm_getNumLoopTri;
dm->getVertDataArray = DM_get_vert_data_layer;
dm->getEdgeDataArray = DM_get_edge_data_layer;
dm->getPolyDataArray = DM_get_poly_data_layer;
dm->getLoopDataArray = DM_get_loop_data_layer;
}
void DM_init(DerivedMesh *dm,
DerivedMeshType type,
int numVerts,
int numEdges,
int numTessFaces,
int numLoops,
int numPolys)
{
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;
dm->numTessFaceData = numTessFaces;
dm->numLoopData = numLoops;
dm->numPolyData = numPolys;
DM_init_funcs(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
dm->needsFree = 1;
/* Don't use #CustomData_reset because we don't want to touch custom-data. */
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);
}
void DM_from_template(DerivedMesh *dm,
DerivedMesh *source,
DerivedMeshType type,
int numVerts,
int numEdges,
int numTessFaces,
int numLoops,
int numPolys)
{
const CustomData_MeshMasks *mask = &CD_MASK_DERIVEDMESH;
2022-08-30 21:54:53 +02:00
CustomData_copy(&source->vertData, &dm->vertData, mask->vmask, CD_SET_DEFAULT, numVerts);
CustomData_copy(&source->edgeData, &dm->edgeData, mask->emask, CD_SET_DEFAULT, numEdges);
CustomData_copy(&source->faceData, &dm->faceData, mask->fmask, CD_SET_DEFAULT, numTessFaces);
CustomData_copy(&source->loopData, &dm->loopData, mask->lmask, CD_SET_DEFAULT, numLoops);
CustomData_copy(&source->polyData, &dm->polyData, mask->pmask, CD_SET_DEFAULT, numPolys);
dm->cd_flag = source->cd_flag;
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;
dm->numTessFaceData = numTessFaces;
dm->numLoopData = numLoops;
dm->numPolyData = numPolys;
DM_init_funcs(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
dm->needsFree = 1;
}
bool DM_release(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
if (dm->needsFree) {
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);
MEM_SAFE_FREE(dm->looptris.array);
dm->looptris.num = 0;
dm->looptris.num_alloc = 0;
return true;
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
}
CustomData_free_temporary(&dm->vertData, dm->numVertData);
CustomData_free_temporary(&dm->edgeData, dm->numEdgeData);
CustomData_free_temporary(&dm->faceData, dm->numTessFaceData);
CustomData_free_temporary(&dm->loopData, dm->numLoopData);
CustomData_free_temporary(&dm->polyData, dm->numPolyData);
return false;
}
void DM_DupPolys(DerivedMesh *source, DerivedMesh *target)
{
CustomData_free(&target->loopData, source->numLoopData);
CustomData_free(&target->polyData, source->numPolyData);
CustomData_copy(&source->loopData,
&target->loopData,
CD_MASK_DERIVEDMESH.lmask,
CD_DUPLICATE,
source->numLoopData);
CustomData_copy(&source->polyData,
&target->polyData,
CD_MASK_DERIVEDMESH.pmask,
CD_DUPLICATE,
source->numPolyData);
2009-08-18 22:05:08 +02:00
target->numLoopData = source->numLoopData;
target->numPolyData = source->numPolyData;
2009-08-18 22:05:08 +02:00
if (!CustomData_has_layer(&target->polyData, CD_MPOLY)) {
MPoly *mpoly;
MLoop *mloop;
2009-08-18 22:05:08 +02:00
mloop = source->dupLoopArray(source);
mpoly = source->dupPolyArray(source);
CustomData_add_layer(&target->loopData, CD_MLOOP, CD_ASSIGN, mloop, source->numLoopData);
CustomData_add_layer(&target->polyData, CD_MPOLY, CD_ASSIGN, mpoly, source->numPolyData);
}
}
void DM_ensure_looptri_data(DerivedMesh *dm)
{
const unsigned int totpoly = dm->numPolyData;
const unsigned int totloop = dm->numLoopData;
const int looptris_num = poly_to_tri_count(totpoly, totloop);
BLI_assert(dm->looptris.array_wip == nullptr);
SWAP(MLoopTri *, dm->looptris.array, dm->looptris.array_wip);
if ((looptris_num > dm->looptris.num_alloc) || (looptris_num < dm->looptris.num_alloc * 2) ||
(totpoly == 0)) {
MEM_SAFE_FREE(dm->looptris.array_wip);
dm->looptris.num_alloc = 0;
dm->looptris.num = 0;
}
if (totpoly) {
if (dm->looptris.array_wip == nullptr) {
dm->looptris.array_wip = (MLoopTri *)MEM_malloc_arrayN(
looptris_num, sizeof(*dm->looptris.array_wip), __func__);
dm->looptris.num_alloc = looptris_num;
}
dm->looptris.num = looptris_num;
}
}
void BKE_mesh_runtime_eval_to_meshkey(Mesh *me_deformed, Mesh *me, KeyBlock *kb)
{
/* Just a shallow wrapper around #BKE_keyblock_convert_from_mesh,
* that ensures both evaluated mesh and original one has same number of vertices. */
const int totvert = me_deformed->totvert;
2018-06-17 17:05:51 +02:00
if (totvert == 0 || me->totvert == 0 || me->totvert != totvert) {
return;
}
2018-06-17 17:05:51 +02:00
BKE_keyblock_convert_from_mesh(me_deformed, me->key, kb);
}
void DM_set_only_copy(DerivedMesh *dm, const CustomData_MeshMasks *mask)
{
CustomData_set_only_copy(&dm->vertData, mask->vmask);
CustomData_set_only_copy(&dm->edgeData, mask->emask);
CustomData_set_only_copy(&dm->faceData, mask->fmask);
/* 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
CustomData_set_only_copy(&dm->loopData, mask->lmask);
Custom(&dm->polyData, mask->pmask);
#endif
}
static void mesh_set_only_copy(Mesh *mesh, const CustomData_MeshMasks *mask)
{
CustomData_set_only_copy(&mesh->vdata, mask->vmask);
CustomData_set_only_copy(&mesh->edata, mask->emask);
CustomData_set_only_copy(&mesh->fdata, mask->fmask);
/* 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
CustomData_set_only_copy(&mesh->ldata, mask->lmask);
CustomData_set_only_copy(&mesh->pdata, mask->pmask);
#endif
}
void *DM_get_vert_data_layer(DerivedMesh *dm, int type)
{
if (type == CD_MVERT) {
return dm->getVertArray(dm);
}
return CustomData_get_layer(&dm->vertData, type);
}
void *DM_get_edge_data_layer(DerivedMesh *dm, int type)
{
if (type == CD_MEDGE) {
return dm->getEdgeArray(dm);
}
return CustomData_get_layer(&dm->edgeData, type);
}
void *DM_get_poly_data_layer(DerivedMesh *dm, int type)
{
return CustomData_get_layer(&dm->polyData, type);
}
void *DM_get_loop_data_layer(DerivedMesh *dm, int type)
{
return CustomData_get_layer(&dm->loopData, type);
}
void DM_copy_vert_data(
2012-05-12 21:18:02 +02:00
DerivedMesh *source, DerivedMesh *dest, int source_index, int dest_index, int count)
{
CustomData_copy_data(&source->vertData, &dest->vertData, source_index, dest_index, count);
}
void DM_interp_vert_data(DerivedMesh *source,
DerivedMesh *dest,
int *src_indices,
float *weights,
int count,
int dest_index)
{
CustomData_interp(
&source->vertData, &dest->vertData, src_indices, weights, nullptr, count, dest_index);
}
static float (*get_editbmesh_orco_verts(BMEditMesh *em))[3]
{
BMIter iter;
BMVert *eve;
float(*orco)[3];
int i;
/* 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
orco = (float(*)[3])MEM_malloc_arrayN(em->bm->totvert, sizeof(float[3]), "BMEditMesh Orco");
BM_ITER_MESH_INDEX (eve, &iter, em->bm, BM_VERTS_OF_MESH, i) {
copy_v3_v3(orco[i], eve->co);
}
2018-06-17 17:05:51 +02:00
return orco;
}
/* orco custom data layer */
static float (*get_orco_coords(Object *ob, BMEditMesh *em, int layer, int *free))[3]
{
2012-05-12 21:18:02 +02:00
*free = 0;
if (layer == CD_ORCO) {
/* get original coordinates */
2012-05-12 21:18:02 +02:00
*free = 1;
if (em) {
return get_editbmesh_orco_verts(em);
}
return BKE_mesh_orco_verts_get(ob);
}
if (layer == CD_CLOTH_ORCO) {
/* 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 */
if (!em) {
2020-05-08 11:02:03 +02:00
ClothModifierData *clmd = (ClothModifierData *)BKE_modifiers_findby_type(
ob, eModifierType_Cloth);
if (clmd) {
KeyBlock *kb = BKE_keyblock_from_key(BKE_key_from_object(ob),
clmd->sim_parms->shapekey_rest);
if (kb && kb->data) {
return (float(*)[3])kb->data;
}
}
}
return nullptr;
}
return nullptr;
}
static Mesh *create_orco_mesh(Object *ob, Mesh *me, BMEditMesh *em, int layer)
{
Mesh *mesh;
float(*orco)[3];
int free;
if (em) {
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);
}
else {
mesh = BKE_mesh_copy_for_eval(me, true);
}
orco = get_orco_coords(ob, em, layer, &free);
if (orco) {
BKE_mesh_vert_coords_apply(mesh, orco);
if (free) {
MEM_freeN(orco);
}
}
return mesh;
}
static void add_orco_mesh(Object *ob, BMEditMesh *em, Mesh *mesh, Mesh *mesh_orco, int layer)
{
float(*orco)[3], (*layerorco)[3];
int totvert, free;
totvert = mesh->totvert;
if (mesh_orco) {
free = 1;
if (mesh_orco->totvert == totvert) {
orco = BKE_mesh_vert_coords_alloc(mesh_orco, nullptr);
}
else {
orco = BKE_mesh_vert_coords_alloc(mesh, nullptr);
}
}
else {
/* TODO(sybren): totvert should potentially change here, as ob->data
* or em may have a different number of vertices than dm. */
orco = get_orco_coords(ob, em, layer, &free);
}
if (orco) {
if (layer == CD_ORCO) {
BKE_mesh_orco_verts_transform((Mesh *)ob->data, orco, totvert, 0);
}
if (!(layerorco = (float(*)[3])CustomData_get_layer(&mesh->vdata, layer))) {
2022-08-30 21:54:53 +02:00
CustomData_add_layer(&mesh->vdata, layer, CD_SET_DEFAULT, nullptr, mesh->totvert);
BKE_mesh_update_customdata_pointers(mesh, false);
layerorco = (float(*)[3])CustomData_get_layer(&mesh->vdata, layer);
}
memcpy(layerorco, orco, sizeof(float[3]) * totvert);
if (free) {
MEM_freeN(orco);
}
}
}
static bool mesh_has_modifier_final_normals(const Mesh *mesh_input,
const CustomData_MeshMasks *final_datamask,
Mesh *mesh_final)
{
/* Test if mesh has the required loop normals, in case an additional modifier
* evaluation from another instance or from an operator requests it but the
* initial normals were not loop normals. */
const bool calc_loop_normals = ((mesh_input->flag & ME_AUTOSMOOTH) != 0 ||
(final_datamask->lmask & CD_MASK_NORMAL) != 0);
return (!calc_loop_normals || CustomData_has_layer(&mesh_final->ldata, CD_NORMAL));
}
static void mesh_calc_modifier_final_normals(const Mesh *mesh_input,
const CustomData_MeshMasks *final_datamask,
const bool sculpt_dyntopo,
2019-03-29 21:13:55 +01:00
Mesh *mesh_final)
{
/* Compute normals. */
const bool calc_loop_normals = ((mesh_input->flag & ME_AUTOSMOOTH) != 0 ||
(final_datamask->lmask & CD_MASK_NORMAL) != 0);
/* Needed as `final_datamask` is not preserved outside modifier stack evaluation. */
SubsurfRuntimeData *subsurf_runtime_data = mesh_final->runtime.subsurf_runtime_data;
if (subsurf_runtime_data) {
subsurf_runtime_data->calc_loop_normals = calc_loop_normals;
}
if (calc_loop_normals) {
/* Compute loop normals (NOTE: will compute poly and vert normals as well, if needed!). In case
* of deferred CPU subdivision, this will be computed when the wrapper is generated. */
if (!subsurf_runtime_data || subsurf_runtime_data->resolution == 0) {
BKE_mesh_calc_normals_split(mesh_final);
}
}
else {
if (sculpt_dyntopo == false) {
/* without this, drawing ngon tri's faces will show ugly tessellated face
* normals and will also have to calculate normals on the fly, try avoid
* this where possible since calculating polygon normals isn't fast,
* note that this isn't a problem for subsurf (only quads) or edit-mode
* which deals with drawing differently. */
BKE_mesh_ensure_normals_for_display(mesh_final);
}
/* Some modifiers, like data-transfer, may generate those data as temp layer,
* we do not want to keep them, as they are used by display code when available
* (i.e. even if auto-smooth is disabled). */
if (CustomData_has_layer(&mesh_final->ldata, CD_NORMAL)) {
CustomData_free_layers(&mesh_final->ldata, CD_NORMAL, mesh_final->totloop);
}
}
}
/* 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. */
BLI_strncpy(mesh_eval->id.name, mesh_input->id.name, sizeof(mesh_eval->id.name));
/* Make evaluated mesh to share same edit mesh pointer as original and copied meshes. */
mesh_eval->edit_mesh = mesh_input->edit_mesh;
}
void BKE_mesh_wrapper_deferred_finalize_mdata(Mesh *me_eval,
const CustomData_MeshMasks *cd_mask_finalize)
{
if (me_eval->runtime.wrapper_type_finalize & (1 << ME_WRAPPER_TYPE_BMESH)) {
editbmesh_calc_modifier_final_normals(me_eval, cd_mask_finalize);
me_eval->runtime.wrapper_type_finalize &= ~(1 << ME_WRAPPER_TYPE_BMESH);
}
BLI_assert(me_eval->runtime.wrapper_type_finalize == 0);
}
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +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.
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +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.
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
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);
if (mti->modifyGeometrySet == nullptr) {
mesh_output = BKE_modifier_modify_mesh(md, &mectx, input_mesh);
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
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);
/* Adds a new mesh component to the geometry set based on the #input_mesh. */
MeshComponent &mesh_component = geometry_set.get_component_for_write<MeshComponent>();
/* 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. */
mesh_component.replace(input_mesh, GeometryOwnershipType::Editable);
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
/* Let the modifier change the geometry set. */
mti->modifyGeometrySet(md, &mectx, &geometry_set);
/* Release the mesh from the geometry set again. */
if (geometry_set.has<MeshComponent>()) {
MeshComponent &mesh_component = geometry_set.get_component_for_write<MeshComponent>();
if (mesh_component.get_for_read() != input_mesh) {
/* Make sure the mesh component actually owns the mesh before taking over ownership. */
mesh_component.ensure_owns_direct_data();
}
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
mesh_output = mesh_component.release();
}
/* Return an empty mesh instead of null. */
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
if (mesh_output == nullptr) {
mesh_output = BKE_mesh_new_nomain(0, 0, 0, 0, 0);
BKE_mesh_copy_parameters_for_eval(mesh_output, input_mesh);
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
}
}
return mesh_output;
}
static void mesh_calc_modifiers(struct Depsgraph *depsgraph,
const Scene *scene,
Object *ob,
const bool use_deform,
const bool need_mapping,
const CustomData_MeshMasks *dataMask,
const bool use_cache,
const bool allow_shared_mesh,
/* return args */
Mesh **r_deform,
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
Mesh **r_final,
GeometrySet **r_geometry_set)
{
using namespace blender::bke;
/* Input and final mesh. Final mesh is only created the moment the first
* constructive modifier is executed, or a deform modifier needs normals
* or certain data layers. */
Mesh *mesh_input = (Mesh *)ob->data;
Refactor: Move normals out of MVert, lazy calculation As described in T91186, this commit moves mesh vertex normals into a contiguous array of float vectors in a custom data layer, how face normals are currently stored. The main interface is documented in `BKE_mesh.h`. Vertex and face normals are now calculated on-demand and cached, retrieved with an "ensure" function. Since the logical state of a mesh is now "has normals when necessary", they can be retrieved from a `const` mesh. The goal is to use on-demand calculation for all derived data, but leave room for eager calculation for performance purposes (modifier evaluation is threaded, but viewport data generation is not). **Benefits** This moves us closer to a SoA approach rather than the current AoS paradigm. Accessing a contiguous `float3` is much more efficient than retrieving data from a larger struct. The memory requirements for accessing only normals or vertex locations are smaller, and at the cost of more memory usage for just normals, they now don't have to be converted between float and short, which also simplifies code In the future, the remaining items can be removed from `MVert`, leaving only `float3`, which has similar benefits (see T93602). Removing the combination of derived and original data makes it conceptually simpler to only calculate normals when necessary. This is especially important now that we have more opportunities for temporary meshes in geometry nodes. **Performance** In addition to the theoretical future performance improvements by making `MVert == float3`, I've done some basic performance testing on this patch directly. The data is fairly rough, but it gives an idea about where things stand generally. - Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms), showing that accessing just `MVert` is now more efficient. - Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight change that at least shows there is no regression. - Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small but observable speedup. - Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms), shows that using normals in geometry nodes is faster. - Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms), shows that calculating normals is slightly faster now. - File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB), Normals are not saved in files, which can help with large meshes. As for memory usage, it may be slightly more in some cases, but I didn't observe any difference in the production files I tested. **Tests** Some modifiers and cycles test results need to be updated with this commit, for two reasons: - The subdivision surface modifier is not responsible for calculating normals anymore. In master, the modifier creates different normals than the result of the `Mesh` normal calculation, so this is a bug fix. - There are small differences in the results of some modifiers that use normals because they are not converted to and from `short` anymore. **Future improvements** - Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier already retrieves normals if they are needed anyway. - Copy normals as part of a better CoW system for attributes. - Make more areas use lazy instead of eager normal calculation. - Remove `BKE_mesh_normals_tag_dirty` in more places since that is now the default state of a new mesh. - Possibly apply a similar change to derived face corner normals. Differential Revision: https://developer.blender.org/D12770
2022-01-13 21:37:58 +01:00
BKE_mesh_assert_normals_dirty_or_calculated(mesh_input);
Mesh *mesh_final = nullptr;
Mesh *mesh_deform = nullptr;
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
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;
BLI_assert((mesh_input->id.tag & LIB_TAG_COPIED_ON_WRITE_EVAL_RESULT) == 0);
/* Deformed vertex locations array. Deform only modifier need this type of
* float array rather than MVert*. Tracked along with mesh_final as an
* optimization to avoid copying coordinates back and forth if there are
* multiple sequential deform only modifiers. */
float(*deformed_verts)[3] = nullptr;
int num_deformed_verts = mesh_input->totvert;
bool isPrevDeform = false;
/* Mesh with constructive modifiers but no deformation applied. Tracked
* along with final mesh if undeformed / orco coordinates are requested
* for texturing. */
Mesh *mesh_orco = nullptr;
Mesh *mesh_orco_cloth = nullptr;
/* Modifier evaluation modes. */
const bool use_render = (DEG_get_mode(depsgraph) == DAG_EVAL_RENDER);
const int required_mode = use_render ? eModifierMode_Render : eModifierMode_Realtime;
/* Sculpt can skip certain modifiers. */
const bool has_multires = BKE_sculpt_multires_active(scene, ob) != nullptr;
bool multires_applied = false;
const bool sculpt_mode = ob->mode & OB_MODE_SCULPT && ob->sculpt && !use_render;
const bool sculpt_dyntopo = (sculpt_mode && ob->sculpt->bm) && !use_render;
/* Modifier evaluation contexts for different types of modifiers. */
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, (ModifierApplyFlag)(apply_render | apply_cache)};
const ModifierEvalContext mectx_orco = {
depsgraph, ob, (ModifierApplyFlag)(apply_render | MOD_APPLY_ORCO)};
/* Get effective list of modifiers to execute. Some effects like shape keys
* are added as virtual modifiers before the user created modifiers. */
VirtualModifierData virtualModifierData;
ModifierData *firstmd = BKE_modifiers_get_virtual_modifierlist(ob, &virtualModifierData);
ModifierData *md = firstmd;
/* 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);
ModifierData *previewmd = nullptr;
CustomData_MeshMasks previewmask = {0};
if (do_mod_mcol) {
/* Find the last active modifier generating a preview, or nullptr if none. */
/* XXX Currently, DPaint modifier just ignores this.
* Needs a stupid hack...
* The whole "modifier preview" thing has to be (re?)designed, anyway! */
previewmd = BKE_modifier_get_last_preview(scene, md, required_mode);
}
/* 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. */
CustomData_MeshMasks final_datamask = *dataMask;
CDMaskLink *datamasks = BKE_modifier_calc_data_masks(
scene, ob, md, &final_datamask, required_mode, previewmd, &previewmask);
CDMaskLink *md_datamask = datamasks;
/* XXX Always copying POLYINDEX, else tessellated data are no more valid! */
CustomData_MeshMasks append_mask = CD_MASK_BAREMESH_ORIGINDEX;
/* Clear errors before evaluation. */
BKE_modifiers_clear_errors(ob);
Curves: support deforming curves on surface Curves that are attached to a surface can now follow the surface when it is modified using shape keys or modifiers (but not when the original surface is deformed in edit or sculpt mode). The surface is allowed to be changed in any way that keeps uv maps intact. So deformation is allowed, but also some topology changes like subdivision. The following features are added: * A new `Deform Curves on Surface` node, which deforms curves with attachment information based on the surface object and uv map set in the properties panel. * A new `Add Rest Position` checkbox in the shape keys panel. When checked, a new `rest_position` vector attribute is added to the mesh before shape keys and modifiers are applied. This is necessary to support proper deformation of the curves, but can also be used for other purposes. * The `Add > Curve > Empty Hair` operator now sets up a simple geometry nodes setup that deforms the hair. It also makes sure that the rest position attribute is added to the surface. * A new `Object (Attach Curves to Surface)` operator in the `Set Parent To` (ctrl+P) menu, which attaches existing curves to the surface and sets the surface object as parent. Limitations: * Sculpting the procedurally deformed curves will be implemented separately. * The `Deform Curves on Surface` node is not generic and can only be used for one specific purpose currently. We plan to generalize this more in the future by adding support by exposing more inputs and/or by turning it into a node group. Differential Revision: https://developer.blender.org/D14864
2022-07-08 14:45:48 +02:00
if (ob->modifier_flag & OB_MODIFIER_FLAG_ADD_REST_POSITION) {
if (mesh_final == nullptr) {
mesh_final = BKE_mesh_copy_for_eval(mesh_input, true);
ASSERT_IS_VALID_MESH(mesh_final);
}
MutableAttributeAccessor attributes = mesh_attributes_for_write(*mesh_final);
SpanAttributeWriter<float3> rest_positions =
attributes.lookup_or_add_for_write_only_span<float3>("rest_position", ATTR_DOMAIN_POINT);
if (rest_positions) {
attributes.lookup<float3>("position").materialize(rest_positions.span);
rest_positions.finish();
}
Curves: support deforming curves on surface Curves that are attached to a surface can now follow the surface when it is modified using shape keys or modifiers (but not when the original surface is deformed in edit or sculpt mode). The surface is allowed to be changed in any way that keeps uv maps intact. So deformation is allowed, but also some topology changes like subdivision. The following features are added: * A new `Deform Curves on Surface` node, which deforms curves with attachment information based on the surface object and uv map set in the properties panel. * A new `Add Rest Position` checkbox in the shape keys panel. When checked, a new `rest_position` vector attribute is added to the mesh before shape keys and modifiers are applied. This is necessary to support proper deformation of the curves, but can also be used for other purposes. * The `Add > Curve > Empty Hair` operator now sets up a simple geometry nodes setup that deforms the hair. It also makes sure that the rest position attribute is added to the surface. * A new `Object (Attach Curves to Surface)` operator in the `Set Parent To` (ctrl+P) menu, which attaches existing curves to the surface and sets the surface object as parent. Limitations: * Sculpting the procedurally deformed curves will be implemented separately. * The `Deform Curves on Surface` node is not generic and can only be used for one specific purpose currently. We plan to generalize this more in the future by adding support by exposing more inputs and/or by turning it into a node group. Differential Revision: https://developer.blender.org/D14864
2022-07-08 14:45:48 +02:00
}
/* Apply all leading deform modifiers. */
if (use_deform) {
for (; md; md = md->next, md_datamask = md_datamask->next) {
const ModifierTypeInfo *mti = BKE_modifier_get_info((ModifierType)md->type);
if (!BKE_modifier_is_enabled(scene, md, required_mode)) {
continue;
}
if (mti->type == eModifierTypeType_OnlyDeform && !sculpt_dyntopo) {
if (!deformed_verts) {
deformed_verts = BKE_mesh_vert_coords_alloc(mesh_input, &num_deformed_verts);
}
else if (isPrevDeform && mti->dependsOnNormals && mti->dependsOnNormals(md)) {
if (mesh_final == nullptr) {
mesh_final = BKE_mesh_copy_for_eval(mesh_input, true);
ASSERT_IS_VALID_MESH(mesh_final);
}
BKE_mesh_vert_coords_apply(mesh_final, deformed_verts);
}
BKE_modifier_deform_verts(md, &mectx, mesh_final, deformed_verts, num_deformed_verts);
isPrevDeform = true;
}
else {
break;
}
}
/* Result of all leading deforming modifiers is cached for
* places that wish to use the original mesh but with deformed
* coordinates (like vertex paint). */
if (r_deform) {
mesh_deform = BKE_mesh_copy_for_eval(mesh_input, true);
if (deformed_verts) {
BKE_mesh_vert_coords_apply(mesh_deform, deformed_verts);
}
}
}
/* Apply all remaining constructive and deforming modifiers. */
bool have_non_onlydeform_modifiers_appled = false;
for (; md; md = md->next, md_datamask = md_datamask->next) {
const ModifierTypeInfo *mti = BKE_modifier_get_info((ModifierType)md->type);
if (!BKE_modifier_is_enabled(scene, md, required_mode)) {
continue;
}
if (mti->type == eModifierTypeType_OnlyDeform && !use_deform) {
continue;
}
if ((mti->flags & eModifierTypeFlag_RequiresOriginalData) &&
have_non_onlydeform_modifiers_appled) {
BKE_modifier_set_error(ob, md, "Modifier requires original data, bad stack position");
continue;
}
2014-05-09 10:29:21 +02:00
if (sculpt_mode && (!has_multires || multires_applied || sculpt_dyntopo)) {
bool unsupported = false;
if (md->type == eModifierType_Multires && ((MultiresModifierData *)md)->sculptlvl == 0) {
/* If multires is on level 0 skip it silently without warning message. */
if (!sculpt_dyntopo) {
continue;
}
}
if (sculpt_dyntopo) {
unsupported = true;
}
if (scene->toolsettings->sculpt->flags & SCULPT_ONLY_DEFORM) {
unsupported |= (mti->type != eModifierTypeType_OnlyDeform);
}
2012-05-12 21:18:02 +02:00
unsupported |= multires_applied;
if (unsupported) {
if (sculpt_dyntopo) {
BKE_modifier_set_error(ob, md, "Not supported in dyntopo");
}
else {
BKE_modifier_set_error(ob, md, "Not supported in sculpt mode");
}
continue;
}
}
if (need_mapping && !BKE_modifier_supports_mapping(md)) {
continue;
}
/* Add orco mesh as layer if needed by this modifier. */
if (mesh_final && mesh_orco && mti->requiredDataMask) {
CustomData_MeshMasks mask = {0};
mti->requiredDataMask(ob, md, &mask);
if (mask.vmask & CD_MASK_ORCO) {
add_orco_mesh(ob, nullptr, mesh_final, mesh_orco, CD_ORCO);
}
}
/* How to apply modifier depends on (a) what we already have as
* a result of previous modifiers (could be a Mesh or just
* deformed vertices) and (b) what type the modifier is. */
if (mti->type == eModifierTypeType_OnlyDeform) {
/* No existing verts to deform, need to build them. */
if (!deformed_verts) {
if (mesh_final) {
/* Deforming a mesh, read the vertex locations
* out of the mesh and deform them. Once done with this
* run of deformers verts will be written back. */
deformed_verts = BKE_mesh_vert_coords_alloc(mesh_final, &num_deformed_verts);
}
else {
deformed_verts = BKE_mesh_vert_coords_alloc(mesh_input, &num_deformed_verts);
}
}
/* if this is not the last modifier in the stack then recalculate the normals
* to avoid giving bogus normals to the next modifier see: T23673. */
else if (isPrevDeform && mti->dependsOnNormals && mti->dependsOnNormals(md)) {
if (mesh_final == nullptr) {
mesh_final = BKE_mesh_copy_for_eval(mesh_input, true);
ASSERT_IS_VALID_MESH(mesh_final);
}
BKE_mesh_vert_coords_apply(mesh_final, deformed_verts);
}
BKE_modifier_deform_verts(md, &mectx, mesh_final, deformed_verts, num_deformed_verts);
}
else {
bool check_for_needs_mapping = false;
/* apply vertex coordinates or build a Mesh as necessary */
if (mesh_final != nullptr) {
if (have_non_onlydeform_modifiers_appled == false) {
/* 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;
}
}
else {
mesh_final = BKE_mesh_copy_for_eval(mesh_input, true);
ASSERT_IS_VALID_MESH(mesh_final);
check_for_needs_mapping = true;
}
if (deformed_verts) {
BKE_mesh_vert_coords_apply(mesh_final, deformed_verts);
}
have_non_onlydeform_modifiers_appled = true;
/* determine which data layers are needed by following modifiers */
CustomData_MeshMasks nextmask = md_datamask->next ? md_datamask->next->mask : final_datamask;
if (check_for_needs_mapping) {
/* 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.
*
* These are created when either requested by evaluation, or if
* following modifiers requested them. */
if (need_mapping ||
((nextmask.vmask | nextmask.emask | nextmask.pmask) & CD_MASK_ORIGINDEX)) {
/* calc */
CustomData_add_layer(
&mesh_final->vdata, CD_ORIGINDEX, CD_CONSTRUCT, nullptr, mesh_final->totvert);
CustomData_add_layer(
&mesh_final->edata, CD_ORIGINDEX, CD_CONSTRUCT, nullptr, mesh_final->totedge);
CustomData_add_layer(
&mesh_final->pdata, CD_ORIGINDEX, CD_CONSTRUCT, nullptr, mesh_final->totpoly);
/* Not worth parallelizing this,
* gives less than 0.1% overall speedup in best of best cases... */
range_vn_i((int *)CustomData_get_layer(&mesh_final->vdata, CD_ORIGINDEX),
mesh_final->totvert,
0);
range_vn_i((int *)CustomData_get_layer(&mesh_final->edata, CD_ORIGINDEX),
mesh_final->totedge,
0);
range_vn_i((int *)CustomData_get_layer(&mesh_final->pdata, CD_ORIGINDEX),
mesh_final->totpoly,
0);
}
}
/* set the Mesh to only copy needed data */
CustomData_MeshMasks mask = md_datamask->mask;
/* needMapping check here fixes bug T28112, otherwise it's
* possible that it won't be copied */
CustomData_MeshMasks_update(&mask, &append_mask);
if (need_mapping) {
mask.vmask |= CD_MASK_ORIGINDEX;
mask.emask |= CD_MASK_ORIGINDEX;
mask.pmask |= CD_MASK_ORIGINDEX;
}
mesh_set_only_copy(mesh_final, &mask);
/* add cloth rest shape key if needed */
if (mask.vmask & CD_MASK_CLOTH_ORCO) {
add_orco_mesh(ob, nullptr, mesh_final, mesh_orco, CD_CLOTH_ORCO);
}
/* add an origspace layer if needed */
if ((md_datamask->mask.lmask) & CD_MASK_ORIGSPACE_MLOOP) {
if (!CustomData_has_layer(&mesh_final->ldata, CD_ORIGSPACE_MLOOP)) {
2022-08-30 21:54:53 +02:00
CustomData_add_layer(&mesh_final->ldata,
CD_ORIGSPACE_MLOOP,
CD_SET_DEFAULT,
nullptr,
mesh_final->totloop);
mesh_init_origspace(mesh_final);
}
}
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
Mesh *mesh_next = modifier_modify_mesh_and_geometry_set(
md, mectx, mesh_final, geometry_set_final);
ASSERT_IS_VALID_MESH(mesh_next);
if (mesh_next) {
/* if the modifier returned a new mesh, release the old one */
if (mesh_final != mesh_next) {
BLI_assert(mesh_final != mesh_input);
BKE_id_free(nullptr, mesh_final);
}
mesh_final = mesh_next;
if (deformed_verts) {
MEM_freeN(deformed_verts);
deformed_verts = nullptr;
}
}
/* create an orco mesh in parallel */
if (nextmask.vmask & CD_MASK_ORCO) {
if (!mesh_orco) {
mesh_orco = create_orco_mesh(ob, mesh_input, nullptr, CD_ORCO);
}
nextmask.vmask &= ~CD_MASK_ORCO;
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;
if (mti->requiredDataMask != nullptr) {
mti->requiredDataMask(ob, md, &temp_cddata_masks);
}
CustomData_MeshMasks_update(&temp_cddata_masks, &nextmask);
mesh_set_only_copy(mesh_orco, &temp_cddata_masks);
mesh_next = BKE_modifier_modify_mesh(md, &mectx_orco, mesh_orco);
ASSERT_IS_VALID_MESH(mesh_next);
if (mesh_next) {
/* if the modifier returned a new mesh, release the old one */
if (mesh_orco != mesh_next) {
BLI_assert(mesh_orco != mesh_input);
BKE_id_free(nullptr, mesh_orco);
}
mesh_orco = mesh_next;
}
}
/* create cloth orco mesh in parallel */
if (nextmask.vmask & CD_MASK_CLOTH_ORCO) {
if (!mesh_orco_cloth) {
mesh_orco_cloth = create_orco_mesh(ob, mesh_input, nullptr, CD_CLOTH_ORCO);
}
nextmask.vmask &= ~CD_MASK_CLOTH_ORCO;
nextmask.vmask |= CD_MASK_ORIGINDEX;
nextmask.emask |= CD_MASK_ORIGINDEX;
nextmask.pmask |= CD_MASK_ORIGINDEX;
mesh_set_only_copy(mesh_orco_cloth, &nextmask);
mesh_next = BKE_modifier_modify_mesh(md, &mectx_orco, mesh_orco_cloth);
ASSERT_IS_VALID_MESH(mesh_next);
if (mesh_next) {
/* if the modifier returned a new mesh, release the old one */
if (mesh_orco_cloth != mesh_next) {
BLI_assert(mesh_orco != mesh_input);
BKE_id_free(nullptr, mesh_orco_cloth);
}
mesh_orco_cloth = mesh_next;
}
}
/* in case of dynamic paint, make sure preview mask remains for following modifiers */
/* XXX Temp and hackish solution! */
if (md->type == eModifierType_DynamicPaint) {
append_mask.lmask |= CD_MASK_PREVIEW_MLOOPCOL;
}
mesh_final->runtime.deformed_only = false;
}
2012-05-12 21:18:02 +02:00
isPrevDeform = (mti->type == eModifierTypeType_OnlyDeform);
if (sculpt_mode && md->type == eModifierType_Multires) {
multires_applied = true;
}
}
BLI_linklist_free((LinkNode *)datamasks, nullptr);
for (md = firstmd; md; md = md->next) {
BKE_modifier_free_temporary_data(md);
}
/* Yay, we are done. If we have a Mesh and deformed vertices,
* we need to apply these back onto the Mesh. If we have no
* Mesh then we need to build one. */
if (mesh_final == nullptr) {
if (deformed_verts == nullptr && allow_shared_mesh) {
mesh_final = mesh_input;
}
else {
mesh_final = BKE_mesh_copy_for_eval(mesh_input, true);
}
}
if (deformed_verts) {
BKE_mesh_vert_coords_apply(mesh_final, deformed_verts);
MEM_freeN(deformed_verts);
deformed_verts = nullptr;
}
/* 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);
/* Add orco coordinates to final and deformed mesh if requested. */
if (final_datamask.vmask & CD_MASK_ORCO) {
/* 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) {
add_orco_mesh(ob, nullptr, mesh_final, mesh_orco, CD_ORCO);
}
if (mesh_deform) {
add_orco_mesh(ob, nullptr, mesh_deform, nullptr, CD_ORCO);
}
}
if (mesh_orco) {
BKE_id_free(nullptr, mesh_orco);
}
if (mesh_orco_cloth) {
BKE_id_free(nullptr, mesh_orco_cloth);
}
/* Remove temporary data layer only needed for modifier evaluation.
* Save some memory, and ensure GPU subdivision does not need to deal with this. */
CustomData_free_layers(&mesh_final->vdata, CD_CLOTH_ORCO, mesh_final->totvert);
/* Compute normals. */
if (is_own_mesh) {
mesh_calc_modifier_final_normals(mesh_input, &final_datamask, sculpt_dyntopo, mesh_final);
mesh_calc_finalize(mesh_input, mesh_final);
}
else {
Mesh_Runtime *runtime = &mesh_input->runtime;
if (runtime->mesh_eval == nullptr) {
BLI_assert(runtime->eval_mutex != nullptr);
BLI_mutex_lock((ThreadMutex *)runtime->eval_mutex);
if (runtime->mesh_eval == nullptr) {
/* Not yet finalized by any instance, do it now
* Isolate since computing normals is multithreaded and we are holding a lock. */
blender::threading::isolate_task([&] {
mesh_final = BKE_mesh_copy_for_eval(mesh_input, true);
mesh_calc_modifier_final_normals(
mesh_input, &final_datamask, sculpt_dyntopo, mesh_final);
mesh_calc_finalize(mesh_input, mesh_final);
runtime->mesh_eval = mesh_final;
});
}
else {
/* Already finalized by another instance, reuse. */
mesh_final = runtime->mesh_eval;
}
BLI_mutex_unlock((ThreadMutex *)runtime->eval_mutex);
}
else if (!mesh_has_modifier_final_normals(mesh_input, &final_datamask, runtime->mesh_eval)) {
/* Modifier stack was (re-)evaluated with a request for additional normals
* different than the instanced mesh, can't instance anymore now. */
mesh_final = BKE_mesh_copy_for_eval(mesh_input, true);
mesh_calc_modifier_final_normals(mesh_input, &final_datamask, sculpt_dyntopo, mesh_final);
mesh_calc_finalize(mesh_input, mesh_final);
}
else {
/* Already finalized by another instance, reuse. */
mesh_final = runtime->mesh_eval;
}
}
/* Return final mesh */
*r_final = mesh_final;
if (r_deform) {
*r_deform = mesh_deform;
}
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
if (r_geometry_set) {
*r_geometry_set = new GeometrySet(std::move(geometry_set_final));
}
}
float (*editbmesh_vert_coords_alloc(BMEditMesh *em, int *r_vert_len))[3]
- 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
{
BMIter iter;
BMVert *eve;
float(*cos)[3];
int i;
*r_vert_len = em->bm->totvert;
- 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
cos = (float(*)[3])MEM_malloc_arrayN(em->bm->totvert, sizeof(float[3]), "vertexcos");
BM_ITER_MESH_INDEX (eve, &iter, em->bm, BM_VERTS_OF_MESH, i) {
copy_v3_v3(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
}
bool editbmesh_modifier_is_enabled(const Scene *scene,
const Object *ob,
ModifierData *md,
bool has_prev_mesh)
{
const ModifierTypeInfo *mti = BKE_modifier_get_info((ModifierType)md->type);
const int required_mode = eModifierMode_Realtime | eModifierMode_Editmode;
if (!BKE_modifier_is_enabled(scene, md, required_mode)) {
return false;
}
if ((mti->flags & eModifierTypeFlag_RequiresOriginalData) && has_prev_mesh) {
BKE_modifier_set_error(ob, md, "Modifier requires original data, bad stack position");
2014-12-01 17:11:18 +01:00
return false;
}
2014-12-01 17:11:18 +01:00
return true;
}
static void editbmesh_calc_modifier_final_normals(Mesh *mesh_final,
const CustomData_MeshMasks *final_datamask)
{
const bool calc_loop_normals = ((mesh_final->flag & ME_AUTOSMOOTH) != 0 ||
(final_datamask->lmask & CD_MASK_NORMAL) != 0);
SubsurfRuntimeData *subsurf_runtime_data = mesh_final->runtime.subsurf_runtime_data;
if (subsurf_runtime_data) {
subsurf_runtime_data->calc_loop_normals = calc_loop_normals;
}
if (calc_loop_normals) {
/* Compute loop normals. In case of deferred CPU subdivision, this will be computed when the
* wrapper is generated. */
if (!subsurf_runtime_data || subsurf_runtime_data->resolution == 0) {
BKE_mesh_calc_normals_split(mesh_final);
}
}
else {
/* Same as mesh_calc_modifiers. If using loop normals, poly nors have already been computed. */
BKE_mesh_ensure_normals_for_display(mesh_final);
2019-06-12 01:04:10 +02:00
/* Some modifiers, like data-transfer, may generate those data, we do not want to keep them,
* as they are used by display code when available (i.e. even if autosmooth is disabled). */
if (CustomData_has_layer(&mesh_final->ldata, CD_NORMAL)) {
CustomData_free_layers(&mesh_final->ldata, CD_NORMAL, mesh_final->totloop);
}
}
}
static void editbmesh_calc_modifier_final_normals_or_defer(
Mesh *mesh_final, const CustomData_MeshMasks *final_datamask)
{
if (mesh_final->runtime.wrapper_type != ME_WRAPPER_TYPE_MDATA) {
/* Generated at draw time. */
mesh_final->runtime.wrapper_type_finalize = (1 << mesh_final->runtime.wrapper_type);
return;
}
editbmesh_calc_modifier_final_normals(mesh_final, final_datamask);
}
static void editbmesh_calc_modifiers(struct Depsgraph *depsgraph,
const Scene *scene,
Object *ob,
BMEditMesh *em_input,
const CustomData_MeshMasks *dataMask,
/* return args */
Mesh **r_cage,
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
Mesh **r_final,
GeometrySet **r_geometry_set)
{
/* Input and final mesh. Final mesh is only created the moment the first
* constructive modifier is executed, or a deform modifier needs normals
* or certain data layers. */
Mesh *mesh_input = (Mesh *)ob->data;
Mesh *mesh_final = nullptr;
Mesh *mesh_cage = nullptr;
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
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;
/* Deformed vertex locations array. Deform only modifier need this type of
* float array rather than MVert*. Tracked along with mesh_final as an
* optimization to avoid copying coordinates back and forth if there are
* multiple sequential deform only modifiers. */
float(*deformed_verts)[3] = nullptr;
int num_deformed_verts = 0;
bool isPrevDeform = false;
/* Mesh with constructive modifiers but no deformation applied. Tracked
* along with final mesh if undeformed / orco coordinates are requested
* for texturing. */
Mesh *mesh_orco = nullptr;
/* Modifier evaluation modes. */
const int required_mode = eModifierMode_Realtime | eModifierMode_Editmode;
const bool use_render = (DEG_get_mode(depsgraph) == DAG_EVAL_RENDER);
/* Modifier evaluation contexts for different types of modifiers. */
ModifierApplyFlag apply_render = use_render ? MOD_APPLY_RENDER : (ModifierApplyFlag)0;
const ModifierEvalContext mectx = {
depsgraph, ob, (ModifierApplyFlag)(MOD_APPLY_USECACHE | apply_render)};
const ModifierEvalContext mectx_orco = {depsgraph, ob, MOD_APPLY_ORCO};
/* Get effective list of modifiers to execute. Some effects like shape keys
* are added as virtual modifiers before the user created modifiers. */
VirtualModifierData virtualModifierData;
ModifierData *md = BKE_modifiers_get_virtual_modifierlist(ob, &virtualModifierData);
/* 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. */
CustomData_MeshMasks final_datamask = *dataMask;
CDMaskLink *datamasks = BKE_modifier_calc_data_masks(
scene, ob, md, &final_datamask, required_mode, nullptr, nullptr);
CDMaskLink *md_datamask = datamasks;
CustomData_MeshMasks append_mask = CD_MASK_BAREMESH;
/* Evaluate modifiers up to certain index to get the mesh cage. */
int cageIndex = BKE_modifiers_get_cage_index(scene, ob, nullptr, true);
if (r_cage && cageIndex == -1) {
mesh_cage = BKE_mesh_wrapper_from_editmesh_with_coords(
em_input, &final_datamask, nullptr, mesh_input);
}
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);
/* Clear errors before evaluation. */
BKE_modifiers_clear_errors(ob);
for (int i = 0; md; i++, md = md->next, md_datamask = md_datamask->next) {
const ModifierTypeInfo *mti = BKE_modifier_get_info((ModifierType)md->type);
if (!editbmesh_modifier_is_enabled(scene, ob, md, mesh_final != nullptr)) {
continue;
}
/* Add an orco mesh as layer if needed by this modifier. */
if (mesh_final && mesh_orco && mti->requiredDataMask) {
CustomData_MeshMasks mask = {0};
mti->requiredDataMask(ob, md, &mask);
if (mask.vmask & CD_MASK_ORCO) {
add_orco_mesh(ob, em_input, mesh_final, mesh_orco, CD_ORCO);
}
}
/* How to apply modifier depends on (a) what we already have as
* a result of previous modifiers (could be a mesh or just
* deformed vertices) and (b) what type the modifier is. */
if (mti->type == eModifierTypeType_OnlyDeform) {
/* No existing verts to deform, need to build them. */
if (!deformed_verts) {
if (mesh_final) {
/* Deforming a derived mesh, read the vertex locations
* out of the mesh and deform them. Once done with this
* run of deformers verts will be written back. */
deformed_verts = BKE_mesh_vert_coords_alloc(mesh_final, &num_deformed_verts);
}
else {
deformed_verts = editbmesh_vert_coords_alloc(em_input, &num_deformed_verts);
}
- 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
}
else if (isPrevDeform && mti->dependsOnNormals && mti->dependsOnNormals(md)) {
if (mesh_final == nullptr) {
mesh_final = BKE_mesh_from_bmesh_for_eval_nomain(em_input->bm, nullptr, mesh_input);
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_final);
ASSERT_IS_VALID_MESH(mesh_final);
}
BLI_assert(deformed_verts != nullptr);
BKE_mesh_vert_coords_apply(mesh_final, deformed_verts);
}
if (mti->deformVertsEM) {
BKE_modifier_deform_vertsEM(
md, &mectx, em_input, mesh_final, deformed_verts, num_deformed_verts);
}
else {
BKE_modifier_deform_verts(md, &mectx, mesh_final, deformed_verts, num_deformed_verts);
}
}
else {
/* apply vertex coordinates or build a DerivedMesh as necessary */
if (mesh_final) {
if (deformed_verts) {
Mesh *mesh_tmp = BKE_mesh_copy_for_eval(mesh_final, false);
if (mesh_final != mesh_cage) {
BKE_id_free(nullptr, mesh_final);
}
mesh_final = mesh_tmp;
BKE_mesh_vert_coords_apply(mesh_final, deformed_verts);
}
else if (mesh_final == mesh_cage) {
/* 'me' may be changed by this modifier, so we need to copy it. */
mesh_final = BKE_mesh_copy_for_eval(mesh_final, false);
}
}
else {
mesh_final = BKE_mesh_wrapper_from_editmesh_with_coords(
em_input, nullptr, deformed_verts, mesh_input);
deformed_verts = nullptr;
}
/* create an orco derivedmesh in parallel */
CustomData_MeshMasks mask = md_datamask->mask;
if (mask.vmask & CD_MASK_ORCO) {
if (!mesh_orco) {
mesh_orco = create_orco_mesh(ob, mesh_input, em_input, CD_ORCO);
}
mask.vmask &= ~CD_MASK_ORCO;
mask.vmask |= CD_MASK_ORIGINDEX;
mask.emask |= CD_MASK_ORIGINDEX;
mask.pmask |= CD_MASK_ORIGINDEX;
mesh_set_only_copy(mesh_orco, &mask);
Mesh *mesh_next = BKE_modifier_modify_mesh(md, &mectx_orco, mesh_orco);
ASSERT_IS_VALID_MESH(mesh_next);
if (mesh_next) {
/* if the modifier returned a new dm, release the old one */
if (mesh_orco && mesh_orco != mesh_next) {
BKE_id_free(nullptr, mesh_orco);
}
mesh_orco = mesh_next;
}
}
/* set the DerivedMesh to only copy needed data */
CustomData_MeshMasks_update(&mask, &append_mask);
/* XXX WHAT? overwrites mask ??? */
/* CD_MASK_ORCO may have been cleared above */
mask = md_datamask->mask;
mask.vmask |= CD_MASK_ORIGINDEX;
mask.emask |= CD_MASK_ORIGINDEX;
mask.pmask |= CD_MASK_ORIGINDEX;
mesh_set_only_copy(mesh_final, &mask);
if (mask.lmask & CD_MASK_ORIGSPACE_MLOOP) {
if (!CustomData_has_layer(&mesh_final->ldata, CD_ORIGSPACE_MLOOP)) {
2022-08-30 21:54:53 +02:00
CustomData_add_layer(&mesh_final->ldata,
CD_ORIGSPACE_MLOOP,
CD_SET_DEFAULT,
nullptr,
mesh_final->totloop);
mesh_init_origspace(mesh_final);
}
}
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
Mesh *mesh_next = modifier_modify_mesh_and_geometry_set(
md, mectx, mesh_final, geometry_set_final);
ASSERT_IS_VALID_MESH(mesh_next);
if (mesh_next) {
if (mesh_final && mesh_final != mesh_next) {
BKE_id_free(nullptr, mesh_final);
}
mesh_final = mesh_next;
if (deformed_verts) {
MEM_freeN(deformed_verts);
deformed_verts = nullptr;
}
}
mesh_final->runtime.deformed_only = false;
}
if (r_cage && i == cageIndex) {
if (mesh_final && deformed_verts) {
mesh_cage = BKE_mesh_copy_for_eval(mesh_final, false);
BKE_mesh_vert_coords_apply(mesh_cage, deformed_verts);
}
else if (mesh_final) {
mesh_cage = mesh_final;
}
else {
Mesh *me_orig = mesh_input;
/* Modifying the input mesh is weak, however as there can only be one object in edit mode
* even if multiple are sharing the same mesh this should be thread safe. */
if ((me_orig->id.tag & LIB_TAG_COPIED_ON_WRITE) && (ob->mode & OB_MODE_EDIT)) {
if (!BKE_mesh_runtime_ensure_edit_data(me_orig)) {
BKE_mesh_runtime_reset_edit_data(me_orig);
}
me_orig->runtime.edit_data->vertexCos = (const float(*)[3])MEM_dupallocN(deformed_verts);
}
mesh_cage = BKE_mesh_wrapper_from_editmesh_with_coords(
em_input,
&final_datamask,
deformed_verts ? (const float(*)[3])MEM_dupallocN(deformed_verts) : nullptr,
mesh_input);
- 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
}
}
isPrevDeform = (mti->type == eModifierTypeType_OnlyDeform);
- 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
}
BLI_linklist_free((LinkNode *)datamasks, nullptr);
/* Yay, we are done. If we have a DerivedMesh and deformed vertices need
* to apply these back onto the DerivedMesh. If we have no DerivedMesh
* then we need to build one. */
if (mesh_final) {
if (deformed_verts) {
if (mesh_final == mesh_cage) {
mesh_final = BKE_mesh_copy_for_eval(mesh_final, false);
}
BKE_mesh_vert_coords_apply(mesh_final, deformed_verts);
}
}
else if (!deformed_verts && mesh_cage) {
/* cage should already have up to date normals */
mesh_final = mesh_cage;
}
else {
/* this is just a copy of the editmesh, no need to calc normals */
mesh_final = BKE_mesh_wrapper_from_editmesh_with_coords(
em_input, &final_datamask, deformed_verts, mesh_input);
deformed_verts = nullptr;
- 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
}
if (deformed_verts) {
MEM_freeN(deformed_verts);
}
/* Add orco coordinates to final and deformed mesh if requested. */
if (final_datamask.vmask & CD_MASK_ORCO) {
/* FIXME(@campbellbarton): avoid the need to convert to mesh data just to add an orco layer. */
BKE_mesh_wrapper_ensure_mdata(mesh_final);
add_orco_mesh(ob, em_input, mesh_final, mesh_orco, CD_ORCO);
}
if (mesh_orco) {
BKE_id_free(nullptr, mesh_orco);
}
/* Compute normals. */
editbmesh_calc_modifier_final_normals_or_defer(mesh_final, &final_datamask);
if (mesh_cage && (mesh_cage != mesh_final)) {
editbmesh_calc_modifier_final_normals_or_defer(mesh_cage, &final_datamask);
}
/* Return final mesh. */
*r_final = mesh_final;
if (r_cage) {
*r_cage = mesh_cage;
}
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
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
}
static void mesh_build_extra_data(struct Depsgraph *depsgraph, Object *ob, Mesh *mesh_eval)
{
uint32_t eval_flags = DEG_get_eval_flags_for_id(depsgraph, &ob->id);
if (eval_flags & DAG_EVAL_NEED_SHRINKWRAP_BOUNDARY) {
BKE_shrinkwrap_compute_boundary_data(mesh_eval);
}
}
static void mesh_build_data(struct Depsgraph *depsgraph,
const Scene *scene,
Object *ob,
const CustomData_MeshMasks *dataMask,
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
{
#if 0 /* XXX This is already taken care of in #mesh_calc_modifiers... */
if (need_mapping) {
/* Also add the flag so that it is recorded in lastDataMask. */
dataMask->vmask |= CD_MASK_ORIGINDEX;
dataMask->emask |= CD_MASK_ORIGINDEX;
dataMask->pmask |= CD_MASK_ORIGINDEX;
}
#endif
Mesh *mesh_eval = nullptr, *mesh_deform_eval = nullptr;
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
GeometrySet *geometry_set_eval = nullptr;
mesh_calc_modifiers(depsgraph,
scene,
ob,
2021-07-01 02:08:24 +02:00
true,
need_mapping,
dataMask,
true,
true,
&mesh_deform_eval,
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
&mesh_eval,
&geometry_set_eval);
/* 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). */
Mesh *mesh = (Mesh *)ob->data;
const bool is_mesh_eval_owned = (mesh_eval != mesh->runtime.mesh_eval);
BKE_object_eval_assign_data(ob, &mesh_eval->id, is_mesh_eval_owned);
/* Add the final mesh as a non-owning component to the geometry set. */
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
MeshComponent &mesh_component = geometry_set_eval->get_component_for_write<MeshComponent>();
mesh_component.replace(mesh_eval, GeometryOwnershipType::Editable);
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
ob->runtime.geometry_set_eval = geometry_set_eval;
ob->runtime.mesh_deform_eval = mesh_deform_eval;
ob->runtime.last_data_mask = *dataMask;
ob->runtime.last_need_mapping = need_mapping;
BKE_object_boundbox_calc_from_mesh(ob, mesh_eval);
/* 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));
mesh_eval->key = mesh->key;
if ((ob->mode & OB_MODE_ALL_SCULPT) && ob->sculpt) {
if (DEG_is_active(depsgraph)) {
BKE_sculpt_update_object_after_eval(depsgraph, ob);
}
}
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
}
static void editbmesh_build_data(struct Depsgraph *depsgraph,
const Scene *scene,
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
{
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
2022-01-11 15:42:07 +01:00
Mesh *mesh = static_cast<Mesh *>(obedit->data);
Mesh *me_cage;
Mesh *me_final;
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
GeometrySet *non_mesh_components;
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
editbmesh_calc_modifiers(
depsgraph, scene, obedit, em, dataMask, &me_cage, &me_final, &non_mesh_components);
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
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);
}
}
const bool is_mesh_eval_owned = (me_final != mesh->runtime.mesh_eval);
BKE_object_eval_assign_data(obedit, &me_final->id, is_mesh_eval_owned);
obedit->runtime.editmesh_eval_cage = me_cage;
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
obedit->runtime.geometry_set_eval = non_mesh_components;
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
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
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
2022-01-11 15:42:07 +01:00
obedit->runtime.last_data_mask = *dataMask;
}
static void object_get_datamask(const Depsgraph *depsgraph,
Object *ob,
CustomData_MeshMasks *r_mask,
bool *r_need_mapping)
{
ViewLayer *view_layer = DEG_get_evaluated_view_layer(depsgraph);
DEG_get_customdata_mask_for_object(depsgraph, ob, r_mask);
if (r_need_mapping) {
*r_need_mapping = false;
}
/* Must never access original objects when dependency graph is not active: it might be already
* freed. */
if (!DEG_is_active(depsgraph)) {
return;
}
Object *actob = view_layer->basact ? DEG_get_original_object(view_layer->basact->object) :
nullptr;
if (DEG_get_original_object(ob) == actob) {
bool editing = BKE_paint_select_face_test(actob);
/* weight paint and face select need original indices because of selection buffer drawing */
if (r_need_mapping) {
*r_need_mapping = (editing || (ob->mode & (OB_MODE_WEIGHT_PAINT | OB_MODE_VERTEX_PAINT)));
}
/* check if we need tfaces & mcols due to face select or texture paint */
if ((ob->mode & OB_MODE_TEXTURE_PAINT) || editing) {
r_mask->lmask |= CD_MASK_MLOOPUV | CD_MASK_PROP_BYTE_COLOR;
r_mask->fmask |= CD_MASK_MTFACE;
}
/* check if we need mcols due to vertex paint or weightpaint */
if (ob->mode & OB_MODE_VERTEX_PAINT) {
r_mask->lmask |= CD_MASK_PROP_BYTE_COLOR;
}
if (ob->mode & OB_MODE_WEIGHT_PAINT) {
r_mask->vmask |= CD_MASK_MDEFORMVERT;
}
if (ob->mode & OB_MODE_EDIT) {
r_mask->vmask |= CD_MASK_MVERT_SKIN;
}
}
}
void makeDerivedMesh(struct Depsgraph *depsgraph,
const Scene *scene,
Object *ob,
const CustomData_MeshMasks *dataMask)
{
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
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,
* they aren't cleaned up properly on mode switch, causing crashes, e.g T58150. */
BLI_assert(ob->id.tag & LIB_TAG_COPIED_ON_WRITE);
BKE_object_free_derived_caches(ob);
if (DEG_is_active(depsgraph)) {
BKE_sculpt_update_object_before_eval(scene, ob);
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
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;
bool need_mapping;
CustomData_MeshMasks cddata_masks = *dataMask;
object_get_datamask(depsgraph, ob, &cddata_masks, &need_mapping);
if (em) {
editbmesh_build_data(depsgraph, scene, ob, em, &cddata_masks);
}
else {
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
}
}
/***/
Mesh *mesh_get_eval_final(struct Depsgraph *depsgraph,
const Scene *scene,
Object *ob,
const CustomData_MeshMasks *dataMask)
{
/* This function isn't thread-safe and can't be used during evaluation. */
BLI_assert(DEG_is_evaluating(depsgraph) == false);
/* Evaluated meshes aren't supposed to be created on original instances. If you do,
* they aren't cleaned up properly on mode switch, causing crashes, e.g T58150. */
BLI_assert(ob->id.tag & LIB_TAG_COPIED_ON_WRITE);
/* if there's no evaluated mesh or the last data mask used doesn't include
* the data we need, rebuild the derived mesh
*/
bool need_mapping;
CustomData_MeshMasks cddata_masks = *dataMask;
object_get_datamask(depsgraph, ob, &cddata_masks, &need_mapping);
Mesh *mesh_eval = BKE_object_get_evaluated_mesh(ob);
if ((mesh_eval == nullptr) ||
!CustomData_MeshMasks_are_matching(&(ob->runtime.last_data_mask), &cddata_masks) ||
(need_mapping && !ob->runtime.last_need_mapping)) {
CustomData_MeshMasks_update(&cddata_masks, &ob->runtime.last_data_mask);
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
2022-01-11 15:42:07 +01:00
makeDerivedMesh(depsgraph, scene, ob, dataMask);
mesh_eval = BKE_object_get_evaluated_mesh(ob);
}
BKE_mesh_assert_normals_dirty_or_calculated(mesh_eval);
return mesh_eval;
}
Mesh *mesh_get_eval_deform(struct Depsgraph *depsgraph,
const Scene *scene,
Object *ob,
const CustomData_MeshMasks *dataMask)
{
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
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;
}
/* This function isn't thread-safe and can't be used during evaluation. */
BLI_assert(DEG_is_evaluating(depsgraph) == false);
/* Evaluated meshes aren't supposed to be created on original instances. If you do,
* they aren't cleaned up properly on mode switch, causing crashes, e.g T58150. */
BLI_assert(ob->id.tag & LIB_TAG_COPIED_ON_WRITE);
/* 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;
CustomData_MeshMasks cddata_masks = *dataMask;
object_get_datamask(depsgraph, ob, &cddata_masks, &need_mapping);
if (!ob->runtime.mesh_deform_eval ||
!CustomData_MeshMasks_are_matching(&(ob->runtime.last_data_mask), &cddata_masks) ||
(need_mapping && !ob->runtime.last_need_mapping)) {
CustomData_MeshMasks_update(&cddata_masks, &ob->runtime.last_data_mask);
mesh_build_data(
depsgraph, scene, ob, &cddata_masks, need_mapping || ob->runtime.last_need_mapping);
}
return ob->runtime.mesh_deform_eval;
}
Mesh *mesh_create_eval_final(Depsgraph *depsgraph,
const Scene *scene,
2020-08-20 08:09:48 +02:00
Object *ob,
const CustomData_MeshMasks *dataMask)
{
Mesh *result;
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
mesh_calc_modifiers(
depsgraph, scene, ob, true, false, dataMask, false, false, nullptr, &result, nullptr);
return result;
}
Mesh *mesh_create_eval_no_deform(Depsgraph *depsgraph,
const Scene *scene,
Object *ob,
const CustomData_MeshMasks *dataMask)
{
Mesh *result;
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
mesh_calc_modifiers(
depsgraph, scene, ob, false, false, dataMask, false, false, nullptr, &result, nullptr);
return result;
}
Mesh *mesh_create_eval_no_deform_render(Depsgraph *depsgraph,
const Scene *scene,
Object *ob,
const CustomData_MeshMasks *dataMask)
{
Mesh *result;
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
mesh_calc_modifiers(
depsgraph, scene, ob, false, false, dataMask, false, false, nullptr, &result, nullptr);
return result;
}
/***/
Mesh *editbmesh_get_eval_cage(struct Depsgraph *depsgraph,
const Scene *scene,
Object *obedit,
BMEditMesh *em,
const CustomData_MeshMasks *dataMask)
{
CustomData_MeshMasks cddata_masks = *dataMask;
/* if there's no derived mesh or the last data mask used doesn't include
* the data we need, rebuild the derived mesh
*/
object_get_datamask(depsgraph, obedit, &cddata_masks, nullptr);
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
2022-01-11 15:42:07 +01:00
if (!obedit->runtime.editmesh_eval_cage ||
!CustomData_MeshMasks_are_matching(&(obedit->runtime.last_data_mask), &cddata_masks)) {
editbmesh_build_data(depsgraph, scene, obedit, em, &cddata_masks);
}
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
2022-01-11 15:42:07 +01:00
return obedit->runtime.editmesh_eval_cage;
}
Mesh *editbmesh_get_eval_cage_from_orig(struct Depsgraph *depsgraph,
const Scene *scene,
Object *obedit,
const CustomData_MeshMasks *dataMask)
{
BLI_assert((obedit->id.tag & LIB_TAG_COPIED_ON_WRITE) == 0);
const Scene *scene_eval = (const Scene *)DEG_get_evaluated_id(depsgraph, (ID *)&scene->id);
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);
}
/***/
/* same as above but for vert coords */
struct MappedUserData {
float (*vertexcos)[3];
BLI_bitmap *vertex_visit;
};
static void make_vertexcos__mapFunc(void *userData,
int index,
const float co[3],
Refactor: Move normals out of MVert, lazy calculation As described in T91186, this commit moves mesh vertex normals into a contiguous array of float vectors in a custom data layer, how face normals are currently stored. The main interface is documented in `BKE_mesh.h`. Vertex and face normals are now calculated on-demand and cached, retrieved with an "ensure" function. Since the logical state of a mesh is now "has normals when necessary", they can be retrieved from a `const` mesh. The goal is to use on-demand calculation for all derived data, but leave room for eager calculation for performance purposes (modifier evaluation is threaded, but viewport data generation is not). **Benefits** This moves us closer to a SoA approach rather than the current AoS paradigm. Accessing a contiguous `float3` is much more efficient than retrieving data from a larger struct. The memory requirements for accessing only normals or vertex locations are smaller, and at the cost of more memory usage for just normals, they now don't have to be converted between float and short, which also simplifies code In the future, the remaining items can be removed from `MVert`, leaving only `float3`, which has similar benefits (see T93602). Removing the combination of derived and original data makes it conceptually simpler to only calculate normals when necessary. This is especially important now that we have more opportunities for temporary meshes in geometry nodes. **Performance** In addition to the theoretical future performance improvements by making `MVert == float3`, I've done some basic performance testing on this patch directly. The data is fairly rough, but it gives an idea about where things stand generally. - Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms), showing that accessing just `MVert` is now more efficient. - Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight change that at least shows there is no regression. - Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small but observable speedup. - Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms), shows that using normals in geometry nodes is faster. - Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms), shows that calculating normals is slightly faster now. - File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB), Normals are not saved in files, which can help with large meshes. As for memory usage, it may be slightly more in some cases, but I didn't observe any difference in the production files I tested. **Tests** Some modifiers and cycles test results need to be updated with this commit, for two reasons: - The subdivision surface modifier is not responsible for calculating normals anymore. In master, the modifier creates different normals than the result of the `Mesh` normal calculation, so this is a bug fix. - There are small differences in the results of some modifiers that use normals because they are not converted to and from `short` anymore. **Future improvements** - Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier already retrieves normals if they are needed anyway. - Copy normals as part of a better CoW system for attributes. - Make more areas use lazy instead of eager normal calculation. - Remove `BKE_mesh_normals_tag_dirty` in more places since that is now the default state of a new mesh. - Possibly apply a similar change to derived face corner normals. Differential Revision: https://developer.blender.org/D12770
2022-01-13 21:37:58 +01:00
const float UNUSED(no[3]))
{
MappedUserData *mappedData = (MappedUserData *)userData;
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);
}
}
void mesh_get_mapped_verts_coords(Mesh *me_eval, float (*r_cos)[3], const int totcos)
{
if (me_eval->runtime.deformed_only == false) {
MappedUserData userData;
2014-09-14 10:50:59 +02:00
memset(r_cos, 0, sizeof(*r_cos) * totcos);
userData.vertexcos = r_cos;
userData.vertex_visit = BLI_BITMAP_NEW(totcos, "vertexcos flags");
BKE_mesh_foreach_mapped_vert(me_eval, make_vertexcos__mapFunc, &userData, MESH_FOREACH_NOP);
MEM_freeN(userData.vertex_visit);
}
else {
MVert *mv = me_eval->mvert;
for (int i = 0; i < totcos; i++, mv++) {
copy_v3_v3(r_cos[i], mv->co);
}
}
}
static void mesh_init_origspace(Mesh *mesh)
{
const float default_osf[4][2] = {{0, 0}, {1, 0}, {1, 1}, {0, 1}};
OrigSpaceLoop *lof_array = (OrigSpaceLoop *)CustomData_get_layer(&mesh->ldata,
CD_ORIGSPACE_MLOOP);
const int numpoly = mesh->totpoly;
// const int numloop = mesh->totloop;
MVert *mv = mesh->mvert;
MLoop *ml = mesh->mloop;
MPoly *mp = mesh->mpoly;
int i, j, k;
blender::Vector<blender::float2, 64> vcos_2d;
for (i = 0; i < numpoly; i++, mp++) {
OrigSpaceLoop *lof = lof_array + mp->loopstart;
2020-11-06 02:30:59 +01:00
if (ELEM(mp->totloop, 3, 4)) {
for (j = 0; j < mp->totloop; j++, lof++) {
copy_v2_v2(lof->uv, default_osf[j]);
}
}
else {
MLoop *l = &ml[mp->loopstart];
float p_nor[3], co[3];
float mat[3][3];
float min[2] = {FLT_MAX, FLT_MAX}, max[2] = {-FLT_MAX, -FLT_MAX};
float translate[2], scale[2];
BKE_mesh_calc_poly_normal(mp, l, mv, p_nor);
axis_dominant_v3_to_m3(mat, p_nor);
vcos_2d.resize(mp->totloop);
for (j = 0; j < mp->totloop; j++, l++) {
mul_v3_m3v3(co, mat, mv[l->v].co);
copy_v2_v2(vcos_2d[j], co);
for (k = 0; k < 2; k++) {
if (co[k] > max[k]) {
max[k] = co[k];
}
else if (co[k] < min[k]) {
min[k] = co[k];
}
}
}
/* Brings min to (0, 0). */
negate_v2_v2(translate, min);
/* Scale will bring max to (1, 1). */
sub_v2_v2v2(scale, max, min);
if (scale[0] == 0.0f) {
scale[0] = 1e-9f;
}
if (scale[1] == 0.0f) {
scale[1] = 1e-9f;
}
invert_v2(scale);
/* Finally, transform all vcos_2d into ((0, 0), (1, 1))
* square and assign them as origspace. */
for (j = 0; j < mp->totloop; j++, lof++) {
add_v2_v2v2(lof->uv, vcos_2d[j], translate);
mul_v2_v2(lof->uv, scale);
}
}
}
BKE_mesh_tessface_clear(mesh);
}