It seems like a small thing but having a flexible placement and rotation system is so fundamental to the modeling experience. These changes have been really great.
The summon feature with the tab key is really clever. I’ve been enjoying that capability since I noticed it was available, especially when paired with the translate tool. Forgive me if this is too late or if it has been covered above, but there are a couple of things with how the summoning works for scale and rotate that I’d like to bring up:
TL;DR
- Show all scale handles
- Have summoned scale work the same as non-summoned version (some with ctrl/shift behave differently)
- Have summoned rotate work the same as non-summoned (around original pivot)
- Keep the pivot snapping stuff in Edit Pivot (but add the tab-summon ability to Edit Pivot so snapping to points within view is possible when the current pivot isn’t also in view)
- Being able to toggle Edit Pivot with a hot key might be worthwhile
Translate:
I’ll start with translation as a baseline. The translate summoning is really effective because all of the handles are visible after summoning, and the results are exactly as they would have been if summon hadn’t been used (i.e. if you moved the viewport around and used the translate handles from their normal placement). Shift and ctrl keys don’t have any effect in that mode (AFAIK), so it’s all simple and intuitive.
Scale:
The first noticeable difference when summoning the scaling tool is that not all handles are visible. I’d argue that being able to see all the transform tool handles should be a given for a summoning action. It’s fair to say that most of the time a user won’t be pulling the out-of-frame, far side of an object toward and into the area of the scene that’s framed in the viewport, but sometimes (fairly often for me) there is a use for that. Why not have access to that capability through the obvious action of summoning the transform widget?
Example #1: Let’s say we’ve brought a tree model into our scene and then placed it where we want it on the ground. The default size is too big, so the obvious next move is to grab the scale handle at the top of the tree and pull it down (maybe while holding shift) to get a height that works relative to the other things we’re looking at. As it currently stands, even with the summon, we would need to move the view around in order to find that top scale node if the top of the tree was out of the frame.
Example #2: If we are somewhere near the middle of a large panel, it’s possible that after summoning the scale tool we might still only see the nodes that would allow us to scale the panel toward and away from us (side-side and top-bottom scale nodes are still not in frame). If we’re viewing the panel from an angle other than straight-on, it’s possible to see fewer scale nodes after hitting tab than before. That doesn’t seem like it should ever be the case for a summon action.
Placing the nodes around a temp “summoned pivot” like with the translate isn’t particularly helpful, but I wonder if it’s possible to (effectively) slide any out-of-frame scale nodes toward each other until both are in view. Since dragging a grabber node stops at the edge of the viewing frame, that “slide” may need to include some extra room in case the user wants to scale out rather than in.
Scaling behavior
The availability of shift and ctrl modifiers–and scaling differences between models and parts–also complicates things a bit. To recap, the expected behavior for Part scale (without tab summoning) is as follows:
1a. Node: pull/push toward/away from other side
2a. Node + ctrl: pull/push opp sides toward each other (toward center of Part, not pivot)
3a. Node + shift: pull/push all sides relative to center of side opposite the node
4a. Node + shift + ctrl: pull all sides in toward middle (center of Part, not pivot)
For a model:
1b. Node: same as 3a
2b. Node + ctrl: same as 4a
3b. Node + shift: same as 1b (3a)*
4b. Node + shift + ctrl: same as 2b (4a)*
* shift appears to add nothing new to model scaling
Suggested Summoning Scale Tool Behavior
In my opinion, that is already enough functionality for a user to have to keep in mind. As with the translate tool, the results you get when summoning the scale tool should be identical to that seen when not summoning it.
Currently, the scale tool has some different behavior when ctrl and shift are used. Some changes seem to be made relative to the temp “summoned pivot”, whose placement can be arbitrary, so the results are hard to predict with certainty. As such, I don’t care to use that feature and find myself zooming out to scale without using the summon action. Personally, I’d prefer it if the summon action didn’t add any new twists to the behavior. Having it work as usual, but with handles I can reach, is perfectly fine.
Rotate:
The rotate tool completely breaks with the idea of the summoned grabber behaving like the normal one. There’s an argument to be made for changing that for consistency sake alone. Sometimes, all I want to do is look close-up at a reference point while I rotate another object using the rotation pivot that’s already there (i.e., I don’t need to see the middle of the box to rotate around the middle of the box). The summoned rotate tool seems to be using snapping to grid and also snapping to edges of the object…at grid increments… or something. Anyway, what it’s doing isn’t completely obvious. The snapping and setting of the rotate pivot do have some advantages though, but maybe that can be done through Edit Pivot instead.
Suggested Summoning Rotate Tool Behavior
So, for this one, my personal preference would be to see it kept simple. When the rotate tool is summoned, it shows around a temp “summoned pivot” like with translate, but it rotates the object around the original pivot (as it would without using summon). If the rotation pivot needs to be moved, then enabling the summon feature while the “Edit Pivot” button is activated would be a nice addition.
Here’s what I mean: Setting the rotation point when summoning the rotate tool is a convenience feature that hides the expected behavior and introduces inconsistency. Setting the rotation pivot through Edit Pivot is what would be needed for rotating around a selected point without using summon, and it would arguably be no less convenient to do that when summoning the grabber to an area. Notably, you can’t summon the grabber when the Edit Pivot button is active. Adding that tab-summon capability to the Edit Pivot functionality (to snap to things in view) would be a nice upgrade to that feature and would make switching the current tab=summon-rotateGrabber+setActivePivot action to an Edit Pivot action relatively painless from the user’s perspective (esp if Edit Pivot could be mapped to a hot key). That would allow the summon rotate to behave consistently relative to the other grabbers (and its unsummoned form), but it would also make any pivot adjustments a clearer and more purposeful exercise, which has its own benefits.
Anyway, just some thoughts/opinions. Sorry if I missed where all that was hashed out already. The pivot stuff is really coming along. Thanks for all you’re doing!