Page MenuHome

Transform object origins design task
Open, NormalPublic

Description

Recently the ability to transform object origins was added.

Transforming objects while adjusting their object-data so only the origins move.

This design task is to plan further changes, see T69003: Transform object origins (adjusting origins, not the data) for the previous task.

TODO's

  • Support shape keys (mesh, curve & lattice).
  • Support grease pencil object data. (Need to investigate grease pencil parenting and animation, if this needs special handling).
  • Support image empties (Constrained to 2D).
  • Support text objects. (Constrained to 2D, Only translation/scale can be supported, not rotation).
  • Support mesh multi-res data.
  • Collection Instances (Only translation can be supported).

Other Possible Improvements

UI

Since this is new, we have to see how often users will access it.

Details

Type
Design

Event Timeline

Campbell Barton (campbellbarton) triaged this task as Normal priority.
Campbell Barton (campbellbarton) renamed this task from Transform object origins design task (additional features) to Transform object origins design task.Sun, Aug 25, 3:03 AM

hey @Campbell Barton (campbellbarton) .I mentioned this in the other task hoping that it could be possible to implement with the current state, i know too many thing at hand........but if it's not possible for now then hopefully gets considered in future developements, when this feature is well used & tested.. i am sure many users including me will want them in one way or another, thanks.

it could have self snapping & alignment to vert,edge and face normals and the possibility to create custom orientation when orientation changes...

My personal take on the UI part.

Should it be displayed more prominently in the header - instead of using a popover?
if it doesn't change the functionality then sure why not, as to what William have said:

"By making it a generic transform option, you can do this with any way transforming is executed (via direct modal operator, via active tool gizmos, or via viewport gizmos).

Should it have it's own key shortcut?
it could, but something like the Annotation tool, where u can both hold 'D' & LMB for quick access or a single toggle for en(dis)able ...anyway is valid.

Should we display object centers differently when this is enabled?
ideally yes, right now there is no indication if u use it with a hotkey until you do the transformation.

Should it be displayed more prominently in the header - instead of using a popover?

Yes, please. This is basically a mode, it's important to see at a glance if we are in this mode or not.

Should it have it's own key shortcut?

Yes, and if possible a smart hotkey that we can press and hold to activate it and then release to turn it off. Quick and fast.
By the way, if this "hold" function could be a property of the keymap system, it would be amazing, so we could enable it on any hotkey in blender. Much needed feature imo.

Should we display object centers differently when this is enabled?

IMHO, nothing should change when this feature is enabled, and more, the gizmo also shouldn't change or disappear, it should remain the same when moving it, like: https://i.imgur.com/2MYuQ4W.gif

Thx.

I do think that it should have its shortcut

I do think it should be displayed in the header OR have some constant indication of if its enabled.

If the object axis is displayed constantly as long as the origin transform is enabled (not only during transform drag), then the top level header button would no longer be necessary, since the indication of the state would be taken care of. However the reason it should not be part of the "pivot" popover is that currently the "pivot" popover defines HOW things are transformed, while this mode defines WHAT is transformed.

The main goal is to make it as quickly accessible as possible.

What is the point of that?
What will happen if object have instance?

What is the point of that?
What will happen if object have instance?

simply the instances behave like the parent object .... if you move the pivot in the parent object it also moves in the instances, nothing changes from what it already happens, it's just a convenience at the user experience level.

What is the point of that?
What will happen if object have instance?

simply the instances behave like the parent object .... if you move the pivot in the parent object it also moves in the instances, nothing changes from what it already happens, it's just a convenience at the user experience level.

Well, here is a little problem))
A simple question for you, devs, to feel the difference between pivot and origin.

  • When applied to multiple objects at once, it assumed they should all have the same origin.

https://developer.blender.org/T69003#762011

So, I made 3 instances of 3 objects.
Selection contains all of them - which one should be the leader for changes? =)
Obviously, they CAN'T have origin in same location, as they are instances.

So what we supposed to get in that simple case?

What is the point of that?
What will happen if object have instance?

simply the instances behave like the parent object .... if you move the pivot in the parent object it also moves in the instances, nothing changes from what it already happens, it's just a convenience at the user experience level.

Well, here is a little problem))
A simple question for you, devs, to feel the difference between pivot and origin.

  • When applied to multiple objects at once, it assumed they should all have the same origin.

https://developer.blender.org/T69003#762011
So, I made 3 instances of 3 objects.
Selection contains all of them - which one should be the leader for changes? =)
Obviously, they CAN'T have origin in same location, as they are instances.
So what we supposed to get in that simple case?

