Yeah, it's a very common scenario when dealing with engineers/developers - user reports a serious problem using the bug tracker because it really is the only way to report anything ... developer rightfully states that "it's not a bug" because it actually is a design issue ... and said design issue ends up in limbo and never gets addressed.
One way around that would be for the bug ticket to only be closed once a product or UX guy acknowledges the issue and creates a ticket for it ... but that's something they probably won't want to do anyway because that'd be admitting their own bad design
Anyways - If you ever need more ammo on this (footage showing the issue, and so on), count me in. I completely forgot about it myself because I fixed it in my keymap manually months ago, but this default sluggishness is something that new users shouldn't have to deal with.
I've just had a look on blender for this but it doesn't seem sluggish? It feels similar to 3ds max but that might be because i've set it to industry standard? I dont know if that makes a difference or not?
I hadn't realised the last page wasn't selected and this from you dude. " the setting has been changed by whoever is in charge of the keymap .."
@MrNinjutsu : by that I meant that someone proactively changed that setting sometime between 2.79 and the 2.8 beta, leading to 2.8 feeling sluggish. Now on my end I've since fixed it in my own keymap which I then port over to new versions (2.8 Release, 2.81, and so on) so I cannot really tell if this setting is still broken (so to speak) by default now without investigating further by removing my preferences and redownloading the software. But as you pointed out it may very well be different between some of the provided presets anyways (Maya style, Max style ...).
To test it out : when in object or in component mode, do a mouse click selection. If the selection is confirmed (gets highlighted/turns yellow) when you press down, it's the super snappy 2.79 behavior - basically the program reacting instantly to your inputs. But if the selection is confirmed when you let go of the mouse button press, then this is indeed sluggish behavior and imho not acceptable. It may not be noticeable to new users starting out, but when going fast it definitely cause issues and is just not feeling responsive overall. It becomes especially noticeable when doing multiselections (and no, using marquee selections to avoid this scenario is not a "fix" for this issue )
Using box selections might not be a fix, but try using circle select with a really small radius. I can't test it right now, but I would be surprised if that only selects on mouse up.
Edit: In fact it shouldn't, otherwise click-drag selects would not be possible.
Hehe of course Circle Select is not a fix either The point of these comments (and the bug report mentioned above) is not to find workarounds to avoid a problem - the point is to highlight an issue that makes the app feel sluggish even for the most basic operation, and to make some noise one way or another so that knowledge of the issue spreads - both from an altruistic perspective (it's in everyones interest to have tools behaving as smoothly as possible) and/or also to help development (if this reaches the ears of someone in charge it may change things for the better). Otherwise we end up in Apple Fanboy territory ("oh nah, you don't need that feature you say you need, trust us, Steve Jobs thought about it")
And as said : selection validation on clickdown is absolutely *not* incompatible with drag box selection. Try it on your desktop icons, you'll see
I haven't been using 2.8 much yet, but thanks to the information here I finally know why it felt different I usually used the standard "Select"-tool which selects on "press", but once you add a selection using Shift-key it selects on "click", feels strange. I don't see any issues so far changing everything to "press" and using tools that require "drag", I don't quite understand the design decision.
I mean sure if you feel you need it, sure go make some posts. I just don't feel the need because I work differently.
Being somewhat active in open source in general, not just Blender, I just don't like how some people are starting to move to hostilities because others either don't understand them or have a different opinion concerning this issue.
This has absolutely nothing to do with hostility - this is a very clear UX design oversight, no doubt happening because of how massive of an undertaking 2.8 was. The fact that it doesn't affect some users is completely irrelevant ... This is not about a preference, this is about making a piece of software as smooth as it can be (or in this case keeping it the way it has been, as opposed to making it worse). In other words, aiming for excellence as opposed to going got for the lowest common denominator of "oh that seems fine". It's the good old horse carriages VS Ford cars thing
The altruistic position is to care, and to confident in one's observations - even if it means ruffling some feathers. Well, to an extent of course Ironically, the most toxic/pointless comments in the original bug report are the ones dismissing the issue ...
I mean sure if you feel you need it, sure go make some posts. I just don't feel the need because I work differently.
Being somewhat active in open source in general, not just Blender, I just don't like how some people are starting to move to hostilities because others either don't understand them or have a different opinion concerning this issue.
When you start getting industry professionals using and interested in a piece of software on a large scale like what happened with the drop of 2.8 you start to get people that know a lot more about what they are talking about. This is especially true when those people have dealt with several different softwares for years and have worked with them professionally everyday for years just two cents.
Indeed - so it's a good thing that absolutely no one did that.
Anyways, moving on. A great little video about the new sculpting/masking/remeshing features in 2.82. Not only is it catching up with ZB features-wise on that front, it now seems to be objectively better at it thanks to the very straightforward implementation of these features. Great looking stuff.
To test it out : when in object or in component mode, do a mouse click selection. If the selection is confirmed (gets highlighted/turns yellow) when you press down, it's the super snappy 2.79 behavior - basically the program reacting instantly to your inputs. But if the selection is confirmed when you let go of the mouse button press, then this is indeed sluggish behavior and imho not acceptable. It may not be noticeable to new users starting out, but when going fast it definitely cause issues and is just not feeling responsive overall. It becomes especially noticeable when doing multiselections (and no, using marquee selections to avoid this scenario is not a "fix" for this issue )
Ah I see, well I've just tried it out and it's not the snappy behaviour of 2.79. It feels okay to me. However, that being said, i just tested 3ds max out and it selects the object whilst the press is down which is different to blenders default which as you said, is on release. I can see what you're describing now. Max does feel a touch snappier in selecting.
Cannot unsee.
Sculpting I'm pretty keen to have a go of the sculpting side of Blender, a lot of my work I have to use Zbrush for details, and if I can use blender just as effectively, then it's gonna be a no brainer to simplify my workflow.
@MrNinjutsu : yup, that's it ! And I find it fascinating that even just a GIF manages to show it. Can't unsee indeed So yeah for a few weeks/months I thought this was some sort of bug with either the program or the graphics card. That's why I sincerely think it'is a shame that any person interested in Blenderino because of the new 2.8 features will have to suffer through that.
On sculpting : the 2.82 features are really good - especially the slice from mask and the extract with built-in solidify modifier. Objectively better than Zbrush in that regard.
However ... the flatten brush really is busted at this time, it does't seem to flatten at all but rather raises/lowers the surface in a weird way. So if flatten is a big part of your workflow it'll be a problem unfortunately.
@pior I'm curious. Regarding your keymap changes for selection, do you have any conflicting behavior with drag-select or tweak? Because I seem to recall that that was the entire motivation with changing from select-on-press to select-on-release when migrating the over to the left-click select control scheme. If that is a non-issue, I would certainly support making some noise over in the developer forum. I noticed the laggy selection immediately when switching over to 2.8, and definitely missed the snappy selection from previous versions.
Well as said, the best proof of concept is to just play with your desktop icons
No conflicts on my end - that said I do tend to disable stuff I don't need as I am not a "gotta use the defaults" kind of guy. But drag rectangle select is absolutely not incompatible with it that's for sure.
Yeah, spent a minute searching through the developer forum, and it looks like Brecht - who is Blender's chief architect - might be the guy who made this decision way back in 2018. Looks like our very own @MACHIN3 even made some noise about it at the time, to which Brecht's response referred to subtle conflicting behavior with various tool interaction without going into much more detail. Not much else came of it until relatively recently, when the topic was raised in this thread:
However, the devs consider this intended behavior, and will not be treating it as a bug but a design issue (which I think is understandable from their perspective). The best way to get it changed may be to keep the dialog open in the developer forum.
William Reynish (UI/UX) is the main one for keymaps (though he noticed the post anyway).
Rather than explaining, it might be easier to just make a working prototype that shows how it should work, and then have William try it. If it's better without any other issues, he'll almost certainly accept it.
I looked a bit harder to find issues with other tools when changing selection to "press" and quickly found some. When using "Select Box" or "Select Lasso" with Shift or Ctrl it is possible to select/deselect elements outside of the actual selection area.
This issues were not obvious to me, because coming from previous Blender versions I always use "B" hotkey for box selection. A solution could be to disable the normal selection when this tools are active, make them more behave like the hotkey version, but this would probably lead to some workflow issues for other users.
I think the devs are aware of the situation and will hopefully find some way to improve it. For now I can configure it the way I need it and I'm happy.
It's an obvious issue for those who have worked as veterans in other software. Blender has improved massively, which is why it's seriously motivated me to make the switch, and i think small changes like this, that we're accustomed to, will help seasoned artists make the switch sooner.
I like using Vertex Groups and the Decimate modifier, but I have to do the masking job (it's also a very nice feature! picking where you keep the detail geo), as it decimates everything - where Decimation Master in zbrush would do it smart and keep geo where you need it silhouette-wise etc. (it does, right?)
On my end I am not running into such issues, but I went through this adjustment of settings a little while ago and cannot recall in detail what changes I had to do to make it work, if any. But as a proof of concept I can confirm that it is possible to make it all work without conflicts with box selection, simply because that's what I've been using for months now
(and it goes without saying that I am using click-drag for box select here)
If anything, if the behavior change was indeed caused by the introduction of another feature (new box select input), then the situation is all the more worrisome becomes that means that it's not just an oversight but an actual proactive decision. Hopefully they'll come to their senses eventually. The sad thing is that this is imho an evidence of a negative shift in focus (adding new features at the expense of existing delicate systems. And sprinkled with a pinch of design by committee). Oh well.
Welcome to Blender development. It has always been that way, for many years. Guess why i started the fork
The imho bigger problem before they can fix anything here is that they have two contradicting tool systems now. The old one, called with the hotkey and from the text menus. And the new one, in the tool shelf. Means you have for example two box selection tools now that does the same. Just a bit different. But it works for them, and so i don't see them fix this issue.
Here's something I've been wondering about for a while :
Is there a way to convert an annotation (blue line, not GreasePencil) to mesh geometry ? Just the edges, no thickness. I understand that there is a path to go from GreasePencil to geometry, but the 2.8 grease pencil has way too many features/effects getting in the way of quick sketching on surfaces (also very annoying default look presets). Being able to retrieve edge data directly from quick annotations would be great - the data has to be somewhere ...
On my end I am not running into such issues, but I went through this adjustment of settings a little while ago and cannot recall in detail what changes I had to do to make it work, if any. But as a proof of concept I can confirm that it is possible to make it all work without conflicts with box selection, simply because that's what I've been using for months now
@Prime8 Ha, unfortunately I can't recall from the top of my head if I had to do anything special, especially since it's a keymap I've been tweaking/refining for a while. I am not even sure what these entries are called. What are these called in the keymap list ?
@xrg Hmmm that's odd, can't seem to see anything like that in 2.8, 2.81 or 2.82. Would you mind elaborating a bit ?
I do see a "Convert Grease Pencil" command in the search, which *does* seem to act on the blue annotations ... even creating an actual GP scene object with contents of the same name as the original annotation ... but nothing seems to come out of it. Odd.
What would you guys/gals say are essential plugins/addons for blender for game production assets? I've got a collection already i.e boxcutter/hardOps which i LOVE but is there anything i ought to be aware of?
Entirely depends on where your focus is. For me it's Hair Tool. For more technical work Decal Machine looks like a must have. Another must have in my opinion is the Pie Menu Editor. I would have never made the switch to Blender without it and probably gone with Modo instead. That addon has a particularly responsive developer, too.
@xrg : would you mind recording a gif of that, showing the beginning (annotation) and end result (curve) ? Also would love to know the exact version number, as it doesn't seem to show up here on the 2.82 beta from just last week.
Entirely depends on where your focus is. For me it's Hair Tool. For more technical work Decal Machine looks like a must have. Another must have in my opinion is the Pie Menu Editor. I would have never made the switch to Blender without it and probably gone with Modo instead. That addon has a particularly responsive developer, too.
I do a lot of hard surface work; weapons, vehicles and other random assets. I've seen decal machine but i wasn't sure if it was appropriate for baking etc?
Oh, here we go:
Would LOVE to see it in action for game ready assets.
@MrNinjutsu : Well, it just works. You can lay down decals at the highpoly stage (thus avoiding the unnecessary modeling of any small details) ; but it is also possible to add such details after a game asset has already been completed. In both cases you end up with two sources : a regular high (or a previously athored game asset), and a bunch of floating geo bits each calling their decal material. Blender bakes thats down perfectly fine. I believe the next versions of DM will have texture atlasing, which will allow you to bake that stuff in other bakers without having to pass dozens of tiny decal sources. But as said, the Blender baker can handle that just fine, and you only really need the normals and diffuse anyways, it's quite straightforward.
Now it is also possible to work in other ways, like skipping the high altogether by working directly on the final ingame mesh+decals. This can work for some assets, especially on mechanical props/weapons/vehicules (like the examples coming with DecalMachine) but not all, as it does affect the look/style of the artwork quite a bit.
@pior Man, now i have to give it a try. Okay, well, Blender is such an exciting piece of software, can't wait to delve more into it. Thanks for all that info pior, you're the man!
How i can imagine myself using it is just after I've baked down the high poly, before texturing. So i can add in details i didn't want to model. Sounds really awesome actually.
I use toolbag 3 for my baking, will the tangents mess up through this workflow or are the tangents similar?
I don't think you'd be able to bake that stuff down in TB3 for two reasons : • If you use, say, 12 decals ... that would mean having to setup 12 materials in TB just to transfer that data, juggling with what you want to transfer, and so on. • Also, the question is what to even bake. Baking these decals down works flawlessly in Blender because it pulls directly from their unified materials with all their components (normalmap, height, ao, curvature, and so on). And then the bake just works from there in one click. That said this is only needed for the decal pass, so nothing prevents you from baking your high in your software of choice. Just not the decals.
@pior yeah it was more of a question as to whether blenders normal tangent match toolbags tangent so if I were to add the decal normals to the toolbag bake, would it cause any issues? I reckon that's a moot question though.
@MrNinjutsu Only problem with baking decals in toolbag is the ao, as it bleeds a bit arroud the decals edges (don't know if it does that too in blender). Everything elese works fine, i usually just export and hit bake. Marmoset feels like a blender tab a this point and i don't use any addon to export.
@pior Why would he need to create one material for each decal?
We're probably just not talking about the same thing. I am talking specifically about normal/depth-based DM decals each calling their own unique source textures (like the ones used in my examples : a tiny DM texture set for indentA, a tiny DM texture set for indentB, a tiny texture set for this or that bolt, and so on... ). Meaning that these would of course require one material for each in TB3. Also, TB3 can only bake down albedo from such pseudo highs (or anything fed into that slot of course), meaning that feeding the normalmap of a DM decal as albedo for transfer would not give a well-oriented normalmap texture (by oriented I mean, in the RGB sense).
The misunderstanding probably comes from the fact that what you mean by "decal" (stencil decals from an atlas source, I presume) is not the same as DM depth/normals/ao decals faking geometry. These can only baked down in Blender at this time. And even once DM can compile/export atlases it wouldn't work either regardless because TB3 can only transfer Albedo from pseudo highs anyways.
Ok @pior I am starting to understand your frustrations with "sluggish" controls. But I don't have a problem with the selection, but instead with the mode change in the tab key. That now is also on release. And if you happen to move the mouse while having it pressed, it opens a pie menu instead.
Well, by default the tab/mode toggle action actually *is* on press Maybe you changed it in the past ? But yeah regardless, the result is probably a similar feel. Hey, if anything that does spreads awareness
Might be that it was OnRelease before, but moving the mouse while keeping it pressed changing the behaviour is definitely new I think. They also did that with the Z key for the render modes.
On the subject of 3D texture painting inside Blender - is anybody using it for that proper?
At least 4K texture resolution- and UDIM support, performance that holds up with a few assets and texture-layers in the scene. Guided/lazy/smooth strokes, a paint engine with at least basic brush dynamics, stencils, stamps, clone tool and image projection/paint through, symmetrical paint-mirroring. Ideally ability to snap the brush to curves.
Most importantly: flawless handling of texture seams. Basically Mudbox' paint toolset is all I need but I'll gladly take that PBR viewport - am I looking at the right tool or would I be better off to finally investigate 3D coat (unfortunately the Doc said I tested allergic to Substance Painter, so that one's out).
@thomasp Blender has at least some basic functionality for texture painting that you could use. I might be missing one or two of the things you missed, but it costs nothing to try it.
@melviso If by that you mean procedural texture generators, Blender has those. Had those even before 2.8. There is no ready made generator for wood, but you can easily build one yourself with nodes. I built this myself for example:
@f1r3w4rr10r Nice work. Wood is the hardest to get right procedurally because of how unique its patterns are. I am yet to see really good looking wood patterns created with substance tbh. I am looking for how to do this in Blender: https://www.youtube.com/watch?v=FuPQNIx3dh8 Creating the textures are easy but how to randomly put them per uv tile is the issue. This is where Bercon tiles come in. Or this method: https://www.youtube.com/watch?v=SiBhArwW7YU Using Blender eevee. Is this possible with OSL shaders?
It is kind of similar but I wanted simpler workflow (fuse, refuse, unbeve, unfuse , change width - it was to complicated for me, and I could never remember which operator works with what kind of selection). In rebevel there is only alt+B and it can change all bevel properties (width, segments count or delete bevel by merging bevel verts). And it operates always on one type of selection - bevel ring edges (I added 'Loop Ring Select' addon to make it easy to grow, shrink, select range of rings/loops - this way selecting bevel should be fast).
Replies
I hadn't realised the last page wasn't selected and this from you dude. " the setting has been changed by whoever is in charge of the keymap .."
@MrNinjutsu : by that I meant that someone proactively changed that setting sometime between 2.79 and the 2.8 beta, leading to 2.8 feeling sluggish. Now on my end I've since fixed it in my own keymap which I then port over to new versions (2.8 Release, 2.81, and so on) so I cannot really tell if this setting is still broken (so to speak) by default now without investigating further by removing my preferences and redownloading the software. But as you pointed out it may very well be different between some of the provided presets anyways (Maya style, Max style ...).
To test it out : when in object or in component mode, do a mouse click selection. If the selection is confirmed (gets highlighted/turns yellow) when you press down, it's the super snappy 2.79 behavior - basically the program reacting instantly to your inputs. But if the selection is confirmed when you let go of the mouse button press, then this is indeed sluggish behavior and imho not acceptable. It may not be noticeable to new users starting out, but when going fast it definitely cause issues and is just not feeling responsive overall. It becomes especially noticeable when doing multiselections (and no, using marquee selections to avoid this scenario is not a "fix" for this issue
And as said : selection validation on clickdown is absolutely *not* incompatible with drag box selection. Try it on your desktop icons, you'll see
I don't see any issues so far changing everything to "press" and using tools that require "drag", I don't quite understand the design decision.
The altruistic position is to care, and to confident in one's observations - even if it means ruffling some feathers. Well, to an extent of course
When you start getting industry professionals using and interested in a piece of software on a large scale like what happened with the drop of 2.8 you start to get people that know a lot more about what they are talking about. This is especially true when those people have dealt with several different softwares for years and have worked with them professionally everyday for years just two cents.
Anyways, moving on. A great little video about the new sculpting/masking/remeshing features in 2.82. Not only is it catching up with ZB features-wise on that front, it now seems to be objectively better at it thanks to the very straightforward implementation of these features. Great looking stuff.
https://www.youtube.com/watch?v=4Yt1ToAqDxY
Cannot unsee.
Sculpting
I'm pretty keen to have a go of the sculpting side of Blender, a lot of my work I have to use Zbrush for details, and if I can use blender just as effectively, then it's gonna be a no brainer to simplify my workflow.
On sculpting : the 2.82 features are really good - especially the slice from mask and the extract with built-in solidify modifier. Objectively better than Zbrush in that regard.
However ... the flatten brush really is busted at this time, it does't seem to flatten at all but rather raises/lowers the surface in a weird way. So if flatten is a big part of your workflow it'll be a problem unfortunately.
No conflicts on my end - that said I do tend to disable stuff I don't need as I am not a "gotta use the defaults" kind of guy. But drag rectangle select is absolutely not incompatible with it that's for sure.
https://devtalk.blender.org/t/left-click-select-keymap/3168/388
And has been reported as a bug a few times:
https://developer.blender.org/T70645#846661
https://developer.blender.org/T68970
However, the devs consider this intended behavior, and will not be treating it as a bug but a design issue (which I think is understandable from their perspective). The best way to get it changed may be to keep the dialog open in the developer forum.
https://devtalk.blender.org/t/left-click-select-keymap/3168/401
If this is important to you, please consider popping over and voicing your concerns.
When using "Select Box" or "Select Lasso" with Shift or Ctrl it is possible to select/deselect elements outside of the actual selection area.
This issues were not obvious to me, because coming from previous Blender versions I always use "B" hotkey for box selection.
A solution could be to disable the normal selection when this tools are active, make them more behave like the hotkey version, but this would probably lead to some workflow issues for other users.
I think the devs are aware of the situation and will hopefully find some way to improve it.
For now I can configure it the way I need it and I'm happy.
On my end I am not running into such issues, but I went through this adjustment of settings a little while ago and cannot recall in detail what changes I had to do to make it work, if any. But as a proof of concept I can confirm that it is possible to make it all work without conflicts with box selection, simply because that's what I've been using for months now
https://www.youtube.com/watch?v=2us_4dZu8Ro&feature=youtu.be
(and it goes without saying that I am using click-drag for box select here)
If anything, if the behavior change was indeed caused by the introduction of another feature (new box select input), then the situation is all the more worrisome becomes that means that it's not just an oversight but an actual proactive decision. Hopefully they'll come to their senses eventually. The sad thing is that this is imho an evidence of a negative shift in focus (adding new features at the expense of existing delicate systems. And sprinkled with a pinch of design by committee). Oh well.
The imho bigger problem before they can fix anything here is that they have two contradicting tool systems now. The old one, called with the hotkey and from the text menus. And the new one, in the tool shelf. Means you have for example two box selection tools now that does the same. Just a bit different. But it works for them, and so i don't see them fix this issue.
Is there a way to convert an annotation (blue line, not GreasePencil) to mesh geometry ? Just the edges, no thickness.
I understand that there is a path to go from GreasePencil to geometry, but the 2.8 grease pencil has way too many features/effects getting in the way of quick sketching on surfaces (also very annoying default look presets). Being able to retrieve edge data directly from quick annotations would be great - the data has to be somewhere ...
@xrg Hmmm that's odd, can't seem to see anything like that in 2.8, 2.81 or 2.82. Would you mind elaborating a bit ?
I do see a "Convert Grease Pencil" command in the search, which *does* seem to act on the blue annotations ... even creating an actual GP scene object with contents of the same name as the original annotation ... but nothing seems to come out of it. Odd.
Oh, here we go:
Would LOVE to see it in action for game ready assets.
Here all the little details were added as an afterthought after the underlying game asset had been finished months earlier :
https://www.youtube.com/watch?time_continue=44&v=kdarmhU3PPY&feature=emb_title
Same here :
https://piortumble.tumblr.com/post/188558215398/decalsvariants-over-an-already
And all these bits can be baked down to the lowpoly geo and then composited on top of the already existing maps texture.
And here, the decals were created at the same time as the highpoly stage, and baked down to low in paralled to the regular high then comped in on the texture :
https://66.media.tumblr.com/08a6910e0b16d97a5be33e18d5f65342/c8d88a2c94e90752-9a/s1280x1920/6f42451c55a517acd36dae223359e70f504eafb1.jpg
Now it is also possible to work in other ways, like skipping the high altogether by working directly on the final ingame mesh+decals. This can work for some assets, especially on mechanical props/weapons/vehicules (like the examples coming with DecalMachine) but not all, as it does affect the look/style of the artwork quite a bit.
How i can imagine myself using it is just after I've baked down the high poly, before texturing. So i can add in details i didn't want to model. Sounds really awesome actually.
I use toolbag 3 for my baking, will the tangents mess up through this workflow or are the tangents similar?
• If you use, say, 12 decals ... that would mean having to setup 12 materials in TB just to transfer that data, juggling with what you want to transfer, and so on.
• Also, the question is what to even bake. Baking these decals down works flawlessly in Blender because it pulls directly from their unified materials with all their components (normalmap, height, ao, curvature, and so on). And then the bake just works from there in one click.
That said this is only needed for the decal pass, so nothing prevents you from baking your high in your software of choice. Just not the decals.
@pior Why would he need to create one material for each decal?
The misunderstanding probably comes from the fact that what you mean by "decal" (stencil decals from an atlas source, I presume) is not the same as DM depth/normals/ao decals faking geometry. These can only baked down in Blender at this time. And even once DM can compile/export atlases it wouldn't work either regardless because TB3 can only transfer Albedo from pseudo highs anyways.
But yeah regardless, the result is probably a similar feel. Hey, if anything that does spreads awareness
I am looking for how to do this in Blender:
Creating the textures are easy but how to randomly put them per uv tile is the issue. This is where Bercon tiles come in.
Or this method:
Using Blender eevee.
Is this possible with OSL shaders?
Hotkey is alt+B.
In rebevel there is only alt+B and it can change all bevel properties (width, segments count or delete bevel by merging bevel verts). And it operates always on one type of selection - bevel ring edges (I added 'Loop Ring Select' addon to make it easy to grow, shrink, select range of rings/loops - this way selecting bevel should be fast).