Mesh Fushion, Bevel Boolean, fuse.... ¿Blender solution?

I’m talking that a programmer will make this, not use the bevel modifier after the boolean. Make a boolean modifier that made all the process.

Per boolean that can breat indeed but i’m sure they will tell you it’s not to the boolean job to do this.
With modifiers as nodes that can be handled with the bevel modifier.

  1. Currently to my understanding bevel op is common both to edit mesh as well as modifier automatically being called. It is vital and cannot be replaced, just improved. Bevel Modifier on the other hand could give a choice to user between 2 procedures as mentioned in prior post. There are times when you need clean bevel, there are times when you don’t care and need big smooth rims.

  2. Regarding pitiwazous concern and as DcVertice has commented before in Houdini related reply, I think it would also be a good idea if certain modifiers would give you options to autocreate Vgroups that could then be used by other modifiers (e.g Boolean creating “seams” vgroup). You can see example here, but realistically we just need 1:

  1. About mesh fusion, I don’t think that improve boolean or bevel will be a solution. We need a new modifier that accept multiple booleans operators, with her own stack inside, and each new operator have the options necessary to custom the solution. Like hard mesh in maya or flux in houdini.

  2. It will be so easy to make that I really don’t understand why don’t ask to some coder :slight_smile:

You might be underestimating the task here. Modifying boolean to create Vgroup is probably a 10liner. I poked around in that part of code and they are marked for welding there, could be marked for Vgroup in same area. I might be wrong of course. I don’t know if any other modifiers create Vgroups dynamically and if there would be any problems as a result.

As Vgroup it would play well with every single Modifier and is within same ecosystem. For example imagine Boolean (marked Vgroup) -> Bevel (wide rim, vgroup) -> Displace width Welds texture. If you work with game assets you know that every 3rd or so has them. Practical.

On the other hand make a whole new modifier is massive task, even though the hard-mesh example implies such an operator should at very least be created, regardless where it is called.

Tl;dr: Let’s not undermine work involved, developers are overwhelmed as it is and if we’re lucky to even appear on their radar, ideas expressed should be practical and manageable. That is given that they even see these examples in all the chatter.

I don’t undermine the work in the first case, hard edges/mesh fusion, but it’s the only solution to have this tool. We can not talk about other solution, the rest of solutions are bad solutions. And to don’t broke the compatibility you need to make a new modifier that make booleans and bevel.

Maybe I’m not clear. But with “easy solution” I only talk about add the vertex group output to the boolean operator. Not about the rest of things that we talk.

I’m talking of three different tools

-vertex groups in boolean operator

  • Round shader
  • mesh fusion like solution

I think that the first must be easy to create, the second more complex but easy for a programmer with cycles experience, and the third is a really hard work.

MeshFusion is a great example. Interestingly masters such as Tor Frick generally avoid it. Why? It’s an ecosystem within an ecosystem, an integrated plugin that is difficult to bind with all other modeling that needs to happen. This is a dead end also with respect to maintenance and overhead. I highly doubt there is such development resource available. Best we can hope is small, smart addition and a tweak here or there (e.g vgroups). If topic were to kickstarted I would certainly back it.

For that reason y prefer to talk about the flux from houdini, i think that it is a better solution and permit work with more tools before and after

I’m afraid the only way to have such functionality (in a proper and non-specific manner) would be if we had a developer code a sort of “edit mode lite” modifier that you can place at various points in the stack (what I mean by that is that you would be able to modify things like vertex positions, vertex groups, vertex colors, edge tags, ect… while keeping everything nice and predictable).

I wouldn’t count on seeing that anytime soon barring a surprise though, I would think it would require some involved changes in the code (and yes, that would even be without such a thing as being able to do geometry changes in the modified mesh).

i must disagree and tell that it’s a eird solution and complex.

@DC. I repost hardmesh Example. I think this is fastest operator to create and invoke from Bevel with alternate selection:

Booleans could create vgroups:

  • boolean_A
  • boolean_B

Bevels that come after boolean could use the Vgroup:

  • Bevel1: boolean_A(vertexGroup) -> width 10 units
  • Bevel2: boolean_B(vertexGroup) -> width 5 units

Nothing simpler. Micromanaging is overkill even though already you could use DataTransfer modifier to tweak the values.

Edit: Potentially Booleans should transfer Vgroup data. So if one of your Meshes has VGroup A with value 0.5 and other 1.0 then you could just use 1 Bevel

I have a reasonable good mesh_fusion like solution where I invoke Houdini VDB ops from within Blender and get result within seconds. Not live but input is 100% editable, just end result that takes a few seconds to calc gets the rounded corners treatment.

Here’s a link to VDB boolean magic:


hardmesh and houdini flux are really similar

I was talking of a modfier like this

would this help? [I did a quick try at this a while ago… – unfortunately I dont have much time atm., but maybe someone can build ontop of this…]
basically you can assign bevel weights for ‘new’ edges of a bmesh boolean modifier with this patch [which can then be used when setting the bevel modifier to use bevel weights]

It’s a good idea, the problem with this solution is that you cannot have different bevel from different booleans operations, like with vertex groups. And put a “bevel weight” it is not necessary because when you add the bevel modifier you select the radius of the bevel.

But the edge crease feature I think that can be useful.

I think his patch is good, you can use the bool object with bevels and the contour of the bevel will be edited via the boolean modifier width bevel edge like he did.

With this with the second bevel and the bevel weight on the boolean object you can have different size for different boobleans.

But the bevel will depend allways from the bevel size. If you want to make a bevel with more radius you must change the bevels of all object and change all bevel weights to obtain the same size. It will be a weird workflow that confuse people.

bevel width depends on bevel weight:

Do you have a windows build to try it ?

Yeah, but imagine that you have a bevel size of 1. All bevels in the objects will depend of that value, with bevel weight you only can make bevel between 0 and 1. Then you see that you need a bevel of 1.3 in some part of model. If you pick the bevel modifier and give a 1.3 value you will change all values of the bevels of all object and you will need to change all bevel weights in all boolean operators.

And for example, other problem. You must need in some boolean result a bevel of 10 subdivisions, when the rest of the object only need 3 subdivision. If you put 10 subdivisions in all bevels of the object the perfomance will be bad.

And the same for example for other profile. Clamps and materials.