This is not a new problem, if you set the "Origin to Cursor", the same issue exists.

As it happens though, you've picked an example which would work - with grabbing at least since the objects have no rotation or scale.

In the more general case of multiple instances which are rotated and scaled there is no right answer. We could...

  • Have an warning and ignore any instances.
  • Report an error and do nothing.
  • Pick one (this is what "Set Origin to Cursor" currently does).

That's why I called that example simple, but even it does not allow same origin location.
By the way, what we are fighting for?


Maya: well, we don't have a 3D cursor, so we will put a decorative masquerade called pivot ontop of origin of every object in a scene, hiding true location of objects from you, so you will never know where your object's location really is, so you will ask your local developers to write an addon, that will require moving objects to scene's 0,0,0 base, to reset both their origin and pivot, to provide abitities to rotate objects around single point like 3D cursor actually does, and fix that mess that follows all this stuff.


Blende: well, we already provide both truthful origin and 3D cursor, so both problems are not exist.
We always reject solutions, which creates more problems, than solves.


Blender 2.8: ... we can duplicate 3D cursor behaviour with a ... bunch of exceptions?

@Paul Kotelevets (1D_Inc) This is one of the most oft-requested features in Blender. In Blender, we never had a way to directly transform the origin - we could only snap it to certain pre-defined positions, one of them being the 3D Cursor. This was very clumsy, because you first had to snap the 3d Cursor to somewhere, and then snap the origin to it. Imagine if this was the only way you could do any normal transformation - by first placing the 3d Cursor somewhere and then snapping your object to it - that would be extremely tedious.

So, if your central argument is that nobody wants this and it's not useful, that's just not true at all on the face of it, and can be dismissed easily.

By the way, what we are fighting for?

Making Blender easier to use, and making it easier to accomplish basic tasks, such as moving the origin.

@Campbell Barton (campbellbarton) actually with the objects in instance this function has a strange behavior ... take a look at the gif ...

@noki paike (amonpaike) What's strange about that? That is normal and expected if you move the origin of an object with linked mesh data.

And, the same thing happens when you snap the origin to the cursor - it has nothing to do with this feature.

@William Reynish (billreynish)
I don't know ... What I would expect is that if I select and move the origin of one object it moves also the other point of origin of the instance not the geometry of the instance object ...

edit:
because I consider this new option to move the point of origin a sort of "edit position origin" and therefore we should move the point of origin to all the instances, as if the point of origin was also itself an edited instance, like the geometry.
then maybe I'm wrong ...

I guess the confusion here stems from the fact that Blender doesn't allow you to have linked mesh data between object while having object data unique.

In apps like 3ds Max it works as following: There's an object, which is sort of a container, and then there's mesh data, which is the actual mesh. If you instance mesh object, you are instancing just the mesh data, not the object data. And the pivot is part of the object data. So in 3ds Max for example, you can have dozen of instanced meshes with unique pivot for each.

In Blender, you can't do this. The Max way has some drawbacks too, but with some changes, Blender could well handle both if:

  1. The pivot/origin would be part of the object, not the mesh datablock
  2. When instancing object, both object container and mesh datablock would be instanced. In this case change of the pivot would affect all of the scene instances.
  3. User could optionally make object container "single user" without making the mesh datablock unique. This would allow the instanced meshes (which are stored in memory just once) have multiple unique pivots.

That would cover all possible workflows. It's just matter of pivot/origin being property of the object datablock, not mesh datablock.

After playing around with it for a bit - I do find it strange that it's not possible to snap the origin onto the object itself. For example if you have a wall module and want to snap the origin to the left bottom corner - you still have to use the 3d cursor, as you just can't snap to it.

After playing around with it for a bit - I do find it strange that it's not possible to snap the origin onto the object itself. For example if you have a wall module and want to snap the origin to the left bottom corner - you still have to use the 3d cursor, as you just can't snap to it.

Good point, added to the TODO list.

After playing around with it for a bit - I do find it strange that it's not possible to snap the origin onto the object itself. For example if you have a wall module and want to snap the origin to the left bottom corner - you still have to use the 3d cursor, as you just can't snap to it.

Good point, added to the TODO list.

Wait, wasn't that a bug that was just fixed? O_o

Of course one should be able to snap the pivot onto the geometry of object itself. That's the *main* use case for this.

