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
How far off is the everything nodes project realistically?
Merge modifier would be extremely useful for non-destructive workflows. Personally would have loved to have this when I was working for a project and doing concept/massing work for them, would have saved lot of time instead of manual cleaning on boolean left artifacts.
please add.
3 Likes
Another example where we need merge modifier.
This is 100% editable.
To close the hole on the spring, I can add a solidify and a merge modifier.
If I have the merge modifier I can merge the middle point and I can say that my object is fully editable and the wire isperfect, just have to apply when it’s validated.
If I don’t have the merge modifier, I will have to apply, close the holes, check for validation.
If not validated I’ll have to delete it, come back on my backup, make my modifications, check for validation etc etc.
You can understand the struggle and it’s only on simple example.
The merge modifier would have saved me a lot of time!
5 Likes
Think that blender foundation predictions are not so good. Blender2.80 had to be finished by October 2018 according to the first plannings, and finished at the end of summer 2019… so if developers talk about everythings node like a long-term planning, maybe 3-4 years at least, maybe more. With the new money from Epic maybe the development is faster
I also second the proposal for the Merge/Weld/Remove Doubles modifier or extending DECIMATE with such option (safe middle ground?). It was the most improtant modifier I missed from 3dsmaxs day which in frustration forced me to see if I can do something about it in code. Perhaps interestingly after days and days of pulling hair out in despair, I mailed Campbell and he gave me very valuable pointers including how to call the BMO_ operator to run remove_doubles with just a few lines. To this day I am very grateful for all the tips!
It resulted in the build shared above, which I hoped would demonstrate some of these aspects (e.g triangulate ngeons, welder, scale UVs modifier, displace modifier on curves etc).
For example when working with game models that are critically reviewed and scrutinized, it’s very important to have clean topology ( no ngeons, doubles, good weighted normals ). This usually translates in modifier stack ending with …>Welder > Triangulate Ngeons > Weighted normals. This was not possible in 2.79, which is why I had a build. In 2.8 only the welder is missing. If for whatever reason remove_doubles is needed before Weighted normals, then that stack is useless and each of these steps needs to be applied manually. As there are usually several feedback iterations, you can imagine how annoying that gets.
For highpoly assets it’s hard to imagine a scene which weighs less than 500MB (just open any Zbrush file). My scenes are usually 500-3GB with modifiers. Without modifiers you could safely multiply that number 2-4 times. This is why using modifiers and creating these procedural stacks makes so much sense as greater complexity can be reached, managed. After all houdini files are usually around 1MB each. Needless to say our Global Undo becomes unusable at 500-1GB range.
Artists are creative and just need the functionality however slow or inefficient. They will find infinite ways to combine these building blocks. What is needed is someone like Wazou sitting on developers lap for a week or offering backrubs while sharing ideas of envisioned use. If you look at the evolution of modifiers in past few years (e.g triangulate ngeons or screw with merge threshold, mirror updates) - these updates seem not that massive and just needed artists point of view. There are others like inverted vgroups per modifier(some have) or having UV_WARP support UV scaling (including for curves), having font on curve follow tilt, inset extrude… just from top of my head. Add to it the new OpenVDB Remesher (+vdb import please) and we could skip 2.82 release and just go to 2.84 as far as modeling is concerned. I would not hold my breath for everything Nodes and would much rather have a slow option under Decimate, even if it gets depreciated with time.
8 Likes
True.
Let us have more flexibility with addons and a lot of users will find solutions to their problems instead of always asking for new features directly here.
Look at the tissue addon… it’s a shame that it’s still not a modifier…
I think that the concept of open source here is not really « respected »… In a way yes we can modify blender as we want and it’s cool but nobody will use a separate version of blender and a few peoples can do that.
Open source would also mean more possibilities for plugins… a lot more… not only for ideas approved by the blender devs. It’s kind of hypocritical that blender is called open but is so close minded on principles and is not giving more liberty to its users. Even 3ds max give more liberty to its plugins creators… c’mon…
Let us free and no one will be begging for features like hobos again.
I really think that the problem is not that « there isn’t a merge modifier » the problem is that we cannot use plugins to do that or any other important demand ourselves.
10 Likes