2010-04-11 22:12:30 +00:00
|
|
|
/*
|
2011-10-23 17:52:20 +00:00
|
|
|
* 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) 2005 by the Blender Foundation.
|
|
|
|
* All rights reserved.
|
|
|
|
*/
|
2010-04-11 22:12:30 +00:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
* \ingroup modifiers
|
2014-08-12 13:52:17 +10:00
|
|
|
*
|
|
|
|
* Array modifier: duplicates the object multiple times along an axis.
|
2011-12-29 04:04:27 +00:00
|
|
|
*/
|
|
|
|
|
2010-08-16 05:46:10 +00:00
|
|
|
#include "MEM_guardedalloc.h"
|
2010-04-11 22:12:30 +00:00
|
|
|
|
2011-12-29 04:04:27 +00:00
|
|
|
#include "BLI_math.h"
|
2011-05-09 04:06:48 +00:00
|
|
|
#include "BLI_utildefines.h"
|
2010-04-11 22:12:30 +00:00
|
|
|
|
2010-08-16 05:46:10 +00:00
|
|
|
#include "DNA_curve_types.h"
|
2018-04-25 16:47:52 +02:00
|
|
|
#include "DNA_mesh_types.h"
|
2010-08-16 05:46:10 +00:00
|
|
|
#include "DNA_meshdata_types.h"
|
|
|
|
#include "DNA_object_types.h"
|
2012-02-11 10:15:11 +00:00
|
|
|
#include "DNA_scene_types.h"
|
2010-08-16 05:46:10 +00:00
|
|
|
|
2010-04-11 22:12:30 +00:00
|
|
|
#include "BKE_displist.h"
|
2013-08-19 09:25:24 +00:00
|
|
|
#include "BKE_curve.h"
|
2018-05-30 11:34:08 +02:00
|
|
|
#include "BKE_library.h"
|
2015-10-08 14:21:11 +02:00
|
|
|
#include "BKE_library_query.h"
|
2010-04-11 22:12:30 +00:00
|
|
|
#include "BKE_modifier.h"
|
2017-06-08 09:17:08 +02:00
|
|
|
#include "BKE_mesh.h"
|
2018-03-06 09:57:41 +11:00
|
|
|
#include "BKE_object_deform.h"
|
2012-10-24 07:24:11 +00:00
|
|
|
|
2013-12-26 17:24:42 +06:00
|
|
|
#include "MOD_util.h"
|
|
|
|
|
2017-04-06 15:37:46 +02:00
|
|
|
#include "DEG_depsgraph.h"
|
2018-12-07 15:45:53 +01:00
|
|
|
#include "DEG_depsgraph_query.h"
|
2017-04-06 15:37:46 +02:00
|
|
|
|
2010-04-11 22:12:30 +00:00
|
|
|
static void initData(ModifierData *md)
|
|
|
|
{
|
2012-05-06 13:38:33 +00:00
|
|
|
ArrayModifierData *amd = (ArrayModifierData *) md;
|
2010-04-11 22:12:30 +00:00
|
|
|
|
|
|
|
/* default to 2 duplicates distributed along the x-axis by an
|
2012-03-09 18:28:30 +00:00
|
|
|
* offset of 1 object-width
|
|
|
|
*/
|
2010-04-11 22:12:30 +00:00
|
|
|
amd->start_cap = amd->end_cap = amd->curve_ob = amd->offset_ob = NULL;
|
|
|
|
amd->count = 2;
|
2012-03-23 20:18:09 +00:00
|
|
|
zero_v3(amd->offset);
|
2010-04-11 22:12:30 +00:00
|
|
|
amd->scale[0] = 1;
|
|
|
|
amd->scale[1] = amd->scale[2] = 0;
|
|
|
|
amd->length = 0;
|
|
|
|
amd->merge_dist = 0.01;
|
|
|
|
amd->fit_type = MOD_ARR_FIXEDCOUNT;
|
|
|
|
amd->offset_type = MOD_ARR_OFF_RELATIVE;
|
|
|
|
amd->flags = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void foreachObjectLink(
|
2012-05-06 13:38:33 +00:00
|
|
|
ModifierData *md, Object *ob,
|
2015-10-05 15:57:10 +02:00
|
|
|
ObjectWalkFunc walk, void *userData)
|
2010-04-11 22:12:30 +00:00
|
|
|
{
|
2012-05-06 13:38:33 +00:00
|
|
|
ArrayModifierData *amd = (ArrayModifierData *) md;
|
2010-04-11 22:12:30 +00:00
|
|
|
|
2017-01-31 09:47:59 +01:00
|
|
|
walk(userData, ob, &amd->start_cap, IDWALK_CB_NOP);
|
|
|
|
walk(userData, ob, &amd->end_cap, IDWALK_CB_NOP);
|
|
|
|
walk(userData, ob, &amd->curve_ob, IDWALK_CB_NOP);
|
|
|
|
walk(userData, ob, &amd->offset_ob, IDWALK_CB_NOP);
|
2010-04-11 22:12:30 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
|
|
|
ArrayModifierData *amd = (ArrayModifierData *)md;
|
|
|
|
if (amd->start_cap != NULL) {
|
2018-02-22 12:54:06 +01:00
|
|
|
DEG_add_object_relation(ctx->node, amd->start_cap, DEG_OB_COMP_TRANSFORM, "Array Modifier Start Cap");
|
2018-04-25 16:34:01 +02:00
|
|
|
DEG_add_object_relation(ctx->node, amd->start_cap, DEG_OB_COMP_GEOMETRY, "Array Modifier Start Cap");
|
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
|
|
|
}
|
|
|
|
if (amd->end_cap != NULL) {
|
2018-02-22 12:54:06 +01:00
|
|
|
DEG_add_object_relation(ctx->node, amd->end_cap, DEG_OB_COMP_TRANSFORM, "Array Modifier End Cap");
|
2018-04-25 16:34:01 +02:00
|
|
|
DEG_add_object_relation(ctx->node, amd->end_cap, DEG_OB_COMP_GEOMETRY, "Array Modifier End Cap");
|
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
|
|
|
}
|
|
|
|
if (amd->curve_ob) {
|
2018-02-22 12:54:06 +01:00
|
|
|
DEG_add_object_relation(ctx->node, amd->curve_ob, DEG_OB_COMP_GEOMETRY, "Array Modifier Curve");
|
2018-10-24 12:31:24 +03:00
|
|
|
DEG_add_special_eval_flag(ctx->node, &amd->curve_ob->id, DAG_EVAL_NEED_CURVE_PATH);
|
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
|
|
|
}
|
|
|
|
if (amd->offset_ob != NULL) {
|
2018-02-22 12:54:06 +01:00
|
|
|
DEG_add_object_relation(ctx->node, amd->offset_ob, DEG_OB_COMP_TRANSFORM, "Array Modifier Offset");
|
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
|
|
|
}
|
2019-02-12 12:01:17 +01:00
|
|
|
DEG_add_modifier_to_transform_relation(ctx->node, "Array 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
|
|
|
}
|
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
BLI_INLINE float sum_v3(const float v[3])
|
2012-03-28 22:03:46 +00:00
|
|
|
{
|
2014-08-12 13:52:17 +10:00
|
|
|
return v[0] + v[1] + v[2];
|
|
|
|
}
|
2012-03-28 22:03:46 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* Structure used for sorting vertices, when processing doubles */
|
|
|
|
typedef struct SortVertsElem {
|
|
|
|
int vertex_num; /* The original index of the vertex, prior to sorting */
|
|
|
|
float co[3]; /* Its coordinates */
|
|
|
|
float sum_co; /* sum_v3(co), just so we don't do the sum many times. */
|
|
|
|
} SortVertsElem;
|
2012-03-28 22:03:46 +00:00
|
|
|
|
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
static int svert_sum_cmp(const void *e1, const void *e2)
|
|
|
|
{
|
2015-01-01 23:26:03 +11:00
|
|
|
const SortVertsElem *sv1 = e1;
|
|
|
|
const SortVertsElem *sv2 = e2;
|
2012-03-28 22:03:46 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
if (sv1->sum_co > sv2->sum_co) return 1;
|
|
|
|
else if (sv1->sum_co < sv2->sum_co) return -1;
|
|
|
|
else return 0;
|
|
|
|
}
|
2012-03-28 22:03:46 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
static void svert_from_mvert(SortVertsElem *sv, const MVert *mv, const int i_begin, const int i_end)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = i_begin; i < i_end; i++, sv++, mv++) {
|
|
|
|
sv->vertex_num = i;
|
|
|
|
copy_v3_v3(sv->co, mv->co);
|
|
|
|
sv->sum_co = sum_v3(mv->co);
|
|
|
|
}
|
2012-03-28 22:03:46 +00:00
|
|
|
}
|
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/**
|
|
|
|
* Take as inputs two sets of verts, to be processed for detection of doubles and mapping.
|
|
|
|
* Each set of verts is defined by its start within mverts array and its num_verts;
|
|
|
|
* It builds a mapping for all vertices within source, to vertices within target, or -1 if no double found
|
|
|
|
* The int doubles_map[num_verts_source] array must have been allocated by caller.
|
2012-03-30 17:30:56 +00:00
|
|
|
*/
|
2014-08-12 13:52:17 +10:00
|
|
|
static void dm_mvert_map_doubles(
|
|
|
|
int *doubles_map,
|
|
|
|
const MVert *mverts,
|
|
|
|
const int target_start,
|
|
|
|
const int target_num_verts,
|
|
|
|
const int source_start,
|
|
|
|
const int source_num_verts,
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
const float dist)
|
2012-03-30 17:30:56 +00:00
|
|
|
{
|
2015-01-31 17:23:30 +11:00
|
|
|
const float dist3 = ((float)M_SQRT3 + 0.00005f) * dist; /* Just above sqrt(3) */
|
2014-08-12 13:52:17 +10:00
|
|
|
int i_source, i_target, i_target_low_bound, target_end, source_end;
|
|
|
|
SortVertsElem *sorted_verts_target, *sorted_verts_source;
|
|
|
|
SortVertsElem *sve_source, *sve_target, *sve_target_low_bound;
|
|
|
|
bool target_scan_completed;
|
|
|
|
|
|
|
|
target_end = target_start + target_num_verts;
|
|
|
|
source_end = source_start + source_num_verts;
|
|
|
|
|
|
|
|
/* build array of MVerts to be tested for merging */
|
2018-01-14 22:14:20 +01:00
|
|
|
sorted_verts_target = MEM_malloc_arrayN(target_num_verts, sizeof(SortVertsElem), __func__);
|
|
|
|
sorted_verts_source = MEM_malloc_arrayN(source_num_verts, sizeof(SortVertsElem), __func__);
|
2014-08-12 13:52:17 +10:00
|
|
|
|
|
|
|
/* Copy target vertices index and cos into SortVertsElem array */
|
|
|
|
svert_from_mvert(sorted_verts_target, mverts + target_start, target_start, target_end);
|
|
|
|
|
|
|
|
/* Copy source vertices index and cos into SortVertsElem array */
|
|
|
|
svert_from_mvert(sorted_verts_source, mverts + source_start, source_start, source_end);
|
|
|
|
|
|
|
|
/* sort arrays according to sum of vertex coordinates (sumco) */
|
|
|
|
qsort(sorted_verts_target, target_num_verts, sizeof(SortVertsElem), svert_sum_cmp);
|
|
|
|
qsort(sorted_verts_source, source_num_verts, sizeof(SortVertsElem), svert_sum_cmp);
|
|
|
|
|
|
|
|
sve_target_low_bound = sorted_verts_target;
|
|
|
|
i_target_low_bound = 0;
|
|
|
|
target_scan_completed = false;
|
|
|
|
|
|
|
|
/* Scan source vertices, in SortVertsElem sorted array, */
|
|
|
|
/* all the while maintaining the lower bound of possible doubles in target vertices */
|
|
|
|
for (i_source = 0, sve_source = sorted_verts_source;
|
|
|
|
i_source < source_num_verts;
|
|
|
|
i_source++, sve_source++)
|
|
|
|
{
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
int best_target_vertex = -1;
|
|
|
|
float best_dist_sq = dist * dist;
|
2014-08-12 13:52:17 +10:00
|
|
|
float sve_source_sumco;
|
2012-03-30 17:30:56 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* If source has already been assigned to a target (in an earlier call, with other chunks) */
|
|
|
|
if (doubles_map[sve_source->vertex_num] != -1) {
|
|
|
|
continue;
|
|
|
|
}
|
2012-03-30 17:30:56 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* If target fully scanned already, then all remaining source vertices cannot have a double */
|
|
|
|
if (target_scan_completed) {
|
|
|
|
doubles_map[sve_source->vertex_num] = -1;
|
|
|
|
continue;
|
2012-11-19 14:58:31 +00:00
|
|
|
}
|
2014-08-12 13:52:17 +10:00
|
|
|
|
|
|
|
sve_source_sumco = sum_v3(sve_source->co);
|
|
|
|
|
|
|
|
/* Skip all target vertices that are more than dist3 lower in terms of sumco */
|
|
|
|
/* and advance the overall lower bound, applicable to all remaining vertices as well. */
|
|
|
|
while ((i_target_low_bound < target_num_verts) &&
|
|
|
|
(sve_target_low_bound->sum_co < sve_source_sumco - dist3))
|
|
|
|
{
|
|
|
|
i_target_low_bound++;
|
|
|
|
sve_target_low_bound++;
|
2012-11-19 14:58:31 +00:00
|
|
|
}
|
2014-08-12 13:52:17 +10:00
|
|
|
/* If end of target list reached, then no more possible doubles */
|
|
|
|
if (i_target_low_bound >= target_num_verts) {
|
|
|
|
doubles_map[sve_source->vertex_num] = -1;
|
|
|
|
target_scan_completed = true;
|
|
|
|
continue;
|
2012-11-19 14:58:31 +00:00
|
|
|
}
|
2014-08-12 13:52:17 +10:00
|
|
|
/* Test target candidates starting at the low bound of possible doubles, ordered in terms of sumco */
|
|
|
|
i_target = i_target_low_bound;
|
|
|
|
sve_target = sve_target_low_bound;
|
|
|
|
|
|
|
|
/* i_target will scan vertices in the [v_source_sumco - dist3; v_source_sumco + dist3] range */
|
|
|
|
|
|
|
|
while ((i_target < target_num_verts) &&
|
|
|
|
(sve_target->sum_co <= sve_source_sumco + dist3))
|
|
|
|
{
|
|
|
|
/* Testing distance for candidate double in target */
|
|
|
|
/* v_target is within dist3 of v_source in terms of sumco; check real distance */
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
float dist_sq;
|
|
|
|
if ((dist_sq = len_squared_v3v3(sve_source->co, sve_target->co)) <= best_dist_sq) {
|
|
|
|
/* Potential double found */
|
|
|
|
best_dist_sq = dist_sq;
|
|
|
|
best_target_vertex = sve_target->vertex_num;
|
|
|
|
|
|
|
|
/* If target is already mapped, we only follow that mapping if final target remains
|
|
|
|
* close enough from current vert (otherwise no mapping at all).
|
|
|
|
* Note that if we later find another target closer than this one, then we check it. But if other
|
|
|
|
* potential targets are farther, then there will be no mapping at all for this source. */
|
|
|
|
while (best_target_vertex != -1 && !ELEM(doubles_map[best_target_vertex], -1, best_target_vertex)) {
|
|
|
|
if (compare_len_v3v3(mverts[sve_source->vertex_num].co,
|
|
|
|
mverts[doubles_map[best_target_vertex]].co,
|
|
|
|
dist))
|
|
|
|
{
|
|
|
|
best_target_vertex = doubles_map[best_target_vertex];
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
|
|
|
else {
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
best_target_vertex = -1;
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
|
|
|
}
|
2012-03-30 17:30:56 +00:00
|
|
|
}
|
2014-08-12 13:52:17 +10:00
|
|
|
i_target++;
|
|
|
|
sve_target++;
|
|
|
|
}
|
|
|
|
/* End of candidate scan: if none found then no doubles */
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
doubles_map[sve_source->vertex_num] = best_target_vertex;
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
2012-03-30 17:30:56 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
MEM_freeN(sorted_verts_source);
|
|
|
|
MEM_freeN(sorted_verts_target);
|
|
|
|
}
|
2012-03-30 17:30:56 +00:00
|
|
|
|
2012-11-20 13:29:27 +00:00
|
|
|
|
2018-04-25 16:47:52 +02:00
|
|
|
static void mesh_merge_transform(
|
|
|
|
Mesh *result, Mesh *cap_mesh, float cap_offset[4][4],
|
2014-08-12 13:52:17 +10:00
|
|
|
unsigned int cap_verts_index, unsigned int cap_edges_index, int cap_loops_index, int cap_polys_index,
|
2018-03-06 09:57:41 +11:00
|
|
|
int cap_nverts, int cap_nedges, int cap_nloops, int cap_npolys, int *remap, int remap_len)
|
2014-08-12 13:52:17 +10:00
|
|
|
{
|
|
|
|
int *index_orig;
|
|
|
|
int i;
|
|
|
|
MVert *mv;
|
|
|
|
MEdge *me;
|
|
|
|
MLoop *ml;
|
|
|
|
MPoly *mp;
|
|
|
|
|
2018-04-25 16:47:52 +02:00
|
|
|
CustomData_copy_data(&cap_mesh->vdata, &result->vdata, 0, cap_verts_index, cap_nverts);
|
|
|
|
CustomData_copy_data(&cap_mesh->edata, &result->edata, 0, cap_edges_index, cap_nedges);
|
|
|
|
CustomData_copy_data(&cap_mesh->ldata, &result->ldata, 0, cap_loops_index, cap_nloops);
|
|
|
|
CustomData_copy_data(&cap_mesh->pdata, &result->pdata, 0, cap_polys_index, cap_npolys);
|
2014-08-12 13:52:17 +10:00
|
|
|
|
2018-04-25 16:47:52 +02:00
|
|
|
mv = result->mvert + cap_verts_index;
|
2014-08-12 13:52:17 +10:00
|
|
|
|
|
|
|
for (i = 0; i < cap_nverts; i++, mv++) {
|
|
|
|
mul_m4_v3(cap_offset, mv->co);
|
|
|
|
/* Reset MVert flags for caps */
|
|
|
|
mv->flag = mv->bweight = 0;
|
|
|
|
}
|
2012-03-30 17:30:56 +00:00
|
|
|
|
2018-03-06 09:57:41 +11:00
|
|
|
/* remap the vertex groups if necessary */
|
2018-12-14 14:44:20 +01:00
|
|
|
if (result->dvert != NULL) {
|
|
|
|
BKE_object_defgroup_index_map_apply(&result->dvert[cap_verts_index], cap_nverts, remap, remap_len);
|
2018-03-06 09:57:41 +11:00
|
|
|
}
|
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* adjust cap edge vertex indices */
|
2018-04-25 16:47:52 +02:00
|
|
|
me = result->medge + cap_edges_index;
|
2014-08-12 13:52:17 +10:00
|
|
|
for (i = 0; i < cap_nedges; i++, me++) {
|
|
|
|
me->v1 += cap_verts_index;
|
|
|
|
me->v2 += cap_verts_index;
|
2012-03-30 17:30:56 +00:00
|
|
|
}
|
2014-08-12 13:52:17 +10:00
|
|
|
|
|
|
|
/* adjust cap poly loopstart indices */
|
2018-04-25 16:47:52 +02:00
|
|
|
mp = result->mpoly + cap_polys_index;
|
2014-08-12 13:52:17 +10:00
|
|
|
for (i = 0; i < cap_npolys; i++, mp++) {
|
|
|
|
mp->loopstart += cap_loops_index;
|
2012-03-30 17:30:56 +00:00
|
|
|
}
|
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* adjust cap loop vertex and edge indices */
|
2018-04-25 16:47:52 +02:00
|
|
|
ml = result->mloop + cap_loops_index;
|
2014-08-12 13:52:17 +10:00
|
|
|
for (i = 0; i < cap_nloops; i++, ml++) {
|
|
|
|
ml->v += cap_verts_index;
|
|
|
|
ml->e += cap_edges_index;
|
2012-03-30 17:30:56 +00:00
|
|
|
}
|
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* set origindex */
|
2018-04-25 16:47:52 +02:00
|
|
|
index_orig = CustomData_get_layer(&result->vdata, CD_ORIGINDEX);
|
2014-08-12 13:52:17 +10:00
|
|
|
if (index_orig) {
|
2015-05-05 17:08:29 +10:00
|
|
|
copy_vn_i(index_orig + cap_verts_index, cap_nverts, ORIGINDEX_NONE);
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
|
|
|
|
2018-04-25 16:47:52 +02:00
|
|
|
index_orig = CustomData_get_layer(&result->edata, CD_ORIGINDEX);
|
2014-08-12 13:52:17 +10:00
|
|
|
if (index_orig) {
|
2015-05-05 17:08:29 +10:00
|
|
|
copy_vn_i(index_orig + cap_edges_index, cap_nedges, ORIGINDEX_NONE);
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
|
|
|
|
2018-04-25 16:47:52 +02:00
|
|
|
index_orig = CustomData_get_layer(&result->pdata, CD_ORIGINDEX);
|
2014-08-12 13:52:17 +10:00
|
|
|
if (index_orig) {
|
2015-05-05 17:08:29 +10:00
|
|
|
copy_vn_i(index_orig + cap_polys_index, cap_npolys, ORIGINDEX_NONE);
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
|
|
|
|
2018-04-25 16:47:52 +02:00
|
|
|
index_orig = CustomData_get_layer(&result->ldata, CD_ORIGINDEX);
|
2014-08-12 13:52:17 +10:00
|
|
|
if (index_orig) {
|
2015-05-05 17:08:29 +10:00
|
|
|
copy_vn_i(index_orig + cap_loops_index, cap_nloops, ORIGINDEX_NONE);
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
2012-03-30 17:30:56 +00:00
|
|
|
}
|
2012-03-28 22:03:46 +00:00
|
|
|
|
2018-04-25 16:47:52 +02:00
|
|
|
static Mesh *arrayModifier_doArray(
|
2018-05-01 17:33:04 +02:00
|
|
|
ArrayModifierData *amd, const ModifierEvalContext *ctx, Mesh *mesh)
|
2010-04-11 22:12:30 +00:00
|
|
|
{
|
2014-08-12 13:52:17 +10:00
|
|
|
const float eps = 1e-6f;
|
|
|
|
const MVert *src_mvert;
|
|
|
|
MVert *mv, *mv_prev, *result_dm_verts;
|
|
|
|
|
|
|
|
MEdge *me;
|
|
|
|
MLoop *ml;
|
|
|
|
MPoly *mp;
|
|
|
|
int i, j, c, count;
|
|
|
|
float length = amd->length;
|
2010-04-11 22:12:30 +00:00
|
|
|
/* offset matrix */
|
|
|
|
float offset[4][4];
|
2014-08-12 13:52:17 +10:00
|
|
|
float scale[3];
|
|
|
|
bool offset_has_scale;
|
|
|
|
float current_offset[4][4];
|
2012-02-13 08:06:44 +00:00
|
|
|
float final_offset[4][4];
|
2014-08-12 13:52:17 +10:00
|
|
|
int *full_doubles_map = NULL;
|
|
|
|
int tot_doubles;
|
|
|
|
|
2015-01-07 11:41:45 +11:00
|
|
|
const bool use_merge = (amd->flags & MOD_ARR_MERGE) != 0;
|
2018-05-04 10:05:57 +02:00
|
|
|
const bool use_recalc_normals = (mesh->runtime.cd_dirty_vert & CD_MASK_NORMAL) || use_merge;
|
2018-12-07 15:45:53 +01:00
|
|
|
const bool use_offset_ob = ((amd->offset_type & MOD_ARR_OFF_OBJ) && amd->offset_ob != NULL);
|
2014-09-21 10:12:26 +02:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
int start_cap_nverts = 0, start_cap_nedges = 0, start_cap_npolys = 0, start_cap_nloops = 0;
|
|
|
|
int end_cap_nverts = 0, end_cap_nedges = 0, end_cap_npolys = 0, end_cap_nloops = 0;
|
|
|
|
int result_nverts = 0, result_nedges = 0, result_npolys = 0, result_nloops = 0;
|
|
|
|
int chunk_nverts, chunk_nedges, chunk_nloops, chunk_npolys;
|
|
|
|
int first_chunk_start, first_chunk_nverts, last_chunk_start, last_chunk_nverts;
|
|
|
|
|
2018-04-25 16:47:52 +02:00
|
|
|
Mesh *result, *start_cap_mesh = NULL, *end_cap_mesh = NULL;
|
2014-08-12 13:52:17 +10:00
|
|
|
|
2018-03-06 09:57:41 +11:00
|
|
|
int *vgroup_start_cap_remap = NULL;
|
|
|
|
int vgroup_start_cap_remap_len = 0;
|
|
|
|
int *vgroup_end_cap_remap = NULL;
|
|
|
|
int vgroup_end_cap_remap_len = 0;
|
|
|
|
|
2018-04-25 16:47:52 +02:00
|
|
|
chunk_nverts = mesh->totvert;
|
|
|
|
chunk_nedges = mesh->totedge;
|
|
|
|
chunk_nloops = mesh->totloop;
|
|
|
|
chunk_npolys = mesh->totpoly;
|
2014-08-12 13:52:17 +10:00
|
|
|
|
|
|
|
count = amd->count;
|
|
|
|
|
2018-12-07 15:45:53 +01:00
|
|
|
Object *start_cap_ob = DEG_get_evaluated_object(ctx->depsgraph, amd->start_cap);
|
|
|
|
if (start_cap_ob && start_cap_ob != ctx->object && start_cap_ob->type == OB_MESH) {
|
2018-05-01 17:33:04 +02:00
|
|
|
vgroup_start_cap_remap = BKE_object_defgroup_index_map_create(
|
2018-12-07 15:45:53 +01:00
|
|
|
start_cap_ob, ctx->object, &vgroup_start_cap_remap_len);
|
2018-03-06 09:57:41 +11:00
|
|
|
|
2019-02-11 20:20:12 +01:00
|
|
|
start_cap_mesh = BKE_modifier_get_evaluated_mesh_from_evaluated_object(start_cap_ob, false);
|
2018-04-25 16:47:52 +02:00
|
|
|
if (start_cap_mesh) {
|
|
|
|
start_cap_nverts = start_cap_mesh->totvert;
|
|
|
|
start_cap_nedges = start_cap_mesh->totedge;
|
|
|
|
start_cap_nloops = start_cap_mesh->totloop;
|
|
|
|
start_cap_npolys = start_cap_mesh->totpoly;
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
|
|
|
}
|
2018-12-07 15:45:53 +01:00
|
|
|
Object *end_cap_ob = DEG_get_evaluated_object(ctx->depsgraph, amd->end_cap);
|
|
|
|
if (end_cap_ob && end_cap_ob != ctx->object && end_cap_ob->type == OB_MESH) {
|
2018-05-01 17:33:04 +02:00
|
|
|
vgroup_end_cap_remap = BKE_object_defgroup_index_map_create(
|
2018-12-07 15:45:53 +01:00
|
|
|
end_cap_ob, ctx->object, &vgroup_end_cap_remap_len);
|
2018-03-06 09:57:41 +11:00
|
|
|
|
2019-02-11 20:20:12 +01:00
|
|
|
end_cap_mesh = BKE_modifier_get_evaluated_mesh_from_evaluated_object(end_cap_ob, false);
|
2018-04-25 16:47:52 +02:00
|
|
|
if (end_cap_mesh) {
|
|
|
|
end_cap_nverts = end_cap_mesh->totvert;
|
|
|
|
end_cap_nedges = end_cap_mesh->totedge;
|
|
|
|
end_cap_nloops = end_cap_mesh->totloop;
|
|
|
|
end_cap_npolys = end_cap_mesh->totpoly;
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
|
|
|
}
|
2010-04-11 22:12:30 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* Build up offset array, cumulating all settings options */
|
2010-04-11 22:12:30 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
unit_m4(offset);
|
2018-04-25 16:47:52 +02:00
|
|
|
src_mvert = mesh->mvert;
|
2010-04-11 22:12:30 +00:00
|
|
|
|
2017-06-08 09:17:08 +02:00
|
|
|
if (amd->offset_type & MOD_ARR_OFF_CONST) {
|
|
|
|
add_v3_v3(offset[3], amd->offset);
|
|
|
|
}
|
2014-08-12 13:52:17 +10:00
|
|
|
|
2012-03-24 06:24:53 +00:00
|
|
|
if (amd->offset_type & MOD_ARR_OFF_RELATIVE) {
|
2017-06-08 09:17:08 +02:00
|
|
|
float min[3], max[3];
|
|
|
|
const MVert *src_mv;
|
|
|
|
|
|
|
|
INIT_MINMAX(min, max);
|
|
|
|
for (src_mv = src_mvert, j = chunk_nverts; j--; src_mv++) {
|
|
|
|
minmax_v3v3_v3(min, max, src_mv->co);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (j = 3; j--; ) {
|
|
|
|
offset[3][j] += amd->scale[j] * (max[j] - min[j]);
|
|
|
|
}
|
2010-04-11 22:12:30 +00:00
|
|
|
}
|
|
|
|
|
2014-10-03 14:33:50 +02:00
|
|
|
if (use_offset_ob) {
|
2010-04-11 22:12:30 +00:00
|
|
|
float obinv[4][4];
|
|
|
|
float result_mat[4][4];
|
|
|
|
|
2018-05-01 17:33:04 +02:00
|
|
|
if (ctx->object)
|
|
|
|
invert_m4_m4(obinv, ctx->object->obmat);
|
2010-04-11 22:12:30 +00:00
|
|
|
else
|
|
|
|
unit_m4(obinv);
|
|
|
|
|
2018-12-07 15:45:53 +01:00
|
|
|
mul_m4_series(result_mat, offset, obinv, DEG_get_evaluated_object(ctx->depsgraph, amd->offset_ob)->obmat);
|
2010-04-11 22:12:30 +00:00
|
|
|
copy_m4_m4(offset, result_mat);
|
|
|
|
}
|
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* Check if there is some scaling. If scaling, then we will not translate mapping */
|
|
|
|
mat4_to_size(scale, offset);
|
|
|
|
offset_has_scale = !is_one_v3(scale);
|
|
|
|
|
2018-12-07 15:45:53 +01:00
|
|
|
if (amd->fit_type == MOD_ARR_FITCURVE && amd->curve_ob != NULL) {
|
|
|
|
Object *curve_ob = DEG_get_evaluated_object(ctx->depsgraph, amd->curve_ob);
|
|
|
|
Curve *cu = curve_ob->data;
|
2012-03-24 06:24:53 +00:00
|
|
|
if (cu) {
|
2018-12-07 15:45:53 +01:00
|
|
|
CurveCache *curve_cache = curve_ob->runtime.curve_cache;
|
2018-07-30 16:54:40 +02:00
|
|
|
if (curve_cache != NULL && curve_cache->path != NULL) {
|
2018-12-07 15:45:53 +01:00
|
|
|
float scale_fac = mat4_to_scale(curve_ob->obmat);
|
2018-07-30 16:54:40 +02:00
|
|
|
length = scale_fac * curve_cache->path->totdist;
|
2013-11-18 14:02:49 +13:00
|
|
|
}
|
2010-04-11 22:12:30 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* calculate the maximum number of copies which will fit within the
|
2012-03-09 18:28:30 +00:00
|
|
|
* prescribed length */
|
2012-04-21 15:11:03 +00:00
|
|
|
if (amd->fit_type == MOD_ARR_FITLENGTH || amd->fit_type == MOD_ARR_FITCURVE) {
|
2013-09-03 22:32:03 +00:00
|
|
|
float dist = len_v3(offset[3]);
|
2010-04-11 22:12:30 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
if (dist > eps) {
|
2010-04-11 22:12:30 +00:00
|
|
|
/* this gives length = first copy start to last copy end
|
2012-03-09 18:28:30 +00:00
|
|
|
* add a tiny offset for floating point rounding errors */
|
2015-04-13 10:51:04 +02:00
|
|
|
count = (length + eps) / dist + 1;
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
|
|
|
else {
|
2010-04-11 22:12:30 +00:00
|
|
|
/* if the offset has no translation, just make one copy */
|
|
|
|
count = 1;
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
2010-07-19 04:44:37 +00:00
|
|
|
}
|
2010-04-11 22:12:30 +00:00
|
|
|
|
2012-03-24 06:24:53 +00:00
|
|
|
if (count < 1)
|
2010-07-19 04:44:37 +00:00
|
|
|
count = 1;
|
2010-04-11 22:12:30 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* The number of verts, edges, loops, polys, before eventually merging doubles */
|
|
|
|
result_nverts = chunk_nverts * count + start_cap_nverts + end_cap_nverts;
|
|
|
|
result_nedges = chunk_nedges * count + start_cap_nedges + end_cap_nedges;
|
|
|
|
result_nloops = chunk_nloops * count + start_cap_nloops + end_cap_nloops;
|
|
|
|
result_npolys = chunk_npolys * count + start_cap_npolys + end_cap_npolys;
|
|
|
|
|
|
|
|
/* Initialize a result dm */
|
2018-05-08 17:06:30 +02:00
|
|
|
result = BKE_mesh_new_nomain_from_template(mesh, result_nverts, result_nedges, 0, result_nloops, result_npolys);
|
2018-04-25 16:47:52 +02:00
|
|
|
result_dm_verts = result->mvert;
|
2012-03-26 19:50:45 +00:00
|
|
|
|
2014-09-21 10:12:26 +02:00
|
|
|
if (use_merge) {
|
2014-08-12 13:52:17 +10:00
|
|
|
/* Will need full_doubles_map for handling merge */
|
2018-01-14 22:14:20 +01:00
|
|
|
full_doubles_map = MEM_malloc_arrayN(result_nverts, sizeof(int), "mod array doubles map");
|
2015-05-05 17:08:29 +10:00
|
|
|
copy_vn_i(full_doubles_map, result_nverts, -1);
|
2012-03-26 19:50:45 +00:00
|
|
|
}
|
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* copy customdata to original geometry */
|
2018-04-25 16:47:52 +02:00
|
|
|
CustomData_copy_data(&mesh->vdata, &result->vdata, 0, 0, chunk_nverts);
|
|
|
|
CustomData_copy_data(&mesh->edata, &result->edata, 0, 0, chunk_nedges);
|
|
|
|
CustomData_copy_data(&mesh->ldata, &result->ldata, 0, 0, chunk_nloops);
|
|
|
|
CustomData_copy_data(&mesh->pdata, &result->pdata, 0, 0, chunk_npolys);
|
2011-10-27 17:39:15 +00:00
|
|
|
|
2018-09-03 16:49:08 +02:00
|
|
|
/* Subsurf for eg won't have mesh data in the custom data arrays.
|
2018-04-25 12:25:47 +02:00
|
|
|
* now add mvert/medge/mpoly layers. */
|
2018-04-25 16:47:52 +02:00
|
|
|
if (!CustomData_has_layer(&mesh->vdata, CD_MVERT)) {
|
|
|
|
memcpy(result->mvert, mesh->mvert, sizeof(*result->mvert) * mesh->totvert);
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
2018-04-25 16:47:52 +02:00
|
|
|
if (!CustomData_has_layer(&mesh->edata, CD_MEDGE)) {
|
|
|
|
memcpy(result->medge, mesh->medge, sizeof(*result->medge) * mesh->totedge);
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
2018-04-25 16:47:52 +02:00
|
|
|
if (!CustomData_has_layer(&mesh->pdata, CD_MPOLY)) {
|
|
|
|
memcpy(result->mloop, mesh->mloop, sizeof(*result->mloop) * mesh->totloop);
|
|
|
|
memcpy(result->mpoly, mesh->mpoly, sizeof(*result->mpoly) * mesh->totpoly);
|
2012-11-20 13:29:27 +00:00
|
|
|
}
|
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* Remember first chunk, in case of cap merge */
|
|
|
|
first_chunk_start = 0;
|
|
|
|
first_chunk_nverts = chunk_nverts;
|
2010-07-19 04:44:37 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
unit_m4(current_offset);
|
|
|
|
for (c = 1; c < count; c++) {
|
|
|
|
/* copy customdata to new geometry */
|
2018-04-25 16:47:52 +02:00
|
|
|
CustomData_copy_data(&mesh->vdata, &result->vdata, 0, c * chunk_nverts, chunk_nverts);
|
|
|
|
CustomData_copy_data(&mesh->edata, &result->edata, 0, c * chunk_nedges, chunk_nedges);
|
|
|
|
CustomData_copy_data(&mesh->ldata, &result->ldata, 0, c * chunk_nloops, chunk_nloops);
|
|
|
|
CustomData_copy_data(&mesh->pdata, &result->pdata, 0, c * chunk_npolys, chunk_npolys);
|
2010-07-19 04:44:37 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
mv_prev = result_dm_verts;
|
|
|
|
mv = mv_prev + c * chunk_nverts;
|
2010-07-19 04:44:37 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* recalculate cumulative offset here */
|
|
|
|
mul_m4_m4m4(current_offset, current_offset, offset);
|
2010-07-19 04:44:37 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* apply offset to all new verts */
|
|
|
|
for (i = 0; i < chunk_nverts; i++, mv++, mv_prev++) {
|
|
|
|
mul_m4_v3(current_offset, mv->co);
|
2014-09-21 10:12:26 +02:00
|
|
|
|
|
|
|
/* We have to correct normals too, if we do not tag them as dirty! */
|
|
|
|
if (!use_recalc_normals) {
|
|
|
|
float no[3];
|
|
|
|
normal_short_to_float_v3(no, mv->no);
|
|
|
|
mul_mat3_m4_v3(current_offset, no);
|
|
|
|
normalize_v3(no);
|
|
|
|
normal_float_to_short_v3(mv->no, no);
|
|
|
|
}
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
2010-07-19 04:44:37 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* adjust edge vertex indices */
|
2018-04-25 16:47:52 +02:00
|
|
|
me = result->medge + c * chunk_nedges;
|
2014-08-12 13:52:17 +10:00
|
|
|
for (i = 0; i < chunk_nedges; i++, me++) {
|
|
|
|
me->v1 += c * chunk_nverts;
|
|
|
|
me->v2 += c * chunk_nverts;
|
|
|
|
}
|
2012-10-29 15:43:54 +00:00
|
|
|
|
2018-04-25 16:47:52 +02:00
|
|
|
mp = result->mpoly + c * chunk_npolys;
|
2014-08-12 13:52:17 +10:00
|
|
|
for (i = 0; i < chunk_npolys; i++, mp++) {
|
|
|
|
mp->loopstart += c * chunk_nloops;
|
|
|
|
}
|
2010-07-19 04:44:37 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* adjust loop vertex and edge indices */
|
2018-04-25 16:47:52 +02:00
|
|
|
ml = result->mloop + c * chunk_nloops;
|
2014-08-12 13:52:17 +10:00
|
|
|
for (i = 0; i < chunk_nloops; i++, ml++) {
|
|
|
|
ml->v += c * chunk_nverts;
|
|
|
|
ml->e += c * chunk_nedges;
|
|
|
|
}
|
2010-07-19 04:44:37 +00:00
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* Handle merge between chunk n and n-1 */
|
2014-09-21 10:12:26 +02:00
|
|
|
if (use_merge && (c >= 1)) {
|
2014-08-12 13:52:17 +10:00
|
|
|
if (!offset_has_scale && (c >= 2)) {
|
|
|
|
/* Mapping chunk 3 to chunk 2 is a translation of mapping 2 to 1
|
|
|
|
* ... that is except if scaling makes the distance grow */
|
|
|
|
int k;
|
|
|
|
int this_chunk_index = c * chunk_nverts;
|
|
|
|
int prev_chunk_index = (c - 1) * chunk_nverts;
|
|
|
|
for (k = 0; k < chunk_nverts; k++, this_chunk_index++, prev_chunk_index++) {
|
|
|
|
int target = full_doubles_map[prev_chunk_index];
|
|
|
|
if (target != -1) {
|
|
|
|
target += chunk_nverts; /* translate mapping */
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
while (target != -1 && !ELEM(full_doubles_map[target], -1, target)) {
|
|
|
|
/* If target is already mapped, we only follow that mapping if final target remains
|
|
|
|
* close enough from current vert (otherwise no mapping at all). */
|
|
|
|
if (compare_len_v3v3(result_dm_verts[this_chunk_index].co,
|
|
|
|
result_dm_verts[full_doubles_map[target]].co,
|
|
|
|
amd->merge_dist))
|
|
|
|
{
|
2014-10-05 23:10:44 +02:00
|
|
|
target = full_doubles_map[target];
|
|
|
|
}
|
|
|
|
else {
|
2014-10-03 14:33:50 +02:00
|
|
|
target = -1;
|
|
|
|
}
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
|
|
|
}
|
|
|
|
full_doubles_map[this_chunk_index] = target;
|
2012-04-21 12:51:47 +00:00
|
|
|
}
|
2012-03-29 11:31:44 +00:00
|
|
|
}
|
2014-08-12 13:52:17 +10:00
|
|
|
else {
|
|
|
|
dm_mvert_map_doubles(
|
|
|
|
full_doubles_map,
|
|
|
|
result_dm_verts,
|
|
|
|
(c - 1) * chunk_nverts,
|
|
|
|
chunk_nverts,
|
|
|
|
c * chunk_nverts,
|
|
|
|
chunk_nverts,
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
amd->merge_dist);
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
2012-03-29 11:31:44 +00:00
|
|
|
}
|
2010-07-19 04:44:37 +00:00
|
|
|
}
|
|
|
|
|
2017-12-07 04:33:52 +11:00
|
|
|
/* handle UVs */
|
|
|
|
if (chunk_nloops > 0 && is_zero_v2(amd->uv_offset) == false) {
|
2018-04-25 16:47:52 +02:00
|
|
|
const int totuv = CustomData_number_of_layers(&result->ldata, CD_MLOOPUV);
|
2017-12-07 04:33:52 +11:00
|
|
|
for (i = 0; i < totuv; i++) {
|
2018-04-25 16:47:52 +02:00
|
|
|
MLoopUV *dmloopuv = CustomData_get_layer_n(&result->ldata, CD_MLOOPUV, i);
|
2017-12-07 04:33:52 +11:00
|
|
|
dmloopuv += chunk_nloops;
|
|
|
|
for (c = 1; c < count; c++) {
|
|
|
|
const float uv_offset[2] = {
|
|
|
|
amd->uv_offset[0] * (float)c,
|
|
|
|
amd->uv_offset[1] * (float)c,
|
|
|
|
};
|
|
|
|
int l_index = chunk_nloops;
|
|
|
|
for (; l_index-- != 0; dmloopuv++) {
|
|
|
|
dmloopuv->uv[0] += uv_offset[0];
|
|
|
|
dmloopuv->uv[1] += uv_offset[1];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
last_chunk_start = (count - 1) * chunk_nverts;
|
|
|
|
last_chunk_nverts = chunk_nverts;
|
|
|
|
|
|
|
|
copy_m4_m4(final_offset, current_offset);
|
|
|
|
|
2014-09-21 10:12:26 +02:00
|
|
|
if (use_merge && (amd->flags & MOD_ARR_MERGEFINAL) && (count > 1)) {
|
2014-08-12 13:52:17 +10:00
|
|
|
/* Merge first and last copies */
|
|
|
|
dm_mvert_map_doubles(
|
|
|
|
full_doubles_map,
|
|
|
|
result_dm_verts,
|
|
|
|
last_chunk_start,
|
|
|
|
last_chunk_nverts,
|
|
|
|
first_chunk_start,
|
|
|
|
first_chunk_nverts,
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
amd->merge_dist);
|
2012-03-30 17:30:56 +00:00
|
|
|
}
|
2012-02-13 08:06:44 +00:00
|
|
|
|
|
|
|
/* start capping */
|
2018-04-25 16:47:52 +02:00
|
|
|
if (start_cap_mesh) {
|
2014-08-12 13:52:17 +10:00
|
|
|
float start_offset[4][4];
|
|
|
|
int start_cap_start = result_nverts - start_cap_nverts - end_cap_nverts;
|
|
|
|
invert_m4_m4(start_offset, offset);
|
2018-04-25 16:47:52 +02:00
|
|
|
mesh_merge_transform(
|
|
|
|
result, start_cap_mesh, start_offset,
|
2014-08-12 13:52:17 +10:00
|
|
|
result_nverts - start_cap_nverts - end_cap_nverts,
|
|
|
|
result_nedges - start_cap_nedges - end_cap_nedges,
|
|
|
|
result_nloops - start_cap_nloops - end_cap_nloops,
|
|
|
|
result_npolys - start_cap_npolys - end_cap_npolys,
|
2018-03-06 09:57:41 +11:00
|
|
|
start_cap_nverts, start_cap_nedges, start_cap_nloops, start_cap_npolys,
|
|
|
|
vgroup_start_cap_remap, vgroup_start_cap_remap_len);
|
2014-08-12 13:52:17 +10:00
|
|
|
/* Identify doubles with first chunk */
|
2014-09-21 10:12:26 +02:00
|
|
|
if (use_merge) {
|
2014-08-12 13:52:17 +10:00
|
|
|
dm_mvert_map_doubles(
|
|
|
|
full_doubles_map,
|
|
|
|
result_dm_verts,
|
|
|
|
first_chunk_start,
|
|
|
|
first_chunk_nverts,
|
|
|
|
start_cap_start,
|
|
|
|
start_cap_nverts,
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
amd->merge_dist);
|
2012-02-13 08:06:44 +00:00
|
|
|
}
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
2012-02-13 08:06:44 +00:00
|
|
|
|
2018-04-25 16:47:52 +02:00
|
|
|
if (end_cap_mesh) {
|
2014-08-12 13:52:17 +10:00
|
|
|
float end_offset[4][4];
|
|
|
|
int end_cap_start = result_nverts - end_cap_nverts;
|
|
|
|
mul_m4_m4m4(end_offset, current_offset, offset);
|
2018-04-25 16:47:52 +02:00
|
|
|
mesh_merge_transform(
|
|
|
|
result, end_cap_mesh, end_offset,
|
2014-08-12 13:52:17 +10:00
|
|
|
result_nverts - end_cap_nverts,
|
|
|
|
result_nedges - end_cap_nedges,
|
|
|
|
result_nloops - end_cap_nloops,
|
|
|
|
result_npolys - end_cap_npolys,
|
2018-03-06 09:57:41 +11:00
|
|
|
end_cap_nverts, end_cap_nedges, end_cap_nloops, end_cap_npolys,
|
|
|
|
vgroup_end_cap_remap, vgroup_end_cap_remap_len);
|
2014-08-12 13:52:17 +10:00
|
|
|
/* Identify doubles with last chunk */
|
2014-09-21 10:12:26 +02:00
|
|
|
if (use_merge) {
|
2014-08-12 13:52:17 +10:00
|
|
|
dm_mvert_map_doubles(
|
|
|
|
full_doubles_map,
|
|
|
|
result_dm_verts,
|
|
|
|
last_chunk_start,
|
|
|
|
last_chunk_nverts,
|
|
|
|
end_cap_start,
|
|
|
|
end_cap_nverts,
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
amd->merge_dist);
|
2012-02-13 08:06:44 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
/* done capping */
|
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
/* Handle merging */
|
|
|
|
tot_doubles = 0;
|
2014-09-21 10:12:26 +02:00
|
|
|
if (use_merge) {
|
2014-08-12 13:52:17 +10:00
|
|
|
for (i = 0; i < result_nverts; i++) {
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
int new_i = full_doubles_map[i];
|
|
|
|
if (new_i != -1) {
|
|
|
|
/* We have to follow chains of doubles (merge start/end especially is likely to create some),
|
2018-10-15 18:11:37 +11:00
|
|
|
* those are not supported at all by BKE_mesh_merge_verts! */
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
while (!ELEM(full_doubles_map[new_i], -1, new_i)) {
|
|
|
|
new_i = full_doubles_map[new_i];
|
|
|
|
}
|
|
|
|
if (i == new_i) {
|
2014-10-03 14:33:50 +02:00
|
|
|
full_doubles_map[i] = -1;
|
|
|
|
}
|
|
|
|
else {
|
Fix T46455: Array modifier could generate chained mapping of vertices, leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
2016-01-30 17:17:05 +01:00
|
|
|
full_doubles_map[i] = new_i;
|
2014-10-03 14:33:50 +02:00
|
|
|
tot_doubles++;
|
|
|
|
}
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (tot_doubles > 0) {
|
2018-04-25 16:47:52 +02:00
|
|
|
result = BKE_mesh_merge_verts(result, full_doubles_map, tot_doubles, MESH_MERGE_VERTS_DUMP_IF_EQUAL);
|
2014-08-12 13:52:17 +10:00
|
|
|
}
|
|
|
|
MEM_freeN(full_doubles_map);
|
2012-03-27 13:08:40 +00:00
|
|
|
}
|
2014-10-04 12:52:06 +02:00
|
|
|
|
2018-05-04 10:05:57 +02:00
|
|
|
/* In case org dm has dirty normals, or we made some merging, mark normals as dirty in new mesh!
|
|
|
|
* TODO: we may need to set other dirty flags as well?
|
|
|
|
*/
|
2014-10-04 12:52:06 +02:00
|
|
|
if (use_recalc_normals) {
|
2018-05-04 10:05:57 +02:00
|
|
|
result->runtime.cd_dirty_vert |= CD_MASK_NORMAL;
|
2014-10-04 12:52:06 +02:00
|
|
|
}
|
|
|
|
|
2018-03-06 09:57:41 +11:00
|
|
|
if (vgroup_start_cap_remap) {
|
|
|
|
MEM_freeN(vgroup_start_cap_remap);
|
|
|
|
}
|
|
|
|
if (vgroup_end_cap_remap) {
|
|
|
|
MEM_freeN(vgroup_end_cap_remap);
|
|
|
|
}
|
|
|
|
|
2012-02-12 15:02:33 +00:00
|
|
|
return result;
|
2010-04-11 22:12:30 +00:00
|
|
|
}
|
|
|
|
|
2014-08-12 13:52:17 +10:00
|
|
|
|
2018-05-12 08:21:07 +02:00
|
|
|
static Mesh *applyModifier(
|
|
|
|
ModifierData *md, const ModifierEvalContext *ctx,
|
|
|
|
Mesh *mesh)
|
2010-04-11 22:12:30 +00:00
|
|
|
{
|
2012-05-06 13:38:33 +00:00
|
|
|
ArrayModifierData *amd = (ArrayModifierData *) md;
|
2018-05-01 17:33:04 +02:00
|
|
|
return arrayModifier_doArray(amd, ctx, mesh);
|
2010-04-11 22:12:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
ModifierTypeInfo modifierType_Array = {
|
|
|
|
/* name */ "Array",
|
|
|
|
/* structName */ "ArrayModifierData",
|
|
|
|
/* structSize */ sizeof(ArrayModifierData),
|
|
|
|
/* type */ eModifierTypeType_Constructive,
|
2012-05-06 13:38:33 +00:00
|
|
|
/* flags */ eModifierTypeFlag_AcceptsMesh |
|
|
|
|
eModifierTypeFlag_SupportsMapping |
|
|
|
|
eModifierTypeFlag_SupportsEditmode |
|
|
|
|
eModifierTypeFlag_EnableInEditmode |
|
|
|
|
eModifierTypeFlag_AcceptsCVs,
|
2010-04-11 22:12:30 +00:00
|
|
|
|
2018-05-08 15:04:10 +02:00
|
|
|
/* copyData */ modifier_copyData_generic,
|
2018-04-18 15:45:54 +02:00
|
|
|
|
|
|
|
/* deformVerts_DM */ NULL,
|
|
|
|
/* deformMatrices_DM */ NULL,
|
|
|
|
/* deformVertsEM_DM */ NULL,
|
|
|
|
/* deformMatricesEM_DM*/NULL,
|
2018-04-25 16:47:52 +02:00
|
|
|
/* applyModifier_DM */ NULL,
|
2018-04-18 15:45:54 +02:00
|
|
|
|
2011-03-05 10:29:10 +00:00
|
|
|
/* deformVerts */ NULL,
|
|
|
|
/* deformMatrices */ NULL,
|
|
|
|
/* deformVertsEM */ NULL,
|
|
|
|
/* deformMatricesEM */ NULL,
|
2018-04-25 16:47:52 +02:00
|
|
|
/* applyModifier */ applyModifier,
|
2018-04-18 15:45:54 +02:00
|
|
|
|
2010-04-11 22:12:30 +00:00
|
|
|
/* initData */ initData,
|
2011-03-05 10:29:10 +00:00
|
|
|
/* requiredDataMask */ NULL,
|
|
|
|
/* freeData */ NULL,
|
|
|
|
/* isDisabled */ NULL,
|
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,
|
2011-03-05 10:29:10 +00:00
|
|
|
/* dependsOnTime */ NULL,
|
|
|
|
/* dependsOnNormals */ NULL,
|
2010-04-11 22:12:30 +00:00
|
|
|
/* foreachObjectLink */ foreachObjectLink,
|
2011-03-05 10:29:10 +00:00
|
|
|
/* foreachIDLink */ NULL,
|
2011-08-12 18:11:22 +00:00
|
|
|
/* foreachTexLink */ NULL,
|
2010-04-11 22:12:30 +00:00
|
|
|
};
|