That is not "Other possible improvement", jesus... That is the whole point this feature was requested in the first place.

Wait, wasn't that a bug that was just fixed? O_o
Of course one should be able to snap the pivot onto the geometry of object itself. That's the *main* use case for this.
That is not "Other possible improvement", jesus... That is the whole point this feature was requested in the first place.

Exactly. I tried this feature today, and I noticed that snapping was not working, then I thought it was a bug.
Funny yeah, because that's really the main purpose of this feature.
Hope it gets "fixed" soon.

Zino Guerr (Zino) added a comment.EditedSun, Aug 25, 6:37 PM

In T69132#762132, @benjamin (benjamin) Sauder (kioku) wrote:
After playing around with it for a bit - I do find it strange that it's not possible to snap the origin onto the object itself. For example if you have a wall module and want to snap the origin to the left bottom corner - you still have to use the 3d cursor, as you just can't snap to it.
Good point, added to the TODO list.

I guess i didn't explain it well when i said this.

self snapping

Also if you try to align the origin to vert/edge and face you still have to, enter edit mode ->select the vert.... -> create custom orientation-> cursor to selected-> exit edit mode-> origin to 3d cursor, still too many steps.

alignment to vert,edge and face normals and the possibility to create custom orientation when orientation changes...

it's not possible to snap the origin onto the object itself.

Yeah, that's the snapping I was talking about in the other thread. https://developer.blender.org/T69003#761484

@Paul Kotelevets (1D_Inc) This is one of the most oft-requested features in Blender.

Of course, it's not, snaps are, everybody knows that. People want to snap objects[[ https://www.youtube.com/watch?v=w_zJAlN6vqc | like that ]].

So, if your central argument is that nobody wants this and it's not useful, that's just not true at all on the face of it, and can be dismissed easily.

I see, a lot of people even don't know the difference between pivot and origin. What is the use of their requests?

Making Blender easier to use, and making it easier to accomplish basic tasks, such as moving the origin.

I've asked a simple question, and has got such an answer from a core developer:

  • Have an warning and ignore any instances.
  • Report an error and do nothing.
  • Pick one (this is what "Set Origin to Cursor" currently does).

So, you are about to write some nasty crutches just to make the same, that Blender already have... well, are you kidding us? ))

@Campbell Barton (campbellbarton) actually with the objects in instance this function has a strange behavior ... take a look at the gif ...

Wow, that's just briliant!
Guys, that may be not so obvious, but serious people makes serious projects in Blender, such messup is unacceptable in any way.

Like instances that just flew away)

It is not funny to built in untested addons into core. Such things have to stay as addons.

@Paul Kotelevets (1D_Inc): what is showed in that gif is not a 'messup' and is nothing new. The same happens when you use origin snapping in 2.79 and earlier, or in 2.80.

When you do a normal object transform, you are transforming the origin point.

When you offset the origin only, via direct transformation or by snapping to the 3d cursor or other items, what really happens is that you have a reverse transformation happening. The object is offset, and then the data (mesh, curve etc) is offset in the opposite direction. It would be the equivalent of moving an object by X amount, and then entering Edit Mode and moving the data back by -X amount.

So when you have two objects using the same data, what you see in the gif is expected - the origin in the 2nd object is stationary and the data moves. This is normal and expected.

It is not funny to built in untested addons into core.

This isn't an addon.

@Paul Kotelevets (1D_Inc): what is showed in that gif is not a 'messup' and is nothing new. The same happens when you use origin snapping in 2.79 and earlier, or in 2.80.

Yes, that mess was before, so you need to select instances of object to move their origins without moving objects in a space.
This issue continues to this day, and does not seem to be about to be corrected.

Anyway, most people only need this in order to finally get proper CAD snapping, which has been in any other software for decades.

Naturally, during modeling there is no need to move origin that often. But currently this is the only way to make proper snapping in Blender, that's why it is requested.

That's how it is supposed to be used:

https://www.youtube.com/watch?v=w_zJAlN6vqc

well then, one should add a todo to add the option of keeping instances in place if the origin is moved.

@Zino Guerr (Zino) once self-snapping is tackled, most of this should work just fine. Only thing I observed is that the orientation to a face is not great, it should do the same as the 3d cursor where it tries to align it in a sensible way (or the custom transform orientation).

well then, one should add a todo to add the option of keeping instances in place if the origin is moved.

Or block, in case if instanced model is a gamedev model, and it have to share same origin with it's LOD's?

