While it is late in the beta process to change functionality, I am interested to have feedback on the new Bevel Node that is in the 5.2 LTS beta. It is possible that if I don’t do something specifically for 5.2, I could consider changes in 5.3.
Documentation:
Design Issue:
PR:
(Note in particular the bevnode_egs.blend in that PR that shows how to achieve some effects that the modifier has that are not built into the geometry node.)
Two questions of current interest to me:
Should there be a separate mechanism built into the node itself to cater to the very common case of totally uniform edge bevel amount (there’s a suggestion from W_Cloud at the end of the PR discussion).
Should loop slide be exposed as an explicit option, or removed completely, or use the current proposed mechanism of having “different offset values → loop slide on; all same offset values → loop slide off”. See https://projects.blender.org/blender/blender/pulls/159708
Sounds like it would be better to create built-in geometry nodes assets for this. Maybe it should be an asset that can also be used as a modifier directly.
As a geometry node, it will be expected to use an attribute to control the offset.
For edges method, it will seem logical for user to create an attribute stored in edge domain.
Bevel Weight and Vertex Groups will be first intuition of a newbie.
Indeed, one socket to plug the attribute field would be welcomed, for ease of use.
If the ability to control offset by a field is supported, that seems logical to support Loop Slide.
Well, I’m not a big fan of adding an asset for that. Because then we’ll get two bevel nodes that are basically doing the same things with little differences. It’s not the first time I’m advocating against solving problems this way and adding nodes with similar functionality : That may make sense from a developer/code perspective but IMO not a lot from an user standpoint.
It kinda break the idea that nodes are low level/generic functionality and groups a more high level / focused functionality. But both should be unique feature without duplicates, these basic operations like bevel or merge should be a no brainer and they shouldn’t need to plug different nodes or relies on groups.
However I agree that ultimately we may want to replace the actual modifier, but maybe that should be two different problems.
I think by default the node should be able to do the most simple and common operation in an efficient way. Having to plug a value node 4 times doesn’t seems very elegant.
I suggest that there would be different modes for the node, like maybe “edges uniform” and “edges variable” instead of just edges.
Anyway, super cool to see bevel node in blender ! I’ll take time to really test it and report here if needed ! Thanks a lot Howard , modeling with geometry nodes is going to be so much simpler and greater !
I wasn’t necessarily suggesting to have a built-in asset only to add a uniform bevel offset. I think the asset would do more than that. Like having different bevel modes, etc.
Yes, I understand ! anyway having Bevel node, and Bevel++ node group doesn’t feels right to me.
But maybe this is where we hit a design issue. Having basic low level nodes for instancing and array nodegroup fit perfectly. In this case, I’m not so sure…
In any case I think the most common case would be regular , simple mode. Having support for this advanced mode (which I’m not sure even the modifier allows) is great , definitely, but the default should be IMO a simple mode easy to operate especially if we want to open GN to less technically versed artists.
Maybe we are both right in our own views : the bevel node should allow simple and common bevel by default because this is what we need most of the time. In addition to that, having a group with more functionalities that can act as a modifier is going to be needed anyway…
I don’t think there’s any particular reason that the builtin node has to be the “simple, common default”. A node group is just as capable of that task, and the other target of a modifier node group with more functionality should be simple to use and clear by default anyway, so those aren’t diverging goals.
I would rather see a clear hierarchy of abstraction levels, where the lowest level deals with raw location/offset data, generally hides fewer of the details, and makes fewer arbitrary choices, with user-friendly systems built on top of that.
I think the main issue right now is that we’re not solving both of these use cases at the same time. But that’s not really that new for Geometry Nodes. There is also the problem of high-level vs. low-level naming and visibility though, that’s probably something that will have to be solved.
I totally understand the hierarchy of abstraction levels principle and on the overall it’s great. However I think in some cases we may consider bending that rule a bit to make the overall system simpler to use. Maybe some nodes can have two modes (simple /advanced) ? it’s probably going to mess with the code but for users this can help a lot.
I also understand and like the use of more advanced nodegroups, in case like extrude (builtin) and solidify (nodegroup) this makes sense because while being similar it’s two different operations. But when it’s about having two nodes for the same operation that doesn’t sounds right to me. Especially when it’s something very common like here.
What would be the point of the built-in bevel node if there is a nodegroup that is better for simpler case and add more functionalities on top of it ? Sounds like a once in a lifetime use case then… But when looking for a bevel operation we’ll always have two entry and one of them is going to be useless in many cases…
Anyway, I don’t want to sound like a broken record, maybe I’m the only one bothered and in that case it’s fine Or maybe in that particular case we definitely need a nodegroup since bevel is complex…
I think anyway that adding a nodegroup should be considered as a last resort option rather than the default way to solve an UX design problem. Especially in simple operations like here that are already low level from an user standpoint.
I just arrived so let me know if I am missing anything : my understanding is that keeping nodes more generic makes them applicable to any use case, including if you want to determine the bevel offset value per individual edge through some arbitrary combination of conditions.
Stating the pros and cons I am seeing, for my own mind clarity :
If a “commonly used, more straightforward” case of the bevel operation (such as equal offsets everywhere, or a percentage of the neighbouring edge, etc) can be achieved using a nodegroup, it makes that change available for inspection, and that seems like an instructional added value for the user, compared to the scenario where that change is baked into the bevel node.
If the only downside is there will be several “bevel mesh” nodes that need distinct names to communicate their special case, I think I would be fine with that. It can be called “Bevel standard”, “Simple bevel“ or “The less opinionated bevel”
I completely forgot bevel weight existed. I suppose it is meant to go away in favor of generic edge attributes ? or maybe it is already stored as such ?
I completely forgot bevel weight existed. I suppose it is meant to go away in favor of generic edge attributes ? or maybe it is already stored as such ?
In geo nodes it already looks like a generic attribute. The main reason it still feels “special” is that the editing UI lets you set it in several specific ways, not just the generic attribute-setting way. But you could use any named attribute for selection. Similar things could be said about for Vertex Groups.
And it case it isn’t clear to everyone, once there is an attribute such as bevel_edge_weight, it is very easy to use that attribute to generate a selection condition that gets fed into the Selection input of the bevel node, to pick which edges will be beveled. If one wants to use differing weights to achieve different bevels widths, it is equally easy to use that attribute in a calculation to set the Offset fields.
Indeed this should still be accessible, it’s great to have ! Just the node could have a few options for more or less advanced cases and would default to the some common and easy to use use case…
Instead of having several bevel nodes, we could have one builtin that would covers most common user cases, and still allows more advanced complex and exotic setups.
Since it looks I’m the only one bothered by that situation I’m assuming I’m missing something and I should probably let it go On the overall I agree that it’s not a big deal either, just maybe not the most elegant way to solve a design problem IMO, and while being amazingly cool, I think GN tend to miss a bit the fast and simple workflow that is common to blender, especially when it’s about very basic/common operations… this might be worth considering as a global design challenge.
GN is very powerful in the way that all these low level operations can be combined in many different ways. The downside is that to make a basic/regular operation you generally need to plug several nodes. The solution to that is nodegroups, but it tends to duplicate functionalities adding more nodes to pick from and to manage. But maybe it’s possible to have more versatile builtin nodes with different modes , with the most common operation by default for fast workflow and less tech savvy users. And an advanced workflow for slower but custom setup, where adding more nodes would be mandatory… It’s probably more important to me as I’m generally working mostly in the node editor, for months, with many groups to manage. But I guess this might also impact beginners and less tech artists…
Alright, now I’ll let the discussion be and I’ll discuss other matters if needed !
If I understood it clearly, yes i would love to have the node editable as a node group. The more editability the better, independently whether or not the group is going to be anchored in the modifiers options. Houdini makes a lot of nodes editable it is quite awesome to have that possibility.
While I don’t think this is a good idea on a node level, I could see the use on a menu/search level. Some way to declutter the search popup and the node add menu would be necessary with the growing list of available nodes, and I could see an basic/advanced toggle as part of that.
For example setting the ‘available nodes’ to ‘basic’ you would get only the userfriendly bevel nodegroup, while setting it to ‘advanced’ would show both.
It would need some good designing though, because it is not really trivial to decide which nodes to hide in basic view.
Most users working with nodes are fairly advanced already, so I don’t think such a filter would be needed. I think it’s more important that there’s a good version of a node group for a modifier. We already have a checkbox to only show specific node groups as modifiers.
Maybe it makes sense to have a Simple Bevel node group. Basically as a shortcut wrapper for people using nodes. Or even better: Use the node group for the bevel modifier.
Adding a mode to an internal node is not great because it’s more code to maintain, more code that can break, etc.
: the bevel node should allow simple and common bevel by default because this is what we need most of the time. In addition to that, having a group with more functionalities that can act as a modifier is going to be needed anyway…