I guess I'm confused about whether I'm misunderstanding something or someone at SESI had a different idea about what aligning handles to geometry is, way back when. The docs on this topic starts with “Align handles to geometry” title and the feature itself on the RMB menu is found at “Align Handle >”. I know the feature is there prior to H17, but it didn't click in my mind until now what exactly is the issue with it or how to spell it out.

Indeed, this is not what it says, at least not just that and the more important part is left out. It's actually an “Align/Snap geometry/components to geometry/components” and the handle alignment itself just comes along for the ride.

If you want a true “Align handles to geometry” you have to first detach the handle from the geometry (' hotkey), perform the alignment (; hotkey) and then reattach the handle back (' hotkey again).

I'll surely RFE what is actually an “Align handles to geometry” powered by a transient key, which of course skips the whole detach/attach phase. Describing the current necessity to detach/reattach as “sub-optimal” is a gross understatement, since basic point pushing modeling requires lots of these handle alignments per minute.
I don't feel like searching, but I think I described this feature in the “Transformations” thread, but it might not caught any dev. attention and/or I might've also omitted filing a RFE for it.

This is crucial not only for modelers, but very useful for animators too when transforming an object using another's reference frame.

I'm leaving this here for anyone expecting to get what's on the box. I also strongly recommend changing the name of the feature in H as well as in docs. I'll probably RFE this as well.
Cheers!

Hello,

We actually added a volatile edit pivot mode into h17, which is part of the ‘align handles to geometry’ workflow that you mentioned. Unfortunately, the hotkey wasn't properly assigned for the release. We'll try to take care of that in an update.

In the meantime, you can search for ‘volatile edit pivot mode’ in the hotkey manager and try it out for yourself.

Cheers,
Scott

Hi Scott,
I went to the hotkey manager and the ‘volatile edit pivot mode’ has no assigned key. If I assign the existing one ‘ of the Toggle, nothing happens. And if what my experience tells me it’s correct regarding reassigning hotkeys, then there's little I can do to correct the issue. For example I tried to steal the hotkey ‘X’, because it's transient, from the snap radial menu (because, snapping should be activated on the fly not as a toggle in a menu) with no luck. I'm not sure, but it seems that the few keys that are transient are unbreakably linked to the features they've been assigned to from factory.

But here's the catch - even if the ‘volatile edit pivot mode’ had a working hotkey, it still doesn't address the main workflow issue I described above. I'm not sure whether you understood it and just wanted to give me a tip to alleviate part of the problem for the time being, but I want to make sure we're 100% on the same page.

Imagine ‘volatile edit pivot mode’ works and it's the current hotkey for the toggle ('). How would a true “Align handles to geometry” go currently? Press&hold ‘ then press&hold ; then if you only need a rotation match, also press&hold Shift until you LMB on something.

The fact that a ‘volatile edit pivot mode’ exists and it’ll soon be activated is great news. It's very useful for place-snapping (if only multi-snapping had a transient key) the handle and transforming points, etc. after that new “pivot”. Use it all the time in XSI and from what tutorials I've watched in the past, it seems modelers in other programs use this too a lot.

In addition to these two we need a real “Align handles to geometry” like described previously. Not the combination of the two above (one of which is currently called “Align handles to geometry” if matters were not confusing enough), but a one hotkey solution that doesn't involve a detach/reattach handle input from the user, i.e. exactly how the current (the more accurate name) “Align geometry to geometry” works.
Thanks.

Fortunately I went back to fiddling with the hotkey manager and discovered a few things.