@Paul Kotelevets (1D_Inc) Hey, instances moving when changing the original object's origin is an expected behavior, even in other 3d apps. https://i.imgur.com/D0oTnrX.gif
While it would be nice to have an additional option to not move the instances, this is not an issue at all.

in that gif is not a 'messup' and is nothing new. The same happens when you use origin snapping in 2.79 and earlier, or in 2.80.
When you do a normal object transform, you are transforming the origin point.

I would like to know why from time to time you and I don't understand each other on the fly.

With that gif, I made it - obvious - a behavior that is unexpected, useless and difficult to control, because before it simply was not possible to move points of origin as it has just happened now.

The one in the gif, is the pivot point / point of origin, that I can move only now, through this new feature, before it was not possible to work in this way.

What I have made evident is that now, with the instances, a mess happens, an unexpected behavior. If you move a point of origin of an object that has instances. normally we expect that all the points of origin of all the instances are moved and not the geometries, because we expect that this new function is a sort of "edit point of origin" inside "of the objects container."

I expect that it works like this, that I have been using blender for 20 years, imagine who comes from other worlds.

@Paul Kotelevets (1D_Inc) it seems that you are looking for better snapping tools, this has nothing to do with users wanting to change origins of objects freely without too many steps, some apps might do it differently because it's not related to parenting... and just as a pivot point.

ok i did other tests, and i have better understood the behavior ... usually i did these operations with an empy object ..

there is however to make possible and to differentiate the two modalities, because currently to move a pivot point, to set a new point of origin to an object, one expects that it is a sort of -editing-repositioning not a manipulator.

edit:
here is the case where you get confused, selecting all the objects in the instance, it behaves as you expect, but if we rotate the pivot points things happen that confuse

If you set your pivot point to Individual Origins and select all linked objects with Shift + L before transforming, it has the same effect as applying an object-space offset. We'll need to put more work into documentation/NUO if 2.81 ships without an auto-offset toggle, but I wouldn't be too worried about it in the short-term.

edit:
here is the case where you get confused, selecting all the objects in the instance, it behaves as you expect, but if we rotate the pivot points things happen that confuse

I guess that origin's location changes were solved for translation in 2.7x, but rotation is a new feature, so it has no compensation mechanism yet.

Thanks for all the tips and advice ...
But looking at a pragmatic way of using it, I hypothesize that most if not all the times, if I move the pivot point is because I want to move the center of gravity of the object and or instances, I don't want to make my instances acrobatics, I want my instances behave exactly the same as the first object ... if I want to do acrobatic animations, I use modifier arrays, or create links with an empty object or another object ... I certainly don't use this condition to move the pivot point in this way .
Of course if both options are available, so much the better, but I would prefer to have, for the sake of greater potential and rational use, instances that behave identically, that move geometry or points of origin and I would like to access this option more quickly and simple as possible ... on the other hand, this is why this new possibility of moving the point of origin was created.

Added support for snapping the origin onto the objects own geometry. rBdb851c78b4b391e4ddeb3350550a0da5194554fd


  • Have an warning and ignore any instances.
  • Report an error and do nothing.
  • Pick one (this is what "Set Origin to Cursor" currently does).

So, you are about to write some nasty crutches just to make the same, that Blender already have... well, are you kidding us? ))

also...

What I have made evident is that now, with the instances, a mess happens, an unexpected behavior. If you move a point of origin of an object that has instances. normally we expect that all the points of origin of all the instances are moved and not the geometries, because we expect that this new function is a sort of "edit point of origin" inside "of the objects container."

Without a unique pivot offset per object there are no clean solutions to this problem.

Since there seems to be such a high level of confusion around the behavior with instancing - It's probably better to disallow this situation entirely.


I guess that origin's location changes were solved for translation in 2.7x, but rotation is a new feature, so it has no compensation mechanism yet.

Rotation works, again - multiple instances are the problem here.


I guess the confusion here stems from the fact that Blender doesn't allow you to have linked mesh data between object while having object data unique.
In apps like 3ds Max it works as following: There's an object, which is sort of a container, and then there's mesh data, which is the actual mesh. If you instance mesh object, you are instancing just the mesh data, not the object data. And the pivot is part of the object data. So in 3ds Max for example, you can have dozen of instanced meshes with unique pivot for each.
In Blender, you can't do this. The Max way has some drawbacks too, but with some changes, Blender could well handle both if:

  1. The pivot/origin would be part of the object, not the mesh datablock
  2. When instancing object, both object container and mesh datablock would be instanced. In this case change of the pivot would affect all of the scene instances.
  3. User could optionally make object container "single user" without making the mesh datablock unique. This would allow the instanced meshes (which are stored in memory just once) have multiple unique pivots.

