"Formed" Pivots do not Reset

Reproduction Steps
If using a model with a nested items, the pivot becomes “Formed” around the entirety of the model and does not reset when one or more of the nested items is removed. Because of this, you can get pivots that seem to act inside out, where you resize in a direction, and yet the size increases opposite to the way you’re dragging.

Expected Behavior
When a model takes a massive change, the pivot should be re-formed around it.
If there is a nuanced workflow being protected as a reason why the pivot doesn’t do this, I’d at least pivot this bug into requiring a feature request for having the ability to have pivots automatically update.

Actual Behavior
As can be seen, the Resize tool acts erratically.

The Move tool does not suffer from this behavior.
The model featured in the video is here.

Workaround
The pivot can be fixed by pressing the Reset option in the Pivot Tab.

Issue Area: Studio
Issue Type: Performance
Impact: Moderate
Frequency: Often
Date First Experienced: 2022-01-13 00:01:00 (-08:00)
Date Last Experienced: 2022-01-23 00:01:00 (-08:00)

7 Likes

How would you detect a “massive change”? If my pivot kept resetting every time I made changes to a model while working I would be extremely frustrated. It’s simple enough for you to recognize the pivot is wrong and for you to fix it yourself.

It is curious that it inverts like that though, not sure if that could be considered a bug.

3 Likes

If the pivot is outside of the bounding box of the model, I’d say that’s a massive change.

As well, the fact that the resize gets inverted at the very least is a bug. If I resize +X, I shouldn’t see it resizing towards -X.

Honestly the most user friendly case would be to have the pivot always in the direct middle of the group and whenever a change is made, continually update the pivot to the middle of the group, unless the user set a pivot point ahead of time. But that’s my 2 cents.

2 Likes


Yeah, that is a problem.
Notice how with the two parts in the model it will shrink toward one side when ctrl or shift aren’t used, but with only one part in the model it reverts to that “extrude” behavior that parts have and the ctrl and shift wont let you scale toward the pivot.

Anyway. Have to run out for a min. I’ll add some more when I get back.

3 Likes

With a noncentral pivot this is the behavior I would expect

1 Like

Looks like scaling is still a work-in-progress. That said, this still shouldn’t be the behavior we expect. If there are two parts in the model, then it scales like a model usually does (doesn’t do the extrude thing that parts do). In other words, it scales the model uniformly toward/away from the other side. Holding ctrl scales it from the centroid (calculated combined center of all the parts) because pivot scaling isn’t implemented yet. Even when you move both parts way to one side of the pivot, the pivot is still included in the scale and is included in the centroid calculation (not in the above video).

When there is only one part in the model, the model-like behavior breaks down. The scaling behavior shifts to that extrude thing we get with parts. The model begins to behave like it’s a part, only the pivot is out of place unless you hit reset. You’ll notice that the pivot isn’t included in the centroid calculation like it is with two parts. The far side scale dot moves from the pivot to the side of the remaining part.

The Model bounds should also include the pivot, as GeorgeTheDeveloper noted. But, the scale dots should def include the pivot when there is one part in the model if it’s going to do that when there’s more than one part in the model.

Edit: See vid

I’ve been trying to figure out why people are losing their minds over what seems like a great update. These kinds of things haven’t been popping up in my usual workflow.

Edit again:
The inverted resize in George’s vid is due to having the World Pivot Orientation set at (0, 180, 0), in case that was puzzling anyone else.

1 Like

I think an in-between would be the solution here. Automatically doing it in every case would be annoying. Not doing anything in every case would be annoying.

What about if it only “reset” if a user didn’t set a custom pivot and was relying off of the automatic behavior?

1 Like

Thanks for the report! Filed an internal ticket!

2 Likes

This is expected behavior: Pivots don’t try to second-guess you, the pivot will remain in the same place unless it moves along with a model movement or you explicitly edit it using the Pivot Editor.

The intended workflow is to use the “Reset Pivot” button in the model tab if you want to return a model to having a reasonable centered “default” pivot. Doing so only takes a single mouse click so it should not be a workflow disruption to explicitly use it when you make “massive change”.

1 Like

This topic was automatically closed after 6 days. New replies are no longer allowed.