[solved] Hurdles to implementing Merge modifier?

The reason is that all the problems you are mentioning are not being done because they are all very complex problems that require lots of development time and complex planning to solve, where as weld/merge modifier is literally taking a few already written lines of code and turning them into modifier code. An afternoon for an experienced programmer at most. The ratio of development resources needed to benefit to the end user is extremely favorable here, yet the feature has been repeatedly rejected due to some of the Blender developers not being familiar with even basic non destructive modeling workflows.

6 Likes

Devs are already working on perfs. Undo, etc.
I don’t see why modifiers should wait if it’s easy to do/fix.

16 posts were split to a new topic: Delete Materials Feature Request

@BD3D hey, I am with @Wazou on this one. There are many things missing from bender(like proper openVDB integration for example) but none of those are easy to implement or integrate. The weld modifier is a no brainer from the development point of view. This feature already exists as an operator, so making it a modifier is very easy. Not only that, but it was already done several times by various third parties and it was rejected every time because of “everything nodes”. Everything nodes is not going to happen in the near future. Devs started talking about it 5 years ago and nothing realy happend…

@jesterKing Anyway, from my point of view blender should have a generic modifier interface accesible also from python which can run any existing operator as a modifier. This could be similar to the attribute wrangler node in Houdini. In this way you can run python code from this wrangler modifier, which can give you any behavior you want. And I think this is also a no brainer, implementation wise.

1 Like

That is an important feature, too.

Dealing with a polygonal surface, user has basic needs like extending this surface, inserting elements in this surface, deforming this surface, cutting this surface and sewing surfaces into a unique one.

Most of modifiers of Generate category are relative to extension/insertion.
Deform category takes into account deformation need.
We have two modifiers Edge Split and Mask for cuts.
But absolutely none for merging boundaries of surfaces.
Probably another basic interesting modifier that could be added before “everything nodes” project becomes a reality, could be a “fill gap, fill holes” modifier.
One or two modifiers to make mesh manifold during wait for modifier nodes : that is not a caprice.

The deal has been sealed, I think this thread should be closed now and go with what @jesterKing suggested for future discussions otherwise we’ll keep going in Circles.

2 Likes

It is probably worse because of subdivision modifier

Here’s my weld modifier proposal
that intends to avoid the operation being slow by default.

It’s not such a big project so I’ve set it as a target for 2.82.

31 Likes

Maybe because you don’t work on environement scenes. Well compared to other software in the environemental side of things it’s really worse, that’s why we are trying to implement hacky display optimisation technique in our addon.
As for ctrl z and array modifiers i’m sorry but there’s no point’s to argue here.

True. Wazou have influence. There’s peoples asking for features all over the place. We should have a system in place for which patch is prioritized over another. Same for user base features idea, for example RCS. But well Four year old simple posts are still ignored to this day.

Kind of a voting system on which features should be implemented and elected… ect… im sure there’s a democratic way of doing this. Public outcry and petitions is just not a good solution.

For example all X level contributor (bronze/gold/sliver ect…) have access to the voting thread and can have an influence over what little feature is implemented first… ect… this could be good for the funding too

Exactly, the ones with Social Media and youtube Channels can rally their followers with a single post while the little guy working on his own projects has no voice, if BF is about fairness then everyone should be equal, i don’t know what system they should use but it should work for everybody.

I’m thinking it might be best to split this talk of means of developmental input into its own thread.

Also regarding older RCS posting, maybe its a good idea to pack together some of these suggestions into larger briefs that document specific deficiencies within blender’s workflows. Like in this case, the merge modifier comes under the larger brief of non-destructive modelling, with Nodes being at the top of the list in complexity and reward, but other stuff too would be on there lower on the list that may be manageable or worthwhile in the interim.

Arf my post broke, so I add a screen.

4 Likes

No since that doesn’t force anyone to do anything.
There’s a difference between wanting and being able.
Since when the BF is forced to do what they don’t want? I’m god, I can force them to do what I want?

Why are you still on that instead of trying to improve blender?
Did you read my posts at least?
this merge modifier is a 10 years request.

Delete Button was just an example my request was about exposing many modal-operators hotkeys that are still hard coded, I am left handed and i have to change 90% of Blender’s keymap whenever there is a big change like it happened with the 2.80 and the Input editor is not user friendly, so u can imagine the pain in the ass to do that all the time with the many modes & options that blender has, this is very important for left handed users but since we’re a small percentage we’re always marginalized and our requests ignored, this is very crucial for our work luckily i got the patience to do it but i would prefer a better solution than wasting precious time in the Input Editor so it’s more critical than just a new modifier.

Yes, we should be able to edit every hotkeys indeed.
It just seems to be a hard and long work. Ton talked about that on the code quest if I recall.

Of course I read it, how else am I supposed to catch one of the last sentences. It baffles me how quickly you can switch your mindset from a “the developers are not listening” mindset to “let’s work constructively with them”.

There is a “Blender UI paper cuts” thread where people can discuss and suggest small UI adjustments. Something similar might be imaginable for broken workflows. Though, it is highly likely that those threads explode and they for sure need to be heavily moderated.

Regarding a previous question with working closer with the developers on modifiers. That is literally happening for particle nodes and it is highly likely that the same happens for modifiers as well: Particle Nodes UI

This is great, let’s do this to improve current modifiers then!
And I know those posts I participe too since the beginning :wink:

The current modifiers are not on their roadmap as you know. Why should they work on them?

Why not, it’s an important part of blender.
You can see all the people who posted there and on the petition you dislike so much and also on RCS (more the 200 votes).

Not because you have your own conception on how things should be done, that everyone is agree with you.
Same for me.
They said they will improve them, why continuing arguing about all of that?
Get over it.

1 Like