That would cover all possible workflows. It's just matter of pivot/origin being property of the object datablock, not mesh datablock.

Something like this could work, although this would need to be part of a larger change since it's has many implications.

Since there seems to be such a high level of confusion around the behavior with instancing - It's probably better to disallow this situation entirely.

Well, there are three ways of solving that

  • to disallow instance (Duplicate Linked) influence entirely
  • to think about every possible aspect, operating with origins.
  • or to bring "unique pivot for every object ontop of origin" system from maya, that also creates more problems with scene management than solves.

Can't say, that total disallow is nice, but, from our maya experience, it is way better than pivot solution.

Rotation works, again - multiple instances are the problem here.

Well, origin transform is compensated if all instances of object are selected (compensation includes parenting autofixing) - it allows to keep scene's visual appearance untouched.
Now we need rotation compensation the same way to make this tool work properly, as far as it's the only tool that provides origin rotation.
If we are following aspect thinking way, of course.

Without a unique pivot offset per object there are no clean solutions to this problem.
Since there seems to be such a high level of confusion around the behavior with instancing - It's probably better to disallow this situation entirely.

probably, if it is possible, it is better to make sure that the point of origin, is movable only for the selected object or more selected objects, even if they are instances ...

already now, if we select all the instantiated objects, and move the point of origin, it behaves as it should ...
it is only by selecting only one object, that their instances behave as acrobats ..

a practical case of functioning is that if I change the point of origin of an object, I don't necessarily want to change the point of origin of all the other instances ... and if I want to change the point of origin of other instances, well. . then I select them all ...

Added shortcut and use persistent axis display when enabled (not just when dragging).

Added shortcut

It's not possible to make the shortcut a one key press only? Ctrl-Period is kind of a tough combination imo.

@TheRedWaxPolice (TheRedWaxPolice) is that an actual question? Of course it’s possible. But obviously the keymap in Blender is fairly full, esp for single key shortcuts, and Ctrl-. has a connection to the pivot controls.

What would be more useful is if you propose a key shortcut that takes these things into account, and doesn’t clash or interfere with other shortcuts.

the keymap in Blender is fairly full

That's the issue. It's hard to propose a key for this, so I thought you guys would have a better idea of what keys are available.
Personally I would map it to whatever letter key is available. For example in c4d it's the letter L.
So for me it would be either L or maybe P, since those keys seems to do nothing in object mode?

what about 'grless' now it works for (German, Italian,French,Qwerty..etc) keyboards which wasn't possible in 2.7x, it's free AFAIK.

This is similar to pressing Ctrl-P to parent, from talking to artists in the studio, we think this is something accessed occasionally (similar to auto-merge for example).

There will always be some people using a feature frequently, I'd like to have this confirmed by artists in the studio before changing the shortcut.

This is similar to pressing Ctrl-P to parent, from talking to artists in the studio

Do you mean Blender animation studio?
I recently trying to figure out a workflow source in Blender development scheme.
It is needed for workflow protection - a lot of recent solutions do not stand up even to simple repetitive work, because they do not respect the principle of relevance, so huge amount of workflows has been corrupted in 2.8 because of no care.
Like milliseconds in the Olympic Games or Formula 1 races, such details become important only in the process of the hardest of possible workflow conditions.

Blender animation studio is marked as one of the main workflow sources with limited workflows range.

For example in c4d it's the letter L.

Well, why not.

This is similar to pressing Ctrl-P to parent, from talking to artists in the studio

Do you mean Blender animation studio?
I recently trying to figure out a workflow source in Blender development scheme.
It is needed for workflow protection - a lot of recent solutions do not stand up even to simple repetitive work, because they do not respect the principle of relevance, so huge amount of workflows has been corrupted in 2.8 because of no care.
Like milliseconds in the Olympic Games or Formula 1 races, such details become important only in the process of the hardest of possible workflow conditions.
Blender animation studio is marked as one of the main workflow source with limited workflows range.

Here's a typical example of something that was very difficult and slow to accomplish with the old 3D cursor origin workflow:

This applies in general. Pretty much all 2.8 improvements made Blender faster and easier to use. I can't think of one which made things harder/slower.

