Uniform mitering is a bevel feature in Softimage that works like this:




Here's the same bevel in Houdini.



You can imagine the number of steps I'd have to manually take from this to get to the above result.
Also the algoritm is somewhat different - it doesn't keep a constant width of the bevel, but it rather adjusts by the width of the surrounding polys. This could be useful sometimes but in my experience you'll want a constant width.
When the space gets too small to keep the width the same, the next feature (manage collisions) comes in.
The Absolute inset is probably supposed to achieve constant width but it doesn't quite work.

There are countless examples in which uniform mitering is needed - probably 99% when getting into complex topology. It's rather surprising to me that it isn't ON by default in XSI.

————————————————————————

Let's see what manage collisions do:


In the gif above, if I wanted constant width of the bevel I'd leave manage collisions off and I'd simply grab the points that overlap and merge them to the ones of the bevel. I Houdini I'd have to manually scale the edge which means eyeballing it and that wouldn't be such a big deal if I'd have to do it once.

In Houdini the width of the bevel is controlled by the inset and it acts as the name suggests - it insets the created polys which probably explains why collision detecting is “built in”, but the downside to this is that there's no possibility for a constant width of the bevel despite using the absolute value. I guess in a way it works, as long as the edges of the bevel haven't hit the surrounding edges yet, but when it does it goes “inset (relative) mode”.



————————————————————————





Here are a few other interesting features some of which I don't know what they do but it shows the level of control you have in your bevels. I've heard from others that they're god sent when working with polyText where you have lots of convex/concave twists and you need to bevel the edges. Dealt with this problem only once and it was a rather pleasant experience.
They become available when nb. subdiv>0
I never used these with the exception of sharpness (which I'd like to see in Houdini, unlike the others in this subsection) which if you look closely when it's 0 (default 1) it outputs a similar result to Houdini in the star shape in the lower left corner.
Best bevel I've seen in any 3d app so far.



Haven't used with this TBH; bevel width is all I ever needed



This is the Houdini equivalent to relative/absolute which in my opinion should be a drop-down or checkbox/optionbox instead of a different tab




Center is a rather useful feature.

What I'd like different for Houdini, is to have some onscreen (near the cursor?) widgets à la 3dsMax (but better ), because as of now it's just like in Soft and Maya and probably others and having to pull sliders onto the other side of the screen is not that hot.
The option to add/remove what sliders to be added on the tool's widget would be a great addition.

McNistor
What I'd like different for Houdini, is to have some onscreen (near the cursor?) widgets à la 3dsMax (but better ), because as of now it's just like in Soft and Maya and probably others and having to pull sliders onto the other side of the screen is not that hot.
The option to add/remove what sliders to be added on the tool's widget would be a great addition.

I think there will be more onscreen sliders for other tools too in the future. There are several now, introduced recently, not exactly a widget near the cursor but close

While the bevel tool in XSI is quite versatile it is not state of the art anymore. Bevels with non constant radii are the future. I look forward to what SESI comes up with.

I'm not sure what a bevel with non constant radius is. Is it related to a non constant radius curvature?
If that is so, it might be overkill for poly modeling purposes (more like for NURBS/engineering modeling), but in any case it would be an addition to a versatile bevel (presented above) against which I have nothing if this is something people want and/or devs are willing to implement it.

If I understood you correctly, then Softimage's bevel already has this. Never used this TBH, but I can see how it can sometimes be useful.

I think so

One thing that houdini could do better than anyone is to drive the bevel amount with a vertex attribute. That is more for the procedural modeling though

grayOlorin
One thing that houdini could do better than anyone is to drive the bevel amount with a vertex attribute. That is more for the procedural modeling though

That's what I meant with nonconstant radii. Blender has something of that kind called bevel weight. It's basically a point attribute and allows for different radii along a bevel based on the bevelweight resulting on conic bevels. Very useful.

PS: Modelling in houdini should never get nonprocedural. Maybe a mix, like a tweak node with an internal history, that can be collapsed. That way you'd have a temporary modelling history but keep your network simple and memory footprint low. When tweaking points you wpild want to keep your steps to be able to trace it back or what ever but once you're satified you'd usually freeze/collapse it. Just like the edit node but with an extension.

Edit: attached an example of bevel with variable width (its MoI and nurbs and only to visualize what I mean)

grayOlorin
One thing that houdini could do better than anyone is to drive the bevel amount with a vertex attribute. That is more for the procedural modeling though

I can't found it. How to achieve it？thanks

It dies not exist yet . Just hopin…

grayOlorin
It dies not exist yet . Just hopin…

OK, sorry for misunderstood you. I also hope so.

grayOlorin
One thing that houdini could do better than anyone is to drive the bevel amount with a vertex attribute. That is more for the procedural modeling though

I do agree, it would be good for the programmers to be on the lookout for valid places to add that Houdini touch. Also, it might be ambiguous where on an edge to sample an attribute, in many cases.

Ah, so this is the one.
As others have said, it's probably more suited for procedural stuff, but that's not to say it couldn't come handy from time to time in the traditional poly modeling.

McNistor
Ah, so this is the one.
As others have said, it's probably more suited for procedural stuff, but that's not to say it couldn't come handy from time to time in the traditional poly modeling.

The new C4D bevel modifier has some interesting options too and it is procedural (maxon seem very proud of having discovered nondestructive modelling in r16 )
Traditional modelling in XSI is procedural as well. I'm not sure why there seems to be the need for a distinction.

The distinction I'm making (can't speak for others) is this:
when I'm referring to procedural modeling I'm referring to building systems that can later customized and possibly used as deform system, which usually includes things like chairs, ladders, rooftops, buildings with n floors, (you got the idea) as opposed to traditional where you're modeling a high dense and detailed mesh (a robot, a game character, etc.) where the option to go back 150 bevels is often useless since many other operations have been added on top and the evaluation of those would make a mess out of the heavily modified geometry when fiddling with the 150th bevel.
Therefore not what is happening under the hood, but how the users approaches and ultimately uses the model he's creating.

Anyway, the important thing we all agree with, is that Houdini should definitely keep its core workflow.

grayOlorin
One thing that houdini could do better than anyone is to drive the bevel amount with a vertex attribute. That is more for the procedural modeling though

I tried doing this recently. Was intending to make an RFE for it, just haven't found the time to put a decent sample case-use together. It would definitely be useful.

McNistor
The distinction I'm making (can't speak for others) is this:
when I'm referring to procedural modeling I'm referring to building systems that can later customized and possibly used as deform system, which usually includes things like chairs, ladders, rooftops, buildings with n floors, (you got the idea) as opposed to traditional where you're modeling a high dense and detailed mesh (a robot, a game character, etc.) where the option to go back 150 bevels is often useless since many other operations have been added on top and the evaluation of those would make a mess out of the heavily modified geometry when fiddling with the 150th bevel.
Therefore not what is happening under the hood, but how the users approaches and ultimately uses the model he's creating.

Anyway, the important thing we all agree with, is that Houdini should definitely keep its core workflow.

I have build systems like this in XSI, including bevels.
I think the main difference would be if you keep all you ops or not. I agree that in “traditional” modeling you seldom would want all your operators present in the final model. During the process the opposite is the case until you're satisfied with the model. In other tools youd collpse/freeze/delete-history frequently. In Houdini you'd have to bake out the model from time to time which is not very convenient. If there was a convenient and fast way to collapse the network while modelling you would use no special sop but only decide what to keep.