Remove-Doubles (modifier) #41748

New Issue

Campbell Barton · 2014-09-08T03:59:39+02:00

Campbell Barton commented

2014-09-08 03:59:39 +02:00

Starting this design task because the possibility of a remove doubles modifier was suggested (in replies to D443).

The current design of the modifier stack creates an entire new mesh for each modifier, this means its not well suited to having small (fine-grained) editing operations as modifiers.

Which is why we don't already have many basic operations as modifiers.

So for this design task I like to gather some good use cases where a remove-doubles modifier would be used, to consider if its worth adding.

Findings...

Merging could use a boundary only option, since in many cases you want to zip up two boundaries (will be faster too).
Merging 2x solid edges (result of solidify modifier for example), will create internal faces, we could have an option to remove duplicate faces (which are likely to be internal).
... Further, merging overlapping faces isn't likely to give useful results (it can pick first face but not make a useful choice).

Starting this design task because the possibility of a remove doubles modifier was suggested (in replies to [D443](https://archive.blender.org/developer/D443)). The current design of the modifier stack creates an entire new mesh for each modifier, this means its not well suited to having small (fine-grained) editing operations as modifiers. Which is why we don't already have many basic operations as modifiers. So for this design task I like to gather some good use cases where a remove-doubles modifier would be used, to consider if its worth adding. Findings... ---- - Merging could use a **boundary only** option, since in many cases you want to *zip up* two boundaries (will be faster too). - Merging 2x solid edges (result of solidify modifier for example), will create internal faces, we *could* have an option to remove duplicate faces (which are likely to be internal). - ... Further, merging overlapping faces isn't likely to give useful results (it can pick first face but not make a useful choice).

Campbell Barton commented

2014-09-08 03:59:39 +02:00

Changed status to: 'Open'

Campbell Barton self-assigned this 2014-09-08 03:59:39 +02:00

Campbell Barton commented

2014-09-08 03:59:39 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2014-09-08 04:01:42 +02:00

Added subscribers: @karja, @PatriceBertrand

Campbell Barton changed title from ~~Remove doubles modifier~~ to Remove-Doubles (modifier)

2014-09-08 04:02:14 +02:00

ronan ducluzeau commented

2014-09-08 15:40:20 +02:00

Added subscriber: @zeauro

ronan ducluzeau commented

2014-09-08 15:40:20 +02:00

remove_doubles.blend
In this .blend, there is an animated grid with 2 shapekeys simulating a tearing of a transparent block.
On this grid, there is a solidify modifier and a bevel one.

Next to it, there is a non animated grid created by creation of a shapekey from mix at frame 60 and deletion of previous shapekey and basis.
For this mesh, I did a Remove Doubles in edit mode.

With a Remove Doubles modifier added before the others, animated grid could be rendered like non animated one.

[remove_doubles.blend](https://archive.blender.org/developer/F109493/remove_doubles.blend) In this .blend, there is an animated grid with 2 shapekeys simulating a tearing of a transparent block. On this grid, there is a solidify modifier and a bevel one. Next to it, there is a non animated grid created by creation of a shapekey from mix at frame 60 and deletion of previous shapekey and basis. For this mesh, I did a Remove Doubles in edit mode. With a Remove Doubles modifier added before the others, animated grid could be rendered like non animated one.

ronan ducluzeau commented

2014-09-08 16:54:08 +02:00

RD_simple_deform.blend
In this .blend, a simple deform modifier doing a bend is the starting point of modifier stack.
At the bottom, you see the result if we could add a Remove Doubles modifier just after it.

[RD_simple_deform.blend](https://archive.blender.org/developer/F109507/RD_simple_deform.blend) In this .blend, a simple deform modifier doing a bend is the starting point of modifier stack. At the bottom, you see the result if we could add a Remove Doubles modifier just after it.

ronan ducluzeau commented

2014-09-08 17:22:08 +02:00

RD_Sphere_Horn.blend
in this .blend, a simple sphere has a horn define by a curve modifier.
A shapekey was created to animate disappearing of the horn.
With a Remove Doubles modifier, result would be a perfectly smooth sphere

[RD_Sphere_Horn.blend](https://archive.blender.org/developer/F109511/RD_Sphere_Horn.blend) in this .blend, a simple sphere has a horn define by a curve modifier. A shapekey was created to animate disappearing of the horn. With a Remove Doubles modifier, result would be a perfectly smooth sphere

ronan ducluzeau commented

2014-09-08 22:33:01 +02:00

This comment was removed by @zeauro

*This comment was removed by @zeauro*

Patrice Bertrand commented

2014-09-08 22:41:21 +02:00

This comment was removed by @PatriceBertrand

*This comment was removed by @PatriceBertrand*

ronan ducluzeau commented

2014-09-08 22:56:58 +02:00

This comment was removed by @zeauro

*This comment was removed by @zeauro*

Campbell Barton commented

2014-09-09 12:49:27 +02:00

Just removed discussion about a bisect modifier, @zeauro - please stay on topic.

Karja Krähwald commented

2014-09-09 13:11:49 +02:00

Copied from D443, added a few comments. Hopefully it works just as i had imagined:

Have experimented with some ideas.
Main purpose i have found in operations where you want to

tear
pluck
peel
break
cut
(and so on)
geometry, and of course the other way around.

Benefits i see are especially for animation and deform on smooth meshes. With a "merge"-modifier you could assign overlapping edges to 2 or more different vertexgroups and move them with bones or curves asunder.
Rough example. The crack or whatever can be handled by Edge Split very good, but i dont know a good possibility to go any further.
My idea for a "merge"-modifier is to create two or more parts with overlapping verts and edges and hide the dividing line with the modifier.
Moving the parts beyond the merge limit splits the mesh.

Fracture could have an extra layer when combined with Edge Split.

A merge option for meshobject + meshobject (like target object) could handle more - Linked Duplicates with Mask would be responsible for more fragments, so you have only one mesh to work on.
Also comes in place where two sets of modifiers should not affect eachother (Solidify/Array always take whole mesh) and 2 objects are needed, but result object shall appear as connected.
A little like Array cap settings without modifier dependencies. I dont know if this is feasible.

The banana shows no cuts/is not peeled when not deformed, providing the merge is activ.
This can also be done with Array merge, but it dont allows to animate seperate banana peels, or to texture it as a whole.
In theory you could display every fruit outside and inside with a single mesh (after cutting it, suitable for animations).

Last one is Skin modifier (maybe not an ideal example). Skin should be generally not bad to use, because you can set higher merge limits and stick how you like.
Also its very organic - a bit like metaballs when combined with a "merge"-modifier + Subsurf. > same method as in @zeauro´s SphereHorn-File. You could collect connected vertices on one point and they merge to a single vertice with the modifier. Then move the vertices to different locations and you get a larger and still connected mesh. (for waterdrops, growing plants or something like that)
Only problem i see is the radius and root after merge operation.

Copied from [D443](https://archive.blender.org/developer/D443), added a few comments. Hopefully it works just as i had imagined: ---- Have experimented with some ideas. Main purpose i have found in operations where you want to - tear - pluck - peel - break - cut - (and so on) geometry, and of course the other way around. Benefits i see are especially for animation and deform on smooth meshes. With a "merge"-modifier you could assign overlapping edges to 2 or more different vertexgroups and move them with bones or curves asunder. ![TextileTear.png](https://archive.blender.org/developer/F109368/TextileTear.png) Rough example. The crack or whatever can be handled by Edge Split very good, but i dont know a good possibility to go any further. My idea for a "merge"-modifier is to create two or more parts with overlapping verts and edges and hide the dividing line with the modifier. Moving the parts beyond the merge limit splits the mesh. ---- ![EggMerge.png](https://archive.blender.org/developer/F109370/EggMerge.png) Fracture could have an extra layer when combined with Edge Split. A merge option for meshobject + meshobject (like target object) could handle more - Linked Duplicates with Mask would be responsible for more fragments, so you have only one mesh to work on. Also comes in place where two sets of modifiers should not affect eachother (Solidify/Array always take whole mesh) and 2 objects are needed, but result object shall appear as connected. A little like Array cap settings without modifier dependencies. I dont know if this is feasible. ---- ![BananaMerge.png](https://archive.blender.org/developer/F109372/BananaMerge.png) The banana shows no cuts/is not peeled when not deformed, providing the merge is activ. This can also be done with Array merge, but it dont allows to animate seperate banana peels, or to texture it as a whole. In theory you could display every fruit outside and inside with a single mesh (after cutting it, suitable for animations). ---- ![TreePluck.png](https://archive.blender.org/developer/F109374/TreePluck.png) Last one is Skin modifier (maybe not an ideal example). Skin should be generally not bad to use, because you can set higher merge limits and stick how you like. Also its very organic - a bit like metaballs when combined with a "merge"-modifier + Subsurf. > same method as in @zeauro´s SphereHorn-File. You could collect connected vertices on one point and they merge to a single vertice with the modifier. Then move the vertices to different locations and you get a larger and still connected mesh. (for waterdrops, growing plants or something like that) Only problem i see is the radius and root after merge operation.

Patrice Bertrand commented

2014-09-09 14:06:15 +02:00

It's interresting to see, in these examples that the effect of the "remove doubles" may be usefull not only after (after in terms of time not of stack order) other modifiers have acted, but also before, that is to say mesh parts are glued and merged to start with, then because of various modifiers they are torn appart, double vertices get separated and the "double modifier" ceases to operate.

Copied from D443 : We must keep in mind that although we call it "remove doubles", (as in "fix a problem"), the operation is really "remove near vertices". In that sense, even though few modifiers would actually create true doubles, many could generate very close vertices. The array modifier would do this simply if using scaling (through a scaled empty object), then each instance gets smaller and smaller, and vertices get nearer. Shrinkwrap modifier could also quite often yield vertices that are very close to each other and could be simplified by a "remove doubles".

It's interresting to see, in these examples that the effect of the "remove doubles" may be usefull not only **after** (after in terms of time not of stack order) other modifiers have acted, but also **before**, that is to say mesh parts are glued and merged to start with, then because of various modifiers they are torn appart, double vertices get separated and the "double modifier" ceases to operate. Copied from [D443](https://archive.blender.org/developer/D443) : We must keep in mind that although we call it "remove doubles", (as in "fix a problem"), the operation is really "remove near vertices". In that sense, even though few modifiers would actually create true doubles, many could generate very close vertices. The array modifier would do this simply if using scaling (through a scaled empty object), then each instance gets smaller and smaller, and vertices get nearer. Shrinkwrap modifier could also quite often yield vertices that are very close to each other and could be simplified by a "remove doubles".

Karja Krähwald commented

2014-09-12 15:34:25 +02:00

A merge option for meshobject + meshobject (like target object) could handle more - Linked Duplicates (...), so you have only one mesh to work on.
Also comes in place where (...) 2 objects are needed or would be helpful, but result object shall appear as connected. (...)

An example:
You could duplicate (AltD-link) fingers and scale+place the objects in right position to the hand, before merging them to the character mesh with the modifier.
Thus you can edit finger & vertexgroups on a single mesh, without having to duplicateX5 and reassigning vertexgroups on every finger after changes.
The way is that linked fingers get the merge modifier with target "character mesh" and vertexgroups have to be renamed only one time for every duplicate.

For the Array: This could be used where you want to "skip" repeating parts of the mesh, for example on snake models.

Add a linked duplicate of the head mesh.
Give it a mask modifier and mask the repeating part.
Mask the head mesh aswell (opposite).
Array the repeating object.
Use merge modifier and head mesh as target > mesh closed.

As mentioned above, its like Array merge in this example, but end & start of the arrayed mesh can be modified better.
Nevertheless, this is highly theoretical and maybe there are better methods to handle this specific example, but it should work for lot of models.

Would be nice if this gets considered.
I like to suggest not to see this as another function, rather than a main feature of the modifier in terms of possible use cases.

> A merge option for meshobject + meshobject (like target object) could handle more - Linked Duplicates (...), so you have only one mesh to work on. >Also comes in place where (...) 2 objects are needed or would be helpful, but result object shall appear as connected. (...) An example: You could duplicate (AltD-link) fingers and scale+place the objects in right position to the hand, before merging them to the character mesh with the modifier. Thus you can edit finger & vertexgroups on a single mesh, without having to duplicateX5 and reassigning vertexgroups on every finger after changes. The way is that linked fingers get the merge modifier with target "character mesh" and vertexgroups have to be renamed only one time for every duplicate. --- For the Array: This could be used where you want to "skip" repeating parts of the mesh, for example on snake models. ![WhatTheSnake.png](https://archive.blender.org/developer/F110009/WhatTheSnake.png) - Add a linked duplicate of the head mesh. - Give it a mask modifier and mask the repeating part. - Mask the head mesh aswell (opposite). - Array the repeating object. - Use merge modifier and head mesh as target > mesh closed. As mentioned above, its like Array merge in this example, but end & start of the arrayed mesh can be modified better. Nevertheless, this is highly theoretical and maybe there are better methods to handle this specific example, but it should work for lot of models. --- Would be nice if this gets considered. I like to suggest not to see this as another function, rather than a main feature of the modifier in terms of possible use cases.

Karja Krähwald commented

2014-09-16 15:51:26 +02:00

Here is an example where merge is not only handy, but even necessary.

The belt mesh got a curve modifier and follows a curve circle (white line) with Stretch & Bounds Clamp options enabled.
As you can see, the ends could use a good merger.
Or you apply the curve modifier instead, but this means you cant use curve any more for animation or pose corrections.

The idea is to place a Merge modifier after Curve modifier.
Therefore you dont have to apply the modifier and dont have to lose curve control, and of course, its still very easy to make changes on the mesh.

![BeltMerge.png](https://archive.blender.org/developer/F110765/BeltMerge.png) Here is an example where merge is not only handy, but even necessary. The belt mesh got a curve modifier and follows a curve circle (white line) with Stretch & Bounds Clamp options enabled. As you can see, the ends could use a good merger. Or you apply the curve modifier instead, but this means you cant use curve any more for animation or pose corrections. The idea is to place a Merge modifier after Curve modifier. Therefore you dont have to apply the modifier and dont have to lose curve control, and of course, its still very easy to make changes on the mesh.

marc dion commented

2014-09-22 18:50:46 +02:00

Added subscriber: @MarcClintDion

Ray Mairlot commented

2014-10-02 18:43:03 +02:00

Added subscriber: @RayMairlot

Ray Mairlot commented

2014-10-02 18:43:03 +02:00

This may be a similar situation to what @karja said above, but particularly when modelling wheels/tire tread it is necessary to merge the beginning and end of the tire to create a complete circle.

Currently, it is necessary to apply both the array and whatever deform modifier you have used to bend it into a circle (commonly curve or simple deform set to bend) and then remove doubles in edit mode. The obvious disadvantage is that should you want to later change, say, the design of the tire tread it is necessary to have access to the original un-modified mesh and then repeat the apply, remove doubles process.

A remove doubles modifier could simply sit at the end of the modifier stack and allow the underlying mesh to be altered at any point while still forming a seamless circle.

This may be a similar situation to what @karja said above, but particularly when modelling wheels/tire tread it is necessary to merge the beginning and end of the tire to create a complete circle. Currently, it is necessary to apply both the array and whatever deform modifier you have used to bend it into a circle (commonly curve or simple deform set to bend) and then remove doubles in edit mode. The obvious disadvantage is that should you want to later change, say, the design of the tire tread it is necessary to have access to the original un-modified mesh and then repeat the apply, remove doubles process. A remove doubles modifier could simply sit at the end of the modifier stack and allow the underlying mesh to be altered at any point while still forming a seamless circle.

Campbell Barton commented

2014-10-02 19:05:18 +02:00

Updated task with findings section.

Updated task with **findings** section.

Patrice Bertrand commented

2014-10-02 19:48:58 +02:00

If there was a "remove double" modifier, then it would be simple to add settings based on vertex groups. (1) limit the merge to a vertex group, but also (2), limit with given source group onto given target group.
I believe in lightweight modifiers with limited features, used as legos. If and when some node based modifier scheme is introduced, then we would probably use more atomic feature nodes assembled at will. When this comes, it is likely the current modifiers will not be trashed, but simply ported to nodes. In that perspective, it does make sense to introduce such light or atomic modifiers, later to be turned into nodes.

That being said, I did mention earlier that when doubles removal is bundled with a modifier, it can be made more efficient, because it only acts on the vertices that were created. In order to split the work in (A) mesh generation, followed by (B) doubles removal, we would need the (A) node to output not just a mesh, but also vertex groups that identify the newly created vertices. This vertex group node-output would then be pluged into the remove doubles node inputs.

If there was a "remove double" modifier, then it would be simple to add settings based on vertex groups. (1) limit the merge to a vertex group, but also (2), limit with given source group onto given target group. I believe in lightweight modifiers with limited features, used as legos. If and when some node based modifier scheme is introduced, then we would probably use more atomic feature nodes assembled at will. When this comes, it is likely the current modifiers will not be trashed, but simply ported to nodes. In that perspective, it does make sense to introduce such light or atomic modifiers, later to be turned into nodes. That being said, I did mention earlier that when doubles removal is bundled with a modifier, it can be made more efficient, because it only acts on the vertices that were created. In order to split the work in (A) mesh generation, followed by (B) doubles removal, we would need the (A) node to output not just a mesh, but also vertex groups that identify the newly created vertices. This vertex group node-output would then be pluged into the remove doubles node inputs.

Leon Cheung commented

2014-10-03 06:55:10 +02:00

Added subscriber: @ZhangYu

Thomas Roberts commented

2014-10-04 11:18:11 +02:00

Added subscriber: @RyukoReiakuma

Andy Davies commented

2014-10-11 18:33:50 +02:00

Added subscriber: @AndyDavies-3

Andy Davies commented

2014-10-11 18:45:41 +02:00

+1 I think is a modifier that would be worth adding even if it were only for pure modeling purposes.
There are many occasions where I would rather work procedurally (via a curve) but then have to turn it into a mesh because there is a seam.

+1 I think is a modifier that would be worth adding even if it were only for pure modeling purposes. There are many occasions where I would rather work procedurally (via a curve) but then have to turn it into a mesh because there is a seam.

marc dion commented

2015-02-02 11:23:11 +01:00

user:karja has me convinced this is a really good idea. Normally for some of the things shown in his(her) posts, people tend to use a stand-in object that is complete and seamless while the breakable object is invisible. Then the object is made to "brake" by reversing the visibility of everything at a certain keyframe, it works but this idea for a Remove Doubles modifier seems neater and would be very easy to setup and maintain.

I guess that's all obvious now from all the posts made but I just wanted to add to the use cases for this. -> Breaking glass. The broken mesh could be shown the whole time instead of replacing an unbroken one at the time of breakage.

The subtle tearing that would come from the merge threshold being broken by various vertices at different times may actually enhance the illusion.(if anyone's eyes can even track that fast :)

user:karja has me convinced this is a really good idea. Normally for some of the things shown in his(her) posts, people tend to use a stand-in object that is complete and seamless while the breakable object is invisible. Then the object is made to "brake" by reversing the visibility of everything at a certain keyframe, it works but this idea for a Remove Doubles modifier seems neater and would be very easy to setup and maintain. I guess that's all obvious now from all the posts made but I just wanted to add to the use cases for this. -> Breaking glass. The broken mesh could be shown the whole time instead of replacing an unbroken one at the time of breakage. The subtle tearing that would come from the merge threshold being broken by various vertices at different times may actually enhance the illusion.(if anyone's eyes can even track that fast :)

lower case commented

2015-02-14 16:04:04 +01:00

Added subscriber: @lowercase

lower case commented

2015-02-14 16:04:04 +01:00

you need something like this to be able to use 'pointiness' on text and curve objects, as caps are disconected from bevel

Julio Iglesias commented

2015-07-22 18:37:22 +02:00

Added subscriber: @Zafio

Julio Iglesias commented

2015-07-22 18:54:03 +02:00

+1 Worth adding IMO, taking into account the cases already described.

Today I've found myself in the Array+Curve situation, at it was frustrating.

At first I was confused by the "first/last" merge options in the Array Modifier, it took me a while to realize it doesn't work with a curve modifier on top.
So, for that particular case, unless a merge first/last option is implemented for the Curve Modifier (which would be also nice), a Remove Doubles modifier really makes sense.

Regards.

+1 Worth adding IMO, taking into account the cases already described. Today I've found myself in the Array+Curve situation, at it was frustrating. At first I was confused by the "first/last" merge options in the Array Modifier, it took me a while to realize it doesn't work with a curve modifier on top. So, for that particular case, unless a merge first/last option is implemented for the Curve Modifier (which would be also nice), a Remove Doubles modifier really makes sense. Regards.

Leon Cheung commented

2015-07-22 19:18:26 +02:00

Two more examples to show the importance of this feature:

A pac-man:

A plane to sphere morphing:

As shown in the image, I have to subdivide the mesh a lot to have the closed seam less noticable, and of course, smooth shading is helpless in those cases.

Two more examples to show the importance of this feature: A pac-man: ![pacman.gif](https://archive.blender.org/developer/F211659/pacman.gif) A plane to sphere morphing: ![rect-to-sphere.gif](https://archive.blender.org/developer/F211660/rect-to-sphere.gif) As shown in the image, I have to subdivide the mesh a lot to have the closed seam less noticable, and of course, smooth shading is helpless in those cases.

Admiral Potato commented

2015-11-28 01:59:00 +01:00

Added subscriber: @AdmiralPotato

gandalf3 commented

2016-01-25 21:02:40 +01:00

Added subscriber: @gandalf3

michael knubben commented

2016-02-15 14:33:22 +01:00

Added subscriber: @michaelknubben

Jonathan Williamson commented

2016-02-15 16:47:09 +01:00

Added subscriber: @JonathanWilliamson

Matt Heimlich commented

2016-02-15 17:50:08 +01:00

Added subscriber: @MatthewHeimlich

Matt Heimlich commented

2016-02-15 17:50:08 +01:00

I'm sure it's already been covered above, but this would be really nice for keeping contiguous shading on characters that are split into multiple objects (arms, legs, torso, head, etc.) for the sake of external texturing tools that don't support Blender's UV sets.

Gwenael Le Page commented

2016-04-27 23:09:07 +02:00

Added subscriber: @gwentiv

Gottfried Hofmann commented

2016-05-10 15:38:34 +02:00

Added subscriber: @GottfriedHofmann

Gottfried Hofmann commented

2016-05-10 15:38:34 +02:00

When modeling with the screw modifier, a remove doubles modifier would be awesome as well! I have been longing for this for a long time now.

Andrei Nadin commented

2016-05-15 00:34:34 +02:00

Added subscriber: @AnadinX

Andrei Nadin commented

2016-05-15 00:34:34 +02:00

This would be a very good addition, I came across this causing me problems when doing a deformed torus made from bends/twists etc. In Cinema4D, there is the Connect object that takes the whole stack and has the weld/merge functionality in it. This is very similar concept and would be invaluable.

Campbell Barton removed their assignment 2016-08-11 06:37:59 +02:00

Campbell Barton commented

2016-08-11 06:37:59 +02:00

Removed subscriber: @ideasman42

Bloody Rain commented

2016-11-26 00:37:55 +01:00

Added subscriber: @BloodyRain

Bloody Rain commented

2016-11-26 00:37:55 +01:00

I'd love this because I work a lot with the Mirror modifier and run not rarely into the problem that I want to merge some portions along the Mirror axis but not all of them.

So my first idea was to propose an addition to the Mirror modifier to supply it with a vertex group similar to how the Mask modifier uses one which then defines where merging would occur (or not). Optionally with the weight being used as a multiplier for the threshold.

This idea however is much more versatile if said vertex group selection for what can and can not be merged would be added.

I'd love this because I work a lot with the Mirror modifier and run not rarely into the problem that I want to merge some portions along the Mirror axis but not all of them. So my first idea was to propose an addition to the Mirror modifier to supply it with a vertex group similar to how the Mask modifier uses one which then defines where merging would occur (or not). Optionally with the weight being used as a multiplier for the threshold. This idea however is much more versatile if said vertex group selection for what can and can not be merged would be added.

Thomas commented

2017-04-14 13:00:03 +02:00

Added subscriber: @thomasmouilleron

Thomas commented

2017-04-14 13:00:03 +02:00

This would be so useful for maxed out 100% Bevels to create a more controlled subdivision

Nahuel Belich commented

2017-11-27 04:04:22 +01:00

Added subscriber: @NahuelBelich

cédric lepiller commented

2018-08-24 11:44:37 +02:00

Added subscriber: @cedriclepiller

cédric lepiller commented

2018-08-24 11:44:37 +02:00

Any news about this?

Mikail commented

2018-08-24 11:49:37 +02:00

Added subscriber: @Fiendari

Mikail commented

2018-08-24 11:49:37 +02:00

This is one of the most needed modifiers for blender modelling, it would make life so much easier in so many cases and don't we all want easy life I bet you do.

Rainer Trummer commented

2019-01-11 20:57:40 +01:00

Added subscriber: @RainerTrummer

Rainer Trummer commented

2019-01-11 20:57:40 +01:00

Also from our side at the studio a very much longed for modifier! Are there plans to go ahead with this proposal?

marc dion commented

2019-01-11 21:04:45 +01:00

@RainerTrummer
The dev who started this thread also unassigned and unsubscribed himself from the topic almost 3 years ago.

@RainerTrummer The dev who started this thread also unassigned and unsubscribed himself from the topic almost 3 years ago.

marc dion commented

2019-01-11 21:06:29 +01:00

Removed subscriber: @MarcClintDion

Patrice Bertrand commented

2019-01-12 14:44:47 +01:00

I'm the one who started this thread, and as @RainerTrummer says, I am not a blender developper anymore. Back in 2014, it seemed any work on new modifiers was prohibited because a change of paradigm towards node-based modifiers was envisaged. I had built a 'randomizer' modifier that was trashed for that reason.

In case anyone starts working on this again, I have some thoughts to share regarding the remove double algorithm, whether its part of a standalone modifier or embedded in other modifiers such as the array modifier. The current algorithm builds a list of all vertices, sorted on s = x+y+z, then scans this list. It looks like a 3 dimensional problem has been magically transformed into a one dimensional problem, but this is a total illusion: you might just as well sort all vertices on x, then scan the list. Working on the sum has merely changed the main axis through which vertices are compared for distance. In the end, for each value of s (or of x), you need to loop through all vertices that are within epsilon of s. It is not far from o(N^2).

The algorithm I had in mind back then was very different, and I believe it could be much faster when the number of vertices is large. It goes like this. You divide the whole space in little cubes of size epsilon. For each vertex, you determine to which little cube it belongs and you build a hashmap where the key is made of the coordinates of the cube, and the value is a list of vertices that are inside this cube. So for N vertices, this is o(N). Then you do another scan of vertices and for each vertex, you will retrieve the vertices that are in the same cube or in one of the 27-1 adjacent cubes. You will compare the distance for each of these candidate doubles.

If someone wants to start work on this, I hope this can help.

I'm the one who started this thread, and as @RainerTrummer says, I am not a blender developper anymore. Back in 2014, it seemed any work on new modifiers was prohibited because a change of paradigm towards node-based modifiers was envisaged. I had built a 'randomizer' modifier that was trashed for that reason. In case anyone starts working on this again, I have some thoughts to share regarding the remove double algorithm, whether its part of a standalone modifier or embedded in other modifiers such as the array modifier. The current algorithm builds a list of all vertices, sorted on s = x+y+z, then scans this list. It looks like a 3 dimensional problem has been magically transformed into a one dimensional problem, but this is a total illusion: you might just as well sort all vertices on x, then scan the list. Working on the sum has merely changed the main axis through which vertices are compared for distance. In the end, for each value of s (or of x), you need to loop through all vertices that are within epsilon of s. It is not far from o(N^2). The algorithm I had in mind back then was very different, and I believe it could be much faster when the number of vertices is large. It goes like this. You divide the whole space in little cubes of size epsilon. For each vertex, you determine to which little cube it belongs and you build a hashmap where the key is made of the coordinates of the cube, and the value is a list of vertices that are inside this cube. So for N vertices, this is o(N). Then you do another scan of vertices and for each vertex, you will retrieve the vertices that are in the same cube or in one of the 27-1 adjacent cubes. You will compare the distance for each of these candidate doubles. If someone wants to start work on this, I hope this can help.

yoann commented

2019-02-04 01:23:32 +01:00

Added subscriber: @softyoda