(*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.
