We scripted something to avoid being limited by the bevel weigt to 1 on speedflow, that works really nice !
In fact, on the boolean modifier, it’s not like this that should work, but on the contour of the boolean because we can already add bevel modifier on the bool object.
like on my previous gif.
you can do different bevels in the stack like this:
only difference between the two is that you have to disable “Store Edge Bevel Weight” in Properties>MeshData>Geometry Data for the later…
@pitiwazou
But the idea is make something that work for all blender users, with blender standard behaviour and design, not with your script. I think that if we propose something is something that work for all people that use blender, a solution for all general cases.
@2d23d
It’s a better solution, but I think that broke the basic design idea of “keep it simple” and It could confuse the users. But It’s true that it give us the similar result.
But it broke the compatibility with other workflows like “hard ops” and don’t permit to the user to have bevel weights in the base mesh.
A question 2d23d, do you think that it’s hard to code the vertex group output for the modifier?
Of course, you said it was an issue, but if devs fix it, it will not be anymore, it’s possible since we did it ^^
For the work of 2d23d it’s great, like I did, instead of using the bevel on the bool object, that should add bevel weight on the contour.
Like that we could add different size for different booleans.
I understand your point of view, but I don’t want to make a proposal that break the rest of users pipeline and change the behaviour of blender. Make a vertex group output don’t break nothing, give us more possibilities and make a pipeline compatible with other addons like your addon, hard ops,… and keep a really simple options and workflow.
Yes, bevel works well when subtracting a cube from a cube. But, Bevel does not work well for a more complex geometry.
We need something similar to the CAD program, which invade chamfers and fillets to geometry, without paying attention to topology, and build the correct bevels despite everything.
In fact, to fit a good workflow, I think we need two things :
1 - This patch for boolean modifiers, but only for the contour of the bool to add a bevel with different sizes.
2 - make the bevel modifier better with the possibilty to weld vertices to avoid artefacts.
And the result will be like hard-mesh ^^
Well, we could propose the option to have the vertexgroup contain the intersect loop or all new vertex
the welder could be good, but it modified the bevel modifier, not the boolean, and could be other proposal.
The bevel modifier needs a welder option and you don’t need to modify the boolean to have a bevel on it.
regarding vertex group output: should be doable, can look into this, might take a little while though due to time constraints…
Not sure vertex group is the way to go since when you add another boolean, all the vertex are changed.
We must see if the vertex group is interactive. Like bevel weight, and could be different in each modifier of the stack.
All this talk about how to get complex booleans with bevel working gives a textbook case as to why the modifier system needs to be moved from being stack-based to node-based.
If it is done like the node system in Cycles (ie. having a specific I/O socket type for the derived mesh data and maybe also for vertex groups), it should actually make it easier to manage real complex setups.
YEah, it’s true, but in the other hand a node system for all is more complex for new users. Anyway, we need to wait to “everything node” revolution in blender, that I know it won’t be in few time.
I very respectfully disagree. While I love modeling with Houdini, it’s really 10x slower to use nodes than modifiers that are essentially superset of nodes. Nodes do have their part, perhaps in defining new type of functionality/modifiers by offering simplified User interface, hiding complex procedures. Think of MCG (3ds) where you use nodes to create modifiers - that’s what it’s about ( except MCG is vanilla ). We’re artists, we do not need to micromanage every part + features as such do not need to be dismissed until 2020 when nodes might happen or not.
@2d23d - Thank you very kindly. Here’s win build for anyone: http://cgstrive.com/blend/2d23d_Boolean_Mod.rar
Note: Appears that it breaks if you use multiple booleans and then bevel. Last boolean overrides the weight of first?
I’m not advocating for an ultra low-level system here, the idea would be that all of the existing modifiers would still exist as-is but in node form (with inputs and outputs for the derived mesh, external objects, vertex groups, textures, values, ect…). You wouldn’t have to mess with any complex math or matrix calculations if you don’t want to (so it will be faster and easier than the same with Houdini and Max).
The point being made is that stacks can get very complex when you really start adding options for more meticulous control, look at Cinema 4D for example (known for largely avoiding nodes altogether) and how complex parts of its UI has become as a result of said avoidance while adding tons of new options (this observance is based on videos, I don’t use it myself). Also look at the complex boolean trees in the Mesh Fusion demos from Luxology, you could easily create an unwieldy situation if your stack started involving dozens of objects.
Though as a compromise, one could perhaps have both approaches in Blender by adding a special ‘node tree’ modifier which could allow a node setup to slot into the stack (it would work as long as the tree starts from an derived-mesh input node and ends at an output node).
Actually nodes for modifier don’t have any reason because the modifier still having a stack concept and features. Houdini have a node system, but houdini have hundreds of nodes.
Derived mesh output data could be used as input data for any other modifier ahead of it (along with the mesh output going through its own modifiers before reaching the socket).
I don’t know where you get the idea of hundreds of node types, my proposal would not involve that many (at the least, you would have all of the current modifiers as a node type and standard nodes like texture, object (for bringing in external objects as inputs for modifiers), and mesh data (the last one being where you get vertex colors and groups).
I understand you, but I tell that node system actually only could improve the order if you have many nodes, but not the utility.
Do you know some news about everything node in blender?
