does not seem like a big obstacle for you from what I saw from your addon 
1 Like
I’m not as good as you think and C is different from python ^^
1 Like
I just tried to use the word industry standard, maybe it will ticle the devs ^^
We need to do it it’s industry standard !! 
Seriously, merge modifier isn’t different from triangulate or else, so I don’t see why it should not be in blender.
1 Like
not so different… ^___^
1 Like
This would be really useful modifer for modelling standpoint and totally must have for completing non destructive workflow inside blender. It’s proven that modelling is getting more and more non destructive when ever its possible because it allows users to come back later and change their model completely different in matter of seconds instead of tweaking it in polygonal level and moving vertices.
Looks like two possible implementations have shown up, but they’re not submitable.
2 Likes
When I read this I just don’t want to support development fund anymore. It seems such a small request that can save a lot of unneeded work. I don’t understand why in 2019 we don’t have it yet.
3ds max has much more modifiers, in Houdini, you can create your own! Blender in modifier area feels like in stoneage.
5 Likes
There is no need to add a new modifier into the modifiers list. Just add “merge vertices by distance” method to Decimate modifier, and everyone will be happy.
I’ve seen an explanation of merge modifier absence - that each modifier in the stack uses a lot of memory. But modifiers are not about saving memory, they are about non-destructive modelling, and if the memory consumption was the only concern, by that logic it would be better to not have any modifiers at all.
This is weird, because a big portion of modifiers have their operator counterparts.
3 Likes
How do you do if you need to merge points but don’t need a specific modifier ?
You need a merge modifier.
I don’t see why we should not have a modifier only for that plus have a merge on each modifier too.
6 Likes
This is the goal of the project I mentioned, extending Blender’s modifier system to interface with plugins. And the developer of the project has already written a merge modifier for it.
Also, remember that the devs are working on a better long-term solution (nodes). Adding any merge modifier to the old stack-based modifiers is a temporary solution. Nodes will be able to do this sort of thing and a lot more.
2 Likes
So a merge modifier based on the remove doubles operation has the following
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).
These look like they could be taken care of using the bridge operation (with merge option).
If the bridge operation was implemented as a modifier, are there any major use cases that this wouldn’t cover for you Wazou? Are there likely to be any objections from the Blender Devs?
I for one could see some potential for a multi object bridge modifier.
Side note: Is there any documentation on preferred implementation for face / edge groups as an alternate to vertex groups?
[edit] yeah figured out that you can’t do selections on the derived meshes created by other modifiers, therefore it’s not always possible to create the selection possible for the bridge modifier to work.[/edit]
1 Like
Yeah face/edge groups is something for another thread.
Also of note, Lightwave finally got round to implementing face/edge groups in their 2019 release.
1 Like
Hi, a more general response to this topic, it’s come up from time to time that we could make more edit-mesh operations into modifiers.
Inset-Faces, Poke, tris-to-quads, merge-by-distance, etc…
We could always do this, the issue is - this moves in towards something like constructive modeling - where you up applying many primitive operations to create the desired outcome.
While constructive modeling is useful, the current modifier won’t support this efficiently, people will create setups that should work in principle, in practice are becoming unusably slow.
This is disputable, of course in some cases it can work, but I believe doing a round-trip:
Mesh -> Convert-To-EditMesh -> Run Operation -> Convert-To-Mesh.
… for minor editing operations is going to end up with something which is slow.
Currently there is a project to have nodal modifiers which I believe we plan to better support constructive modifiers by supporting edit-mesh operations without having to convert from/to mesh for every node.
Someone could reasonably reply that’s all well and good but we want this modifier now, because we need it and it’s useful.
Firstly, modifiers that create duplicates (spin, array, mirror) - for eg, already have the option to merge first/last.
If there are typical modifier setups that create doubles, we could check on adding the options for those - since merge-by-distance for spin (for example), is significantly faster than a more general operation which is more complex than you might expect.
A general merge-by-distance may result in splitting an n-gon in to many faces for example, even when it doesn’t - we don’t know this in advance so we need to account for all possible degenerate results.
Secondly, I didn’t see many good examples of where this would be useful.
I’m fairly sure the example above wont work, if you run the current merge-by-distance code on this, it will end up collapsing edges before it connects opposite boundary edges.
It’s solvable but requires a different method of detecting duplicates.
Thirdly, merge-by-distance is prone to creating bad/degenerate geometry, vertices from different surfaces joining, resulting in edges with 3+ faces using them - geometry which often causes problems when you need to apply other operations on-top of them.
Again, we could have a more controls here:
- Collapse edges.
- Collapse faces.
- Sew boundary edges.
… these aren’t as likely to create degenerate geometry, not too complicated but would need to be supported.
Conclusion: my concerns with this remain, I think adding merge-by-distance modifier with the edit-mode code as-is could be OK, however it’s going to be slow and may end up needing more functionality to work usefully.
It’s partly a timing issue, we might be better to hold off porting edit-mesh tools to the modifier stack and move to constructive modeling when we have a nodal modifier system that better supports it.
I’ll talk to the other developers.
16 Likes
I tend to agree. There are a TON of new modifiers would love to see:
- transform
- scatter
- copy to points
- merge by distance
- join
The list goes on for a while, but most of these really don’t make sense in the current modifier context. In a nodal context they do! A perfect example of this is “join”. Joining objects together as a modifier makes almost no sense, how would that even work? It brings up so many issues as a modifier. As a node, however, no problem! You have a graph for your object, and you have a cube and a sphere, you connect them both with a join node, tada, they are one object now.
As for the merge operation, I have definitely have ran into times when I simply want a merge modifier, but as it seems there are technical issues to consider with that. So as far as I’m concerned, if this is an issue that the devs don’t want to address now, and would rather tackle later during modelling nodes, that’s fine with me.
I don’t know what to respond to this.
I struggle every day with the lack of a merge modifier.
There are plenty of people like me who need it too, you can check the messages on the petition from people who signed it.
I added several great examples of why we need it and we can add more.
And you say you don’t see many good examples of where this would be useful?
On my example, it works, I’m using a fork of blender and I have no issue with this merge modifier.
I don’t know if you understand the non-destructive workflow, I use it as a professional, on professional jobs.
I make everything non-destructive to be able to make as many changes as I want.
My clients are happy because I can make fast and drastic changes really fast.
After that, I apply the modifiers I need to apply to finalise my model.
Direct modeling isn’t the only way to make things in Blender.
Check what can be done with houdini, there are a lot of modifiers, a merge modifier too, same for 3dsmax, etc.
It’s true that not all people use this workflow because they don’t know it, but Blender is made for and being against this modifier is like being against blender itself.
I know you are not a modeler and I understand your point of view, but even if it can be better later with everything nodes, it is needed right now.
Maybe the merge-by-distance actual code is bad, maybe it shoud be different, but still, we need it and I hope you will change your mind about this because this is really important and please follow what blender user’s need right now even if it’s not perfect, we cannot wait again 4-5 years to have something that usefull and that every other software have.
12 Likes
The problem is that modifiers node system maybe will need 3-4 year to that. Think that we have been waiting for everything nodes 4-5 years and actually we don’t have particles nodes…
1 Like
If we’re going in a nodal direction anyways, implementing a not perfect mod stack solution for merge by distance as a temp solution can be a bit more soothing than not having this at all. I know, if we open pandora’s box we can then find ourselves implementing tools that are less than optimal, which is not what the devs want, understood. I think Cédric has promoted blender’s non destructive modeling powers immensely and has the ground to state that merge by distance mod is useful for such workflows. My 2 cents.
1 Like
Of particular interest to people here there was another example of a merge modifier within blender in Juri Unt’s custom build here as a hack of the Build modifier, not sure how it was implemented…
I think it was this build used to create the gif of an implementation.
These were some additional examples of cases that could use a merge modifier within the petition.
Blender already has several modifiers with a merge option, but most of them are limited.
For example, the array has a merge modifier but combined with a curve or a simple deform, the merge will only work on the array part, not on the deformation part.
In this example, the Simple Deform Modifier comes after the merge modifier and it doesn’t have a merge option, so the final result is bad as you can see.
The curve modifier doesn’t have a Merge option either.
The boolean or Bevel don’t have merge option, so, overlapping vertices will give bad results.
To work in a fully Non-destructive way, we need to be able to fix merge issues.
There is an example of how it could work (from a blender fork), fix issues and keep everything editable.
As you can see, the issue is fixed, the model is perfect.
You could also want to use it to merge overlapping points in scanned meshes for example.
As to who the people could be using these modifier’s, there already exists users who are trying to get the most out of blender for a Non-Destructive workflow.
Predominantly these people are Hard-Ops and Speedflow users, and there’s probably more who could come up with a use with it after it’s implemented.
Its a shame we’re little closer to everything nodes and have gotten the same answer as we got in 2016 regarding this.
8 Likes
I think that this thought is wrong.
- All that modifiers are useful, really useful
- It’s not necessary create a “edit mode” modifier, at least until node system
- If some modifiers have a bad performance (what I don’t know why this must to have a bad perfomance and not the actual modifiers) It’s responsibility of the user to use it or not. Actually blender have sculpt system and a bad performance in dyntopo with dense meshes, but we don’t remove that feature for that reason.
- The main problem is that blender don’t give to the users any way to implement custom modifiers. This must be changed because users need to be able to made custom modifiers and custom nodes in the future node system. We cannot work only with the tools that developers consider useful.
What can be considered normal is that in 6-7 years we didn’t see any improvement in modifiers and we don’t have any way to solve this problem.
5 Likes
Devs please be nice and add a merge modifier.
7 Likes