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.
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!
Can you explain what your workflow is? There should be no change to defaults. A Model’s pivot should be identical to without the pivot editor unless you explicitly go in using the tool to change the pivot.
When mass selecting items there are the same amount of pivot points and it’s basically like another part being put into the Workspace. Too many parts/Models being dragged already causes lag for me and with the pivot points also appearing while the items are being dragged would double the amount of lag i had, working with mass builds with all these pivot points sometimes crashed my Studio and end up with me loosing progress.
(a pivot point per part), a way this could be fixed is if there was one pivot point in the center. But then again the tools being in the middle of the selected items are really difficult to move them to to the wanted position.
I totally agree. They should have an option to turn this off, It’s not very useful whn your woking on a small scale and trying to precisly move a part because the move tool is centered to the picot point.
Sometimes, it randomly places the MainPart of the model somewhere randomly and since im so used to just adjusting the position from center mass of the entire model, I have to take the time to go to properties, remove the MainPart, and then reset the Pivot from the model tab.
It could be that it’s inheriting the MainPart of a model inside of it and throwing the entire thing off, but I could be wrong.
It’s just a convenience thing. I don’t think I’ll ever use it, that why I think it should have a disable feature. That way, if I do need it I can just go to the setting and re-enable it.
Hi Architekts! Forgive me for the direct reply, but I’m also trying to understand the problems people are having with the pivot stuff. I think the changes are great and really want to support them, but I’m struggling to understand the argument against having them. Would you mind clarifying your comment, “…randomly places the MainPart of the model somewhere?” If parts of the model are being randomly placed, then that would be a big problem. Are you saying that when you go to move a model, you are expecting to find the grabber handles out at the sides, but instead they are around a pivot (maybe off somewhere inconvenient)? The later comment, “It could be that it’s inheriting the MainPart of a model inside of it and throwing the entire thing off,” makes me wonder if there is something more that I’m missing. Pre-Thanks for any clarification!
This is what I meant by it randomly being assigned a PrimaryPart (I said MainPart, same thing lol)
From there I have to remove the PrimaryPart and reset the pivot. It’s just an inconvenience with it not being something I’ll ever use. If you have a use for it, power to you. I just think it would be nice to have a disable option in the settings.
Are you referring to the behavior when adding/removing parts from a Model, or moving parts within a Model? I was reminded of this while re-reading the documentation for Model.PrimaryPart:
If the primary part is not set, the pivot will remain at the same location in world space even if parts within the model are moved.
Below, the yellow part within the model was moved but the pivot location is unaffected. This is also the behavior when adding/removing parts from a model.
As you point out, making lots of edits like this means you constantly have to hit Reset to re-center the pivot.
I’d like to understand whether the current behavior for models makes sense - or is causing unnecessary confusion and friction. Would you expect a Model’s pivot to always be centered, unless a custom pivot or Primary Part has been set?
How come the staff team, that should gather opinions about the feature, dismiss any and every negative opinion (which is most of them) about such feature? If you guys don’t care, and aren’t going to even try caring, just close the Topic. So far, every reply from a staff member to a negative opinion that i’ve seen is them talking about holding tab(which is IMPRACTICAL) and just denying the option of turning it off, and giving bad reasons for such denials.
Like, really, how hard can it be to just toggle the pivot dot and snatch the movement arrows to the pivot, when clicking this “Edit Pivot” button?? See, it’s really just that. That would make people SO much at ease with this feature. The Pivot tool is already in the Models tab, it won’t go away, just give us the option of turning off the movement arrow’s snatch and the dots…
(*Wasn’t meant to be a direct reply; just wanted the quote)
When the issue of legacy models with arbitrarily misplaced pivots is fixed, and it has been determined why some models seem to have PrimaryParts assigned at random, and anything else that can be classified as a bug has been addressed, the pivots will come out of beta and there won’t be a way for a user to disable them because future features depend on those pivots. Saying that “features could get very confusing” is probably an understatement if users are allowed to just turn off the functionality that supports them or disable the indicators that show why things are happening the way they are. The seemingly simple request for a way to toggle this functionality is not as simple as it seems—and may have far-reaching consequences.
It appears that there is a consensus around the sentiment that pivots should not necessarily change the way a user works if the added functionality provided by the pivots isn’t needed. It also sounds like the problem with a toggle may not be with the toggle idea itself but rather with the idea of having it controlled by a user.
There is precedent for changing the pivot visibility and (perceived) behavior, based on context, when Studio is in control (e.g. pivots currently don’t show when mult parts are selected, and the handles shift to center of selection). Given all that, I wonder if there is a way to determine/define a context wherein the pivot features are effectively invisible to a user, but where the “toggle” mechanism that enables this is managed by Studio and can be flipped as needed.
For example: If we consider a Part object, one key observation is that the pivot is always in the center of the bounding box unless it’s moved using the Pivot Editor. Rotation, scaling, and translation all happen about this pivot/centroid. Scaling/Extruding the Part, critically, causes the pivot location to move in concert with the bounding box center. If we say that our context definition includes having a selection’s pivot equal to its bounding box center, then we can note that a Part will be in this state almost all of the time. The only time it isn’t is after the pivot has been moved using the Pivot Editor (or a script).
We can extend the idea to multiple selected Parts. In that situation, there is no “true pivot”. The bounding box center acts as an “effective pivot”. By definition, that “effective pivot” and the bounding box center are equal. If we can accept that there is an equivalence of sorts between this effective pivot and a true one, then multiple object selections are covered by our existing context definition. Since this “effective pivot” can’t be manipulated using the Pivot Editor, we can further conclude that mult selections will always be in that state.
Pausing to consider what all that might mean, we’ve just established that any group selection and all individual Parts that haven’t had a pivot explicitly set via the Pivot Editor (or a script) are covered by our defined context. If Studio is configured so that it does not draw pivots on selections in this defined state, then pivot indicators can be almost totally removed from sight for users who don’t modify pivots (in scenes with no models). Additionally, we might note that selections in this state have a pivot (or “effective pivot”) that is axis-aligned (Obj space) with the face centers of the bounding box. That means the act of placing translation handles around the pivot center and placing them at the edges of the bounding box can be thought of as being similar, differing only by an offset. Assuming that translation handles can be offset individually (as with rotation dots), then that observation could be used to push translation handles to the edges of a selection in our defined state to further limit the observed impact that these changes might have on a user. No pivot indicators plus translation handles at the edges of a selection’s bounding box sounds a lot like the old system, regardless of what’s going on under the hood.
Extending the context idea to Models is a little more involved. The defining characteristics of our context still apply, but Models, as written, will quickly fall out of that state and remain out most of the time. This behavior of Models when Pivots are added seems to be a sticking point for more than a few users. In all fairness, it’s a big change to go from Models as positionless folders for Parts (unless tied to a PrimaryPart) to Models with a transform object of their own (…one that can be overridden by a PrimaryPart). It would be worthwhile, I think, to explore the idea of having a model’s default behavior imitate that of an individual Part, at least as far as having the pivot follow the Model’s bounding box center is concerned. If models without a PrimaryPart or a modified pivot could be written so that the pivot stays in the center, then they too would qualify for inclusion in our defined context. Parts, group selections, and Models (in that base configuration) could all be set to effectively work as they did in the old system without having to give users a toggle switch.
In the interest of keeping this brief (relatively speaking), I’ll assume that’s enough to get the basic idea across. In short, that kind of approach might allow:
Pivot indicators to be removed for selections defined by our context (selections where the pivot, effective or true, is at the selection’s bounding box center, in this example)
The transform handles to be placed at the edge of a selection (by default)
(^ with Studio in control of the toggle rather than the user)
Anything out of our context to be shown with pivot and perhaps different handle positions (e.g. when tab-summon is called → “effective pivot” not at bounding box center)
Tab-summon, selections with modified pivots, future features that benefit from or require pivot indicators, etc, to be handled with pivot visibility and handle position set as needed since Studio would be in control of the toggle.
The addition of a user-controlled toggle for things like keeping pivots visible all the time (when things are selected, obv), or for having handles always clustered at the pivot (for users who don’t like handles at the edges, ever). This puts the onus on those who are interested in seeing pivots and pivot-centered transform handles to set the toggle appropriately.
Keeping Studio in control of the “toggle” and placing the onus on users who want the new functionality to find the visibility toggle(s) seems like a possible way forward. Eventually, the “pivots always visible” flag, etc. might be done away with when a majority of users are acclimated to the feature. Anyway. Food for thought/discussion.
For us the first order of business is to separate potential bugs from behavior that is intended, but not what devs expect/want. If a model’s pivot is being placed incorrectly then we need to know how/why; if the pivot not re-centering after a new part is added is unexpected or unwanted, we need to explore whether that design choice makes sense.
All the feedback here is extremely helpful, and I appreciate those we’ve reached out to in DMs for their additional feedback there as well.
For those that are curious, I learned that an issue with it is that when you make changes inside of a model, the pivot does not get adjusted. I pressed alt to click a brick inside of a model and resized it, and the pivot did not adjust. Same for pasting something into a model.
I was probably wrong about the PrimaryPart, but that could be a different problem entirely.
If you have a PrimaryPart set then the pivot “follows” the PrimaryPart. If you don’t have a PrimaryPart set then only moving the model as a whole moves the pivot. You can choose which behavior by setting or not setting the PrimaryPart.
My problem with this is how this wasn’t how it worked before. It used to be where it would automatically re-center itself within the model if you moved parts around.
I don’t use PrimaryParts unless the model is completely wacky and off-center so its frustrating to have to frequently re-center the pivot every time i make a change to parts within a model.
That’s why I’m advocating for a button to turn it off similar to attachments and welds so that its not so impractical for people that aren’t going to use this feature.
