[solved] Hurdles to implementing Merge modifier?

Hi Ideasman42, I really respect your opinion as a blender dev but I wanted to answer your concerns with some of my personal experiences using Blender in production as concept artist.

  1. Needing to account for all possible degenerate results

You can create a grid with 50 divs and select a few faces, run inset, and if you push it far enough you will get horribly messed up geo that is crossing over itself and all kinds of geo damage. Does that mean we shouldn’t have inset? It makes no sense to keep a very valuable tool away because it won’t give us perfection. Yes sometimes it may mess things up, but hey, we can just turn off the modifier then! The pros outweigh the cons considerably, and I really don’t view this as a con at all

  1. It’s useful because you can merge in a procedural way, changing your input geo and still merging without any destruction. It would be like saying whats the point of a subdivision modifier when we can subdivide in edit mode. Being able to go back in non destructively is a life saver when working with clients on hard surface designs.

  2. Thats the first point, and again, I’m totally fine with this modifier not creating 100% perfect solution every time. I’m sure everyone else is okay with that as well. We don’t need perfection, nothing is perfect, it just has to work decently, as good as edit mode. Slow is totally fine again because we can just turn off the preview for the modifier and view it when we need it.

I think Merge modifier is very important and at this time I cannot see any cons. You have my vote, Wazou

2 Likes

I could have been more clear, by:

Needing to account for all possible degenerate results

I meant we need to prevent invalid states which could crash Blender (a face using the same vertex/edge twice, or duplicate edges/faces - for example).

Where to draw the line is always a judgement call.

Probably people using this modifier don’t use it for animation, if you do - it will be prone to jitter output.

I’m wary of adding functionality which users can justifiably report new bugs in.

Although we can document it as a known limitation, it doesn’t stop people reporting bugs and having the perception that Blender is “buggy” because of these kinds of unpredictable results.

3 Likes

Thank you ! The first point makes a lot of sense, I don’t know much about the process for that and how much of it can just be go into edit mode -> select all -> merge by distance on a continual basis to avoid any rewrites at all.

But regarding animation, a very simple solution would be checking if the object has keyframe data and sending a popup saying that adding this merge modifier will remove the keyframes. No bug reports then. I’m sure there can be other problems that can come up though , its definitely a judgement call. I can’t think of any that are worth not having it, but thats my opinion.

I’m still using Blender anyways because its the best, so thats all I can say. I hope that these kinds of worries don’t prevent further development of things like VR and so on. I would much rather have new features that are buggy in certain cases over no features until they are very reliable. Especially with our community where anyone can go in and help once the ball gets rolling.

This should not only concern merge modifier but also the non-modifier operators, which are often prone to creating such geometry. Merge by distance operator for example.

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.

2 Likes

Discussing what you think should/shouldn’t be accepted is a separate issue.

1 Like

2 posts were merged into an existing topic: Blender’s Architecture (split from merge modifier discussion)

11 posts were split to a new 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.

6 Likes

your dream is near:

Weld Modifier: Initial Implementation

Part of T70240

|220x120.53892215569

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.
4 Likes

Fantastic news!

I made two rather light hearted quick mock-ups:

image

:joy:

:grin: :dancing_women:

I’m afraid a Weld mod would be in the ‘Generate’ section. LOL

1 Like

the welder is now officially in master, good welding to all.

Modifier: New Weld Modifier

6 Likes

Hi there, thanks for the info :grin:

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 :thinking: Thanks again :wink:

Cheers.

Hi Michele, perhaps it hasn’t been commited in time for compilation. Maybe tomorrow. :slightly_smiling_face: :upside_down_face:

1 Like