The problem I was having was probably because I was trying to assign the current handle detach hotkey (') to ‘volatile edit pivot mode’ and for some reason it doesn't have any effect in vp, even though the assignment itself seems to go through. I then assigned it to replace the pivot's toggle hotkey (Ins) and works great. The volatility aspect seems therefore linked to the feature itself, not a specific key. A “make multi-snapping volatile” RFE is in order.

And we're yet talking about a pivot alignment. Still not a “handle alignment”. As such, it's great for modifying objects' pivot at scene level and it's useless for SOP lvl modeling.

So, we have an “Align pivot to geometry”, an “Align geometry to geometry”, but we lack a “Align handle to geometry” feature, one as direct as the other two at least. And I'd argue it's the most important, ranked by frequency of usage.

edit: not really “useless for SOP lvl modeling”, but if I want to not involve a pivot offset in order to have “clean” transform values, I'll have to use the detach/reattach method. Even at scene lvl I don't want want to change the pivot values of an Obj for the mere purpose of an interactive transformation.
Also, the fact that “pivot mode” and “attach to geometry” hotkeys (' and ") are on the same physical key, muddles further more the whole issue. I'm willing to bet that even not-so-new Houdini users are at the edge of the woods regarding this matter.

After a few days of trying to achieve liftoff for a mech. model of which concept has been rattling inside my head for a while now, I deem Houdini 17 unusable. The bugs and/or overlooks in feature implementation regarding the issues discussed above, are so many and wicked that I'm no longer striving to identify and reproduce them for cohesive bug reports.
You keep inviting users into alpha/beta that spend 90% of their time in wranglers and then probably read in astonishment “mean” posts like this from “frustrated” users.
If I don't classify as a devoted user that tries to contribute with constructive criticism and feedback, judging by the number of RFEs and posts documented with pics and gifs, in the limited field that I'm competent, then fuck whatever is considered a devoted user around here!

McNistor
The volatility aspect seems therefore linked to the feature itself, not a specific key. A “make multi-snapping volatile” RFE is in order.

That's right, there are certain ‘states’ which are volatile, meaning that they can be activated by pressing and holding a hotkey, or ‘tapping’ the hotkey to move into the state in temporary way.

A similar mode for the attach/detach handle operation is in development.

McNistor
A “make multi-snapping volatile” RFE is in order.

This feature is on the list of things which we would like to tackle in future updates.

McNistor
You keep inviting users into alpha/beta that spend 90% of their time in wranglers and then probably read in astonishment “mean” posts like this from “frustrated” users.

I'm not quite sure where you got the impression that we are astonished by ‘mean posts from frustrated users’. We generally understand the source of the criticism and are sympathetic to the frustrations felt by users. Arguments presented by users are often used internally to try to guide development efforts to help alleviate pain points. That said, development time and resources are limited, and things that may seem like easy fixes from the outside are not always that simple when it comes to actually implementing them. Something like the volatile states mentioned above were part of the most recent effort to update some of the ways a user can interact with Houdini. This process will continue into the future, and hopefully things improve across the board over time.

McNistor
If I don't classify as a devoted user that tries to contribute with constructive criticism and feedback, judging by the number of RFEs and posts documented with pics and gifs, in the limited field that I'm competent, then fuck whatever is considered a devoted user around here!

Alpha/Beta access is necessarily limited due to the resources required to track and respond to those users who have been given access. It is likely that there are ‘devoted users’ who are not part of the alpha/beta process. We try to include users from different disciplines as much as possible to make sure we get useful feedback on ‘in development’ features - that includes modelers, riggers, animators, etc. I seem to recall that you were part of this process for the release of Houdini 14, but I could be wrong about that.

I don't think there were any questions in your last post, but hopefully this response helps clarify anything that was left unasked.

Cheers,
Scott

Houdini should not come out the factory doors in the current state that it is when you go into SOP and start direct modeling. Regardless of how true it is what you're saying, most of your post is PR lining. Those modelers that you invite, if they're worth their salt, they'd be pounding on you to not let you veer into adding tools that will end-up almost useless because the foundation is screwed up. And you'd listen.
Do I need to go again over the things that you shouldn't stop trying to fix before adding even a small thing? I've done it here on the forums and on RFEs and most of them have been ignored. I don't feel encouraged to do it again.

In choosing to interpret the reasons for the current state of affairs in the most charitable way, because managing and tracking info in a forum or a RFE database is a daunting task, I will mention a few things here. They are an absolute must to be fixed/changed/added. Before anything else is done regarding modeling, before going into the actual poly-ops (bevel, split, fuse, etc). So instead of not on top of, hence your resource management related issues should have little bearing on this.
These are off the top of my head and certainly there are others. No pics or gifs this time, for reasons I will describe at the end.

- remove the constant switching of the current tool to the handle tool, after various operations. Most of the time, the user ends up switching to select or the transformation tool that was active. So a key-press needlessly added on top of every thing else, every few seconds or so. The only time this is arguably a good idea is at the object creation (at obj level, not in context). And a few others modeling non-related (paint node, groom, etc). This was touched briefly by someone else here [www.sidefx.com] and I'm pretty sure it's not an issue for just the two of us.
- I end up having an inactive gizmo (greyed out) - no idea how
- I end up having an active gizmo (colored) that can interact with, but nothing is selected - hold S click on empty space
- the newly introduced “handle alignment” tool (and change its name to “object alignment”) is behaving erratically; sometimes it snaps just the handle, sometimes the selected component (I have read the docs and am aware of the different modes with shift/ctrl); the current muddiness of the concepts and naming behind these alignment tools is in tune with other things in Houdini that are needlessly confusing
- sometimes I try to delete selected faces and nothing happens other than being prompted to select faces; other times it works as expected
- viewport switching ‘space+B’ works for a while then it decides to stop working; and shortly after works again
- the first time you enter in point mode, no points are shown; going to edge mode and back, will show them. (not a big issue, but mildly annoying)
- local transformation of components is poorly implemented or buggy (no independent transformation)
- no GC at SOP level
- GC at Obj level is buggy since previous versions (deactivating it doesn't return to the last object selected)
- no global/local/ref values in transf. channels
- many others I can't recall right now
If a bevel or extrude op doesn't produce exactly the results I want, I can go in and make the corrections. Most of the time you actually end up modifying the resulting geometry of that bevel/extrude anyway. But if I'm having to fight an insane interactive system with almost every action I attempt, then a good bevel or extrude op is going to do little to soothe my pain.

For many of these I can't go to Support with RFEs, since I have no idea how to reproduce them. And I'm not particularly eager to persevere in looking for ways to reproduce them since older bugs already reported are still there. And more than this, some of these wrinkles are probably best ironed out in a back-n-forth in depth discussion between a dev. and a tester, the kind that is taking place in the alpha/beta forum. So my apparent saltiness about not being invited to alpha is about the fact that these issues still exist and nobody in there seems to have cared enough. Or was ignored. And the few new features (interaction and modeling) don't seem that optimal from an usability pov and seem also poorly tested, with bugs. Either way, I don't care much about invites, I care about having a working direct-modeling solution inside H, so please achieve that however you wish, me invited or not, but please DO achieve that. You have the option to act as other companies and come up with a “bells & whistles” new features list or to forgo some of the glamour and fix the indispensable nitty-gritty.

@McNistor - so the takeaway from all this is that Houdini is still, after years of development, a factor of 100x slower for modelers?

At least that would be an improvement from not possibly being able to model at all

Yeah, I don't know anymore, maybe I'm doing it wrong. It would explain all those invited modelers that are apparently happy with the status quo on this front.
The user devotion I've manifested thus far was the kind that is holding SideFx' feet to the fire to do what I think is the necessary thing, not the unconditional tail kissing I'm seeing around here. And I'm not special in this way, probably not even in a minority, but on this narrow issue I feel like I'm in the woods at night. I've ventured probably too far.

dunno but it sounds like there isn't a product-manager for the modeling side of things. hopefully there will be a Vellum-style development effort for modeling at some point.

EDIT: handle stuff added:

Houdini 17.0.389 Added a volatile hotkey for putting the handle closest to the mouse cursor into detach mode with orientation picking enabled. The hotkey is not yet bound to an actual key.

McNistor
- remove the constant switching of the current tool to the handle tool, after various operations. Most of the time, the user ends up switching to select or the transformation tool that was active. So a key-press needlessly added on top of every thing else, every few seconds or so. The only time this is arguably a good idea is at the object creation (at obj level, not in context). And a few others modeling non-related (paint node, groom, etc). This was touched briefly by someone else here and I'm pretty sure it's not an issue for just the two of us.
- I end up having an inactive gizmo (greyed out) - no idea how
- …

I am very disappointed since H17 and the new “S” key behavior feature with the confusing tap/switch mode which also introduce regulary an inactive gizmo like you said.
It's a complete source of confusion and errors when doing modeling in a “traditional” way.

I really like all procedural stuff and build as much assets I can but major part of a project need to be build manually and aren't mathematically transposable.
During a modeling session I constantly fighting with selections and tools modes that change without reasons.

We also have a lot of problems with the “S” tapping/switch mode here. Constantly going to inactive gizmo or no gizmo at all. Haven't been able to log the bug repro steps correctly yet, but I will as soon as I can