archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
7a4b784909b3d31f318f92ddcfd534223f3e8412
blender-archive/source/blender/modifiers/intern/MOD_datatransfer.c

246 lines
8.0 KiB
C
Raw Normal View History

Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
/*
* ***** BEGIN GPL LICENSE BLOCK *****
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
* The Original Code is Copyright (C) 2014 Blender Foundation.
* All rights reserved.
*
* Contributor(s): None yet.
*
* ***** END GPL LICENSE BLOCK *****
*
*/
/** \file blender/modifiers/intern/MOD_datatransfer.c
* \ingroup modifiers
*/
#include "BLI_utildefines.h"
#include "BLI_math.h"
#include "DNA_mesh_types.h"
#include "DNA_meshdata_types.h"
#include "DNA_modifier_types.h"
#include "DNA_object_types.h"
#include "BKE_customdata.h"
Fix T43671: Playing with Mix Factor of Data Transfer Modifier Is Overwritting Data of Base Mesh The issue was actually affecting all data types that are not regular CDLayer ones, since by default DerivedMesh references mesh data (verts, edges, etc. - modifying custom normals often implies modifying edges' sarpness too). Modfying edge/face sharpness etc. could directly affect the mesh in this case, **bad**! So we detect whether we are copying data types that may affect non-CDlayers data, and whether verts array of org dm is same as mesh one - in which case we copy the DM. This avoids useless copying in most cases. Note Edit Normals was quite obviously suffering the same issue.
2015-02-15 18:46:46 +01:00
#include "BKE_cdderivedmesh.h"
Cleanup: rename BKE's 'object_data_transfer' to 'data_transfer' to avoid same file names with ED_object's one.
2015-01-12 12:03:28 +01:00
#include "BKE_data_transfer.h"
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
#include "BKE_library.h"
Modifiers: add 'cd_flag' parameter to their ID looping callbacks, needed since some IDs (objects) are not 'refcounted' while others (textures) are... Partial merge from id-remap branch.
2015-10-08 14:21:11 +02:00
#include "BKE_library_query.h"
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
#include "BKE_mesh_mapping.h"
#include "BKE_mesh_remap.h"
#include "BKE_modifier.h"
#include "BKE_report.h"
#include "MEM_guardedalloc.h"
#include "MOD_util.h"
/**************************************
* Modifiers functions. *
**************************************/
static void initData(ModifierData *md)
{
DataTransferModifierData *dtmd = (DataTransferModifierData *) md;
int i;
dtmd->ob_source = NULL;
dtmd->data_types = 0;
dtmd->vmap_mode = MREMAP_MODE_VERT_NEAREST;
dtmd->emap_mode = MREMAP_MODE_EDGE_NEAREST;
dtmd->lmap_mode = MREMAP_MODE_LOOP_NEAREST_POLYNOR;
dtmd->pmap_mode = MREMAP_MODE_POLY_NEAREST;
dtmd->map_max_distance = 1.0f;
dtmd->map_ray_radius = 0.0f;
for (i = 0; i < DT_MULTILAYER_INDEX_MAX; i++) {
dtmd->layers_select_src[i] = DT_LAYERS_ALL_SRC;
dtmd->layers_select_dst[i] = DT_LAYERS_NAME_DST;
}
dtmd->mix_mode = CDT_MIX_TRANSFER;
dtmd->mix_factor = 1.0f;
dtmd->defgrp_name[0] = '\0';
dtmd->flags = MOD_DATATRANSFER_OBSRC_TRANSFORM;
}
static CustomDataMask requiredDataMask(Object *UNUSED(ob), ModifierData *md)
{
DataTransferModifierData *dtmd = (DataTransferModifierData *) md;
CustomDataMask dataMask = 0;
if (dtmd->defgrp_name[0]) {
/* We need vertex groups! */
dataMask |= CD_MASK_MDEFORMVERT;
}
dataMask |= BKE_object_data_transfer_dttypes_to_cdmask(dtmd->data_types);
return dataMask;
}
static bool dependsOnNormals(ModifierData *md)
{
DataTransferModifierData *dtmd = (DataTransferModifierData *) md;
int item_types = BKE_object_data_transfer_get_dttypes_item_types(dtmd->data_types);
if ((item_types & ME_VERT) && (dtmd->vmap_mode & (MREMAP_USE_NORPROJ | MREMAP_USE_NORMAL))) {
return true;
}
if ((item_types & ME_EDGE) && (dtmd->emap_mode & (MREMAP_USE_NORPROJ | MREMAP_USE_NORMAL))) {
return true;
}
if ((item_types & ME_LOOP) && (dtmd->lmap_mode & (MREMAP_USE_NORPROJ | MREMAP_USE_NORMAL))) {
return true;
}
if ((item_types & ME_POLY) && (dtmd->pmap_mode & (MREMAP_USE_NORPROJ | MREMAP_USE_NORMAL))) {
return true;
}
return false;
}
Cleanup: use proper `ObjectWalkFunc` typedef in modifiers' object callback func. Also, fix own stupidity, no need to define ID callback in case we only have objects, calling code knows to fallback to `foreachObjectLink()` when `foreachIDLink()` is missing...
2015-10-05 15:57:10 +02:00
static void foreachObjectLink(
ModifierData *md, Object *ob,
ObjectWalkFunc walk, void *userData)
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
{
DataTransferModifierData *dtmd = (DataTransferModifierData *) md;
Cleanup: Rename callback flags from library_query to `IDWALK_CB_...` Better to have clear way to tell whether flag is parameter for BKE_library_foreach_ID_link(), parameter for its callback function, or return value from this callback function.
2017-01-31 09:47:59 +01:00
walk(userData, ob, &dtmd->ob_source, IDWALK_CB_NOP);
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
}
Depsgraph: Wrap all arguments foe modifiers relations update into a struct Makes it easier to add or remove fields needed to update relations.
2018-02-22 12:54:06 +01:00
static void updateDepsgraph(ModifierData *md, const ModifierUpdateDepsgraphContext *ctx)
Depsgraph: New dependency graph integration commit This commit integrates the work done so far on the new dependency graph system, where goal was to replace legacy depsgraph with the new one, supporting loads of neat features like: - More granular dependency relation nature, which solves issues with fake cycles in the dependencies. - Move towards all-animatable, by better integration of drivers into the system. - Lay down some basis for upcoming copy-on-write, overrides and so on. The new system is living side-by-side with the previous one and disabled by default, so nothing will become suddenly broken. The way to enable new depsgraph is to pass `--new-depsgraph` command line argument. It's a bit early to consider the system production-ready, there are some TODOs and issues were discovered during the merge period, they'll be addressed ASAP. But it's important to merge, because it's the only way to attract artists to really start testing this system. There are number of assorted documents related on the design of the new system: * http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents * http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph There are also some user-related information online: * http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/ * http://code.blender.org/2015/03/more-dependency-graph-tricks/ Kudos to everyone who was involved into the project: - Joshua "Aligorith" Leung -- design specification, initial code - Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes - Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the project and so - Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the issues and recording/writing documentation. - Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
{
DataTransferModifierData *dtmd = (DataTransferModifierData *) md;
if (dtmd->ob_source != NULL) {
Depsgraph: Wrap all arguments foe modifiers relations update into a struct Makes it easier to add or remove fields needed to update relations.
2018-02-22 12:54:06 +01:00
DEG_add_object_relation(ctx->node, dtmd->ob_source, DEG_OB_COMP_GEOMETRY, "DataTransfer Modifier");
Depsgraph: New dependency graph integration commit This commit integrates the work done so far on the new dependency graph system, where goal was to replace legacy depsgraph with the new one, supporting loads of neat features like: - More granular dependency relation nature, which solves issues with fake cycles in the dependencies. - Move towards all-animatable, by better integration of drivers into the system. - Lay down some basis for upcoming copy-on-write, overrides and so on. The new system is living side-by-side with the previous one and disabled by default, so nothing will become suddenly broken. The way to enable new depsgraph is to pass `--new-depsgraph` command line argument. It's a bit early to consider the system production-ready, there are some TODOs and issues were discovered during the merge period, they'll be addressed ASAP. But it's important to merge, because it's the only way to attract artists to really start testing this system. There are number of assorted documents related on the design of the new system: * http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents * http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph There are also some user-related information online: * http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/ * http://code.blender.org/2015/03/more-dependency-graph-tricks/ Kudos to everyone who was involved into the project: - Joshua "Aligorith" Leung -- design specification, initial code - Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes - Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the project and so - Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the issues and recording/writing documentation. - Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
}
}
Modifiers: Stop using md->scene in isDisabled() callback This is first commit in series of changes to get rid of md->scene.
2018-06-21 17:54:12 +02:00
static bool isDisabled(const struct Scene *UNUSED(scene), ModifierData *md, int UNUSED(useRenderParams))
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
{
DataTransferModifierData *dtmd = (DataTransferModifierData *) md;
/* If no source object, bypass. */
return (dtmd->ob_source == NULL);
}
#define HIGH_POLY_WARNING 10000
Fix T43671: Playing with Mix Factor of Data Transfer Modifier Is Overwritting Data of Base Mesh The issue was actually affecting all data types that are not regular CDLayer ones, since by default DerivedMesh references mesh data (verts, edges, etc. - modifying custom normals often implies modifying edges' sarpness too). Modfying edge/face sharpness etc. could directly affect the mesh in this case, **bad**! So we detect whether we are copying data types that may affect non-CDlayers data, and whether verts array of org dm is same as mesh one - in which case we copy the DM. This avoids useless copying in most cases. Note Edit Normals was quite obviously suffering the same issue.
2015-02-15 18:46:46 +01:00
#define DT_TYPES_AFFECT_MESH ( \
DT_TYPE_BWEIGHT_VERT | \
DT_TYPE_BWEIGHT_EDGE | DT_TYPE_CREASE | DT_TYPE_SHARP_EDGE | \
DT_TYPE_LNOR | \
DT_TYPE_SHARP_FACE \
)
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
Cleanup: nuke DM out of data transfer code. This was actually rather hairy, this code is huge and complicated, easy to make mistakes... Good thing is, it will allow for significant simplification and more (name) cleanup in following commits ;)
2018-06-21 14:39:28 +02:00
static Mesh *applyModifier(ModifierData *md, const ModifierEvalContext *ctx, Mesh *me_mod)
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
{
DataTransferModifierData *dtmd = (DataTransferModifierData *) md;
Cleanup: nuke DM out of data transfer code. This was actually rather hairy, this code is huge and complicated, easy to make mistakes... Good thing is, it will allow for significant simplification and more (name) cleanup in following commits ;)
2018-06-21 14:39:28 +02:00
Mesh *result = me_mod;
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
ReportList reports;
Fix T43671: Playing with Mix Factor of Data Transfer Modifier Is Overwritting Data of Base Mesh The issue was actually affecting all data types that are not regular CDLayer ones, since by default DerivedMesh references mesh data (verts, edges, etc. - modifying custom normals often implies modifying edges' sarpness too). Modfying edge/face sharpness etc. could directly affect the mesh in this case, **bad**! So we detect whether we are copying data types that may affect non-CDlayers data, and whether verts array of org dm is same as mesh one - in which case we copy the DM. This avoids useless copying in most cases. Note Edit Normals was quite obviously suffering the same issue.
2015-02-15 18:46:46 +01:00
/* Only used to check wehther we are operating on org data or not... */
Extract common modifier parameters into ModifierEvalContext struct The contents of the ModifierEvalContext struct are constant while iterating over the modifier stack. The struct thus should be only created once, outside any loop over the modifiers.
2018-05-01 17:33:04 +02:00
Mesh *me = ctx->object->data;
Fix T43671: Playing with Mix Factor of Data Transfer Modifier Is Overwritting Data of Base Mesh The issue was actually affecting all data types that are not regular CDLayer ones, since by default DerivedMesh references mesh data (verts, edges, etc. - modifying custom normals often implies modifying edges' sarpness too). Modfying edge/face sharpness etc. could directly affect the mesh in this case, **bad**! So we detect whether we are copying data types that may affect non-CDlayers data, and whether verts array of org dm is same as mesh one - in which case we copy the DM. This avoids useless copying in most cases. Note Edit Normals was quite obviously suffering the same issue.
2015-02-15 18:46:46 +01:00
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
const bool invert_vgroup = (dtmd->flags & MOD_DATATRANSFER_INVERT_VGROUP) != 0;
const float max_dist = (dtmd->flags & MOD_DATATRANSFER_MAP_MAXDIST) ? dtmd->map_max_distance : FLT_MAX;
SpaceTransform space_transform_data;
SpaceTransform *space_transform = (dtmd->flags & MOD_DATATRANSFER_OBSRC_TRANSFORM) ? &space_transform_data : NULL;
if (space_transform) {
Extract common modifier parameters into ModifierEvalContext struct The contents of the ModifierEvalContext struct are constant while iterating over the modifier stack. The struct thus should be only created once, outside any loop over the modifiers.
2018-05-01 17:33:04 +02:00
BLI_SPACE_TRANSFORM_SETUP(space_transform, ctx->object, dtmd->ob_source);
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
}
Cleanup: nuke DM out of data transfer code. This was actually rather hairy, this code is huge and complicated, easy to make mistakes... Good thing is, it will allow for significant simplification and more (name) cleanup in following commits ;)
2018-06-21 14:39:28 +02:00
if ((result == me_mod || (me->mvert == result->mvert) || (me->medge == result->medge)) &&
(dtmd->data_types & DT_TYPES_AFFECT_MESH))
{
Fix T43671: Playing with Mix Factor of Data Transfer Modifier Is Overwritting Data of Base Mesh The issue was actually affecting all data types that are not regular CDLayer ones, since by default DerivedMesh references mesh data (verts, edges, etc. - modifying custom normals often implies modifying edges' sarpness too). Modfying edge/face sharpness etc. could directly affect the mesh in this case, **bad**! So we detect whether we are copying data types that may affect non-CDlayers data, and whether verts array of org dm is same as mesh one - in which case we copy the DM. This avoids useless copying in most cases. Note Edit Normals was quite obviously suffering the same issue.
2015-02-15 18:46:46 +01:00
/* We need to duplicate data here, otherwise setting custom normals, edges' shaprness, etc., could
* modify org mesh, see T43671. */
Cleanup: nuke DM out of data transfer code. This was actually rather hairy, this code is huge and complicated, easy to make mistakes... Good thing is, it will allow for significant simplification and more (name) cleanup in following commits ;)
2018-06-21 14:39:28 +02:00
BKE_id_copy_ex(
NULL, &me_mod->id, (ID **)&result,
LIB_ID_CREATE_NO_MAIN |
LIB_ID_CREATE_NO_USER_REFCOUNT |
LIB_ID_CREATE_NO_DEG_TAG |
LIB_ID_COPY_NO_PREVIEW,
false);
Fix T43671: Playing with Mix Factor of Data Transfer Modifier Is Overwritting Data of Base Mesh The issue was actually affecting all data types that are not regular CDLayer ones, since by default DerivedMesh references mesh data (verts, edges, etc. - modifying custom normals often implies modifying edges' sarpness too). Modfying edge/face sharpness etc. could directly affect the mesh in this case, **bad**! So we detect whether we are copying data types that may affect non-CDlayers data, and whether verts array of org dm is same as mesh one - in which case we copy the DM. This avoids useless copying in most cases. Note Edit Normals was quite obviously suffering the same issue.
2015-02-15 18:46:46 +01:00
}
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
BKE_reports_init(&reports, RPT_STORE);
/* Note: no islands precision for now here. */
Cleanup: names: data transfer/mesh remap: dm -> me/mesh. That area is now officially purged from the Devil.. errr... DerivedMesh!
2018-06-21 15:32:01 +02:00
BKE_object_data_transfer_ex(ctx->depsgraph, md->scene, dtmd->ob_source, ctx->object, result, dtmd->data_types, false,
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
dtmd->vmap_mode, dtmd->emap_mode, dtmd->lmap_mode, dtmd->pmap_mode,
Data Transfer: Add an option to 'auto-transform' destination mesh so that it matches best the source one. This allows to match and transfer data between two meshes with similar shape but complete arbitrary different transform. Note that the result will be best if the meshes (more precisely, their vertices) are exact copies of each other. Otherwise, method used can only perform an approximated best match, which means you'll likely get better results if you 'visually' make them match in 3D space (and use 'Object Transform') instead.
2015-07-13 18:00:08 +02:00
space_transform, false, max_dist, dtmd->map_ray_radius, 0.0f,
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
dtmd->layers_select_src, dtmd->layers_select_dst,
dtmd->mix_mode, dtmd->mix_factor, dtmd->defgrp_name, invert_vgroup, &reports);
if (BKE_reports_contain(&reports, RPT_ERROR)) {
modifier_setError(md, "%s", BKE_reports_string(&reports, RPT_ERROR));
}
Fix T50534, Part II: warn user when DataTransfer mod affects custom normals. Custom normals need Autosmooth setting to be enabled, always!
2017-01-27 19:06:10 +01:00
else if ((dtmd->data_types & DT_TYPE_LNOR) && !(me->flag & ME_AUTOSMOOTH)) {
modifier_setError((ModifierData *)dtmd, "Enable 'Auto Smooth' option in mesh settings");
}
Cleanup: nuke DM out of data transfer code. This was actually rather hairy, this code is huge and complicated, easy to make mistakes... Good thing is, it will allow for significant simplification and more (name) cleanup in following commits ;)
2018-06-21 14:39:28 +02:00
else if (result->totvert > HIGH_POLY_WARNING || ((Mesh *)(dtmd->ob_source->data))->totvert > HIGH_POLY_WARNING) {
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
modifier_setError(md, "You are using a rather high poly as source or destination, computation might be slow");
}
Cleanup: nuke DM out of data transfer code. This was actually rather hairy, this code is huge and complicated, easy to make mistakes... Good thing is, it will allow for significant simplification and more (name) cleanup in following commits ;)
2018-06-21 14:39:28 +02:00
return result;
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
}
Fix T43671: Playing with Mix Factor of Data Transfer Modifier Is Overwritting Data of Base Mesh The issue was actually affecting all data types that are not regular CDLayer ones, since by default DerivedMesh references mesh data (verts, edges, etc. - modifying custom normals often implies modifying edges' sarpness too). Modfying edge/face sharpness etc. could directly affect the mesh in this case, **bad**! So we detect whether we are copying data types that may affect non-CDlayers data, and whether verts array of org dm is same as mesh one - in which case we copy the DM. This avoids useless copying in most cases. Note Edit Normals was quite obviously suffering the same issue.
2015-02-15 18:46:46 +01:00
#undef HIGH_POLY_WARNING
#undef DT_TYPES_AFFECT_MESH
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
ModifierTypeInfo modifierType_DataTransfer = {
/* name */ "DataTransfer",
/* structName */ "DataTransferModifierData",
/* structSize */ sizeof(DataTransferModifierData),
/* type */ eModifierTypeType_NonGeometrical,
/* flags */ eModifierTypeFlag_AcceptsMesh |
eModifierTypeFlag_SupportsMapping |
eModifierTypeFlag_SupportsEditmode |
eModifierTypeFlag_UsesPreview,
Cleanup: Nuke empty dummy wrappers around modifier_copyData_generic(). This also changes signature of modifier copy callback, first (source) parameter is now a const, which is saner anyway!
2018-05-08 15:04:10 +02:00
/* copyData */ modifier_copyData_generic,
Modifiers: Add wrapper functions with Mesh / DerivedMesh conversion Makes the follow changes: - Add new `deform*` and `apply*` function pointers to `ModifierTypeInfo` that take `Mesh`, and rename the old functions to indicate that they take `DerivedMesh`. These new functions are currently set to `NULL` for all modifiers. - Add wrapper `modifier_deform*` and `modifier_apply*` functions in two variants: one that works with `Mesh` and the other which works with `DerivedMesh` that is named with `*_DM_depercated`. These functions check which type of data the modifier supports and converts if necessary - Update the rest of Blender to be aware and make use of these new functions The goal of these changes is to make it possible to port to using `Mesh` incrementally without ever needing to enter into a state where modifiers don't work. After everything has been ported over the old functions and wrappers could be removed. Reviewers: campbellbarton, sergey, mont29 Subscribers: sybren Tags: #bf_blender_2.8 Differential Revision: https://developer.blender.org/D3155
2018-04-18 15:45:54 +02:00
/* deformVerts_DM */ NULL,
/* deformMatrices_DM */ NULL,
/* deformVertsEM_DM */ NULL,
/* deformMatricesEM_DM*/NULL,
Cleanup: nuke DM out of data transfer code. This was actually rather hairy, this code is huge and complicated, easy to make mistakes... Good thing is, it will allow for significant simplification and more (name) cleanup in following commits ;)
2018-06-21 14:39:28 +02:00
/* applyModifier_DM */ NULL,
Modifiers: Add wrapper functions with Mesh / DerivedMesh conversion Makes the follow changes: - Add new `deform*` and `apply*` function pointers to `ModifierTypeInfo` that take `Mesh`, and rename the old functions to indicate that they take `DerivedMesh`. These new functions are currently set to `NULL` for all modifiers. - Add wrapper `modifier_deform*` and `modifier_apply*` functions in two variants: one that works with `Mesh` and the other which works with `DerivedMesh` that is named with `*_DM_depercated`. These functions check which type of data the modifier supports and converts if necessary - Update the rest of Blender to be aware and make use of these new functions The goal of these changes is to make it possible to port to using `Mesh` incrementally without ever needing to enter into a state where modifiers don't work. After everything has been ported over the old functions and wrappers could be removed. Reviewers: campbellbarton, sergey, mont29 Subscribers: sybren Tags: #bf_blender_2.8 Differential Revision: https://developer.blender.org/D3155
2018-04-18 15:45:54 +02:00
/* applyModifierEM_DM */NULL,
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
/* deformVerts */ NULL,
/* deformMatrices */ NULL,
/* deformVertsEM */ NULL,
/* deformMatricesEM */ NULL,
Cleanup: nuke DM out of data transfer code. This was actually rather hairy, this code is huge and complicated, easy to make mistakes... Good thing is, it will allow for significant simplification and more (name) cleanup in following commits ;)
2018-06-21 14:39:28 +02:00
/* applyModifier */ applyModifier,
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
/* applyModifierEM */ NULL,
Modifiers: Add wrapper functions with Mesh / DerivedMesh conversion Makes the follow changes: - Add new `deform*` and `apply*` function pointers to `ModifierTypeInfo` that take `Mesh`, and rename the old functions to indicate that they take `DerivedMesh`. These new functions are currently set to `NULL` for all modifiers. - Add wrapper `modifier_deform*` and `modifier_apply*` functions in two variants: one that works with `Mesh` and the other which works with `DerivedMesh` that is named with `*_DM_depercated`. These functions check which type of data the modifier supports and converts if necessary - Update the rest of Blender to be aware and make use of these new functions The goal of these changes is to make it possible to port to using `Mesh` incrementally without ever needing to enter into a state where modifiers don't work. After everything has been ported over the old functions and wrappers could be removed. Reviewers: campbellbarton, sergey, mont29 Subscribers: sybren Tags: #bf_blender_2.8 Differential Revision: https://developer.blender.org/D3155
2018-04-18 15:45:54 +02:00
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
/* initData */ initData,
/* requiredDataMask */ requiredDataMask,
/* freeData */ NULL,
/* isDisabled */ isDisabled,
Depsgraph: New dependency graph integration commit This commit integrates the work done so far on the new dependency graph system, where goal was to replace legacy depsgraph with the new one, supporting loads of neat features like: - More granular dependency relation nature, which solves issues with fake cycles in the dependencies. - Move towards all-animatable, by better integration of drivers into the system. - Lay down some basis for upcoming copy-on-write, overrides and so on. The new system is living side-by-side with the previous one and disabled by default, so nothing will become suddenly broken. The way to enable new depsgraph is to pass `--new-depsgraph` command line argument. It's a bit early to consider the system production-ready, there are some TODOs and issues were discovered during the merge period, they'll be addressed ASAP. But it's important to merge, because it's the only way to attract artists to really start testing this system. There are number of assorted documents related on the design of the new system: * http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents * http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph There are also some user-related information online: * http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/ * http://code.blender.org/2015/03/more-dependency-graph-tricks/ Kudos to everyone who was involved into the project: - Joshua "Aligorith" Leung -- design specification, initial code - Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes - Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the project and so - Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the issues and recording/writing documentation. - Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
/* updateDepsgraph */ updateDepsgraph,
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
/* dependsOnTime */ NULL,
/* dependsOnNormals */ dependsOnNormals,
/* foreachObjectLink */ foreachObjectLink,
Cleanup: use proper `ObjectWalkFunc` typedef in modifiers' object callback func. Also, fix own stupidity, no need to define ID callback in case we only have objects, calling code knows to fallback to `foreachObjectLink()` when `foreachIDLink()` is missing...
2015-10-05 15:57:10 +02:00
/* foreachIDLink */ NULL,
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
/* foreachTexLink */ NULL,
};
Copy Permalink