I have no complaints about origin transforms as long as it is still the Blender's origin system, not the decorative pivot system from Maya
(except some issues with instances behaviour).

Also, case from video is not difficult (made with duplicating vertex).

Also, origin's placement/rotation is still better in Sketchup: https://youtu.be/5a5WAPDwqB4?t=357
as far as it supports for 3-point alignment (B.A.S.E. proposal), so there is still a way to go)

I'm not against origin transformations, I am against such "got damn quick hurry" proposals, whose concept has not been tested or even well thought out.
Thanks to them, most of this "fresh and cool" stuff from 2.8 is already obsolete, like such origin transforms in compare with Sketchup realization.

Zino Guerr (Zino) added a comment.EditedWed, Aug 28, 1:52 AM

This is similar to pressing Ctrl-P to parent, from talking to artists in the studio, we think this is something accessed occasionally (similar to auto-merge for example).
There will always be some people using a feature frequently, I'd like to have this confirmed by artists in the studio before changing the shortcut.

i am with @Paul Kotelevets (1D_Inc) on this one .
i don't think you guys have Arch-viz or Hard-Surface Artists in the studio? those are the ones who use this frequently and maybe riggers occasionally......anyway the functionality is the one that matters the most not the hotkey.

i don't think you guys have Arch-viz or Hard-Surface Artists in the studio?

There is problem, that there is a big difference between professional Artist and professional Workflow Designer.
Artist pumps skill into the spinal cord, so his reflections are part of his body - he have an art is in priority, so he will accept solutions what software provides. And even allow all those unnecessary addons, just if they will give a little bit more speed.
WD pumps skill into the spinal cord, but he can break himself for better solution - he have a relevance and purity in priority, so he can define, what to get used to and what not to, even if it is painful.
Artist vs WD is a tactics vs strategy issue.

Anyway, WD it is a separate, deep and a very offtop theme.

Shouldn't the origin's "gizmo" have a fixed size like the regular axis gizmos? I find it weird that it shrinks with the object when I zoom out or gets bigger when zoom in... This doesn't happen in other softwares.

Also maybe they could share the same colors of the axis gizmo. Currently their colors are hardcoded, right?

Shouldn't the origin's "gizmo" have a fixed size like the regular axis gizmos?

They aren’t gizmos but indicators. The size is important because you can scale the origin.

Shouldn't the origin's "gizmo" have a fixed size like the regular axis gizmos?

They aren’t gizmos but indicators. The size is important because you can scale the origin.

Yeah, couldn't find a better word, hence the quotation marks lol...
But still feels a little weird, maybe because it's unusual to have an indicator like that, instead of just the regular gizmo, I guess.
Not a big deal tho, even though I wish we could turn off that indicator. And by the way, way not have an option to turn off that indicator, in the overlays?

I think the indicators are OK as they are,
while they're very obvious, I don't think this is an option you leave enabled often.

Opening someone elses file with this enabled while being disabled in the overlays will be confusing.

As well as this we already have many overlay options, so I'd only add more of it's really needed.

we already have many overlay options, so I'd only add more of it's really needed.

Yeah, I understand.
It's just a little weird not having it in the overlays popover, because when you turn off overlays completely by clicking in the "show overlays" button, the indicator disappears, giving the impression that this setting is somewhere in the overlays popover., which is a little confusing.

by clicking in the "show overlays" button

It have to. This button hides everything, including mesh in edit mode.
Another button, located near - "Show Gizmo" hides Gizmos, but leaves origin axis untouched, that shows, that it is not gizmo, but designation.
Also, it cannot be a Gizmo, as far as it isn't a manipulator.

Fixed size of this designation is done to represent object's scale - it allows you to see and control how much scaled object is.
This size, in fact, matters, and is counted in units of the scene.

@Paul Kotelevets (1D_Inc) The point is, is it an overlay or not? If it's not, then when I turn off the "show overlays" button, it shoudn't hide it, because the way I see it, this button is to turn off everything that is inside the popover. Hiding things that are not there is confusing.

this button is to turn off everything that is inside the popover.

Global "Show overlays" hides everything but faces. Point empty object and this designation have no faces so they are hidden.
Internal "Show overlays" checkboxes also don't hide mesh overlays entirely.
This designation is missing for internal checkboxes as its availability defines current mode - object editing or origin editing.
So, there is no way to get confused while opening someone's scene - you will see, if it will be turned off globally, or you will see if scene is in origin editing mode, even if all checkboxes are turned off.

It is an indicator - a mode depicting item.