Because it was moved out of beta today.
Have you used handle summoning yet (hold tab)? If you get used to the muscle memory for it I think that you will find it replaces the need for the handles to always be out at the edges quite nicely.
Hey, i’ve read through some of the posts and i’m wondering if there is a way to disable this feature, i went into studio a few minutes ago and realized i could no longer disable this feature. i tried the feature in the beginning and it was cool but when making a huge build this feature is really, really annoying. i don’t think there is a way for me to turn this off and i’m kind of annoyed because i work with massive builds and this feature just gets in the way. (By get in the way i mean it cause a extreme amount of lag and it’s just a waste of time for me to keep pressing “Tab” and getting handles in the right position. It just makes me waste time when i could be building something else in a game.)
This is another reason i liked it staying in the “Beta features” tab as i could simply enable it when needed and disable it when i don’t want to waste time with summoning handles.
I really hope you consider a way to disable this feature. I take a long time to build without this feature and with this feature the time it takes has almost doubled!
if you aren’t adding a way to disable this, can you provide me with a plugin that puts the handles at the sides again.
5 Likes
You’ve just said everything i was thinking about this feature. Yes, it’s very useful, but its annoying and makes building very messy. It gets more in the way than it helps me building. This should have an option to turn it off, it makes my building experience to be very dismotivating.
2 Likes
We shouldn’t need to train ourselves to use handle summoning. There is no reason why we shouldn’t be able to turn off this irritating white dot and return the handles to the sides of parts. It just makes resizing large parts more tedious. Although I can imagine that the feature itself is great (even though I haven’t used it yet myself), making it get in the way of the usual workflow of developers is just counter-productive.
5 Likes
I think after a bit, I was sort of getting hang of incorporating that into my workflow after the recommendation I made back in October of last year.
I still think that not everyone is comfortable with the feature, that goes with a four-man team I’m working with. It is relatively okay with smaller parts, but when it comes to moving larger parts/models, we find handles and pivot points extremely challenging to work with when we want it to perfectly place them.
We would highly appreciate it if there is a configurable hotkey to enable/disable this feature manually, similar to switching global/local axis via LCtrl + L, which will only bring up those pivot editors when we absolutely need it.
Please don’t get me wrong, I’ve found pivot editors extremely helpful at simulating hinges and displacing some parts/models for some of my builds, I just think that we should have some versatility, especially toggling and hiding the pivot itself.
4 Likes
My bad, I only noticed that a different bug occured at the same time that this feature was fully released. I since have found this post AddAccesory() not working as expected in Team Create regarding the accessory issue I have had.
I jumped to conclusions and I apologise.
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!
6 Likes
Thanks for the detailed feedback!
We’re currently evaluating all of the concerns that have been raised (move handle positioning, pivot point “dots” causing visual noise/clutter). We always strive to balance improvements to tooling with the impact on existing workflows; if we need to return the feature to beta while we address these then that is what we’ll do.
3 Likes
Could you elaborate on which aspects of the feature you find disruptive? (repositioning of move handles, etc)
1 Like
How do I disable it? I don’t like having it enabled.
You can’t disable it. If you don’t like it, I would probably just tell staff why you don’t like it so they can improve it.
Then my feedback is to add a feature to disable it.
6 Likes
I feel like they’re trying to force this onto us no matter how bad we find it. So many people have the legit same opinion about it: It’s useful, but it’s messy.
Adding an option to disable the pivot editor won’t make it useless, as people could just turn it on and use it whenever they need, without it messing the building experience. Also, the fact that they either talk about holding tab(which for me doesnt’ change the problem) or ignore when people say the feature is annoying feels very upsetting, as it makes it look like they don’t really care about our feedbacks.
6 Likes
Can you remove this feature? personally, this is one of the most useless things ever, either remove it or allow a feature to disable it… not very helpful to me at all
7 Likes
I don’t like it because I constantly have to regroup/ reset the pivot on models that otherwise would be fine without the pivot editor
6 Likes
I suppose since they probably won’t listen to us complaining like this I’ll give actual feedback.
Yes, Pivot Editor is a good update. I like it, I could see the functionality, I could see how some people could use this instead of archimedes in their workflow. However, it’s incredibly annoying on current games and on large models, not only do you have to completely redo the pivot origin on models if you want accurate measurements, but it’s impractical.
Adding some sort of shortcut to turn this off, like local and global axis, like someone else said, would be great.
Yes, I’m aware holding tab will create handles, however I develop in increments, meaning holding tab will add lots of z fighting and trigger my ocd a lot by not being perfectly centered.
I haven’t been able to develop the past 2 (I think) days because of this.
Option to disable would be very helpful.
Cheers!
tgarbrecht
5 Likes
Please for the love of god just add some way to disable it so everyone is happy.
It’s a useful feature but it’s interruptive and everyone has the same feedback, just add a way to disable it.
3 Likes
I read above that scaling hasn’t been fully updated to work with pivots, so some of this may be related to that. The posts linked below touch on the issue of models reverting from a “model scaling behavior” to a “part scaling behavior” when there is only one part left in the model and on the potential confusion that results when that one part is oriented differently than the World Pivot Orientation of the model causing the extruding of a side of a part to look like it’s being controlled by the wrong scale handle.
The last video just shows dragging a scale handle with or without ctrl modifier on a model with the pivot not at center. Having scale handles uniformly scale the model toward the opposite side in the direction of the pivot (like it’s doing) seems okay to me. I’d say that’s useful. What’s happening when the ctrl is held doesn’t seem as useful though. There’s way too much position change that happens if the pivot isn’t centered and, consequently, that makes judging where the final placement of the model will be really difficult. Having the whole model scale toward/away from the centroid (rather than the pivot) when ctrl is held might be more useful.
2 Likes
Well done Roblox. You just permanently lost yourself a user of your built-in tools.
EDIT: added picture of the total lunacy, would be completely avoidable if the old move tool handles were usable
3 Likes
Based on all of the comments here, I think returning the Pivot Editor to beta while we consider how address all of the issues raised here is the right course. I’ll return the feature to beta today, and then follow up with everyone to gather feedback. Thanks for your patience!
4 Likes