A bug should be reported if modifiers are creating meshes which violate our own rules for geometry.
Try apply the modifier and run this in the Python Console, with Blender running from a terminal:
C.object.data.validate(verbose=True)
Errors will be printed, with the function returning True if a change needed to be made.
I have made a thread about this already:
But the geometry showcased in the thread returns False when running that Python command. This is the kind of geometry only Blender considers as correct, but pretty much any other software alongside Blender in the pipeline considers it degenerate geometry. Furthermore, even if it’s the kind of topology Blender can handle, it’s only rarely the kind of topology user desires.
All modifiers have limitation when it come to animation IMO.
On some cases, like motion design, it’s a good thing, on other like a character, it will not work.
People have to learn to use the modifiers accordingly of what they are doing with their asset.
The only important thing is to make it not break blender’s rules as ideasman42 said.
I’m not a dev, so I don’t really see the issue with the merge modifier.
After for using other modifiers like insert, extrude etc, I think the BF will have to make the workflow a little bit different, more like Houdini, with groups, etc.
Discussing what you think should/shouldn’t be accepted is a separate issue.
2 posts were merged into an existing topic: Blender’s Architecture (split from merge modifier discussion)
Perhaps im crazy, but when you merge in the array and its above the simple modifier. Why is that gap there again then? That doesnt make sense?
EDIT
I see what you mean. first and last doesnt seem to take note when its above the bend deform
The stack is reversed, so the array is below the simple deform.
The simple deform needs a merge option or/and we need a merge modifier.
Since devs told that the modifier will be implemented this thread don’t have reason to be bump each few time.
If you want to talk about blender architecture it is better split that topic in other thread.
your dream is near:
Weld Modifier: Initial Implementation
Part of T70240
This patch can be split into two commits:
- BLI_bvhtree_overlap_ex: add ‘max_interactions’ parameter
- Weld Modifier: Initial Implementation
It only solves the option described as Full in the proposal.
Still to be done
From proposal
- Seams: restrict welding to vertices along boundary edges.
- Edge Collapse: collapse edges below the length threshold.
- Vertex Group: option to limit welding to vertex groups.
Other ToDos
- New icon for the modifier.
- Some customdata types are not being correctly interpolated (vertex colors rgba, vertex weight).
- A real distance to merge (currently the distance is used to test cubic node overlap).
- Cache BVHTree.
Fantastic news!
I made two rather light hearted quick mock-ups:
I’m afraid a Weld mod would be in the ‘Generate’ section. LOL
Hi there, thanks for the info 
When you say that this modifier is in the master release, where exactly can I download it? I ask you thisk since in the 2.82 Alpha I find nowhere the Merge Modifier 
Thanks again 
Cheers.
Hi Michele, perhaps it hasn’t been commited in time for compilation. Maybe tomorrow. 
It’s in master, and if you build your own blender and pull the latest commits, you get the new Weld modifier.
Thanks everyone. I guess I just have to wait for the builder 
Cheers.
IMO, these options should be added to the weld modifier:
Hm, now if I think about it: in some cases removing interior faces might not require complex volumetric algorithms if you try to remove them at creation time. For that, you have to check, for each face removed, if there’s a double or more and then remove those as well.
