Page MenuHome

Transform object origins (adjusting origins, not the data)
Closed, ResolvedPublic

Tokens
"Love" token, awarded by Tetone."Love" token, awarded by symstract."Like" token, awarded by MJunk."Love" token, awarded by Zino."Love" token, awarded by kioku."Love" token, awarded by amonpaike.
Authored By

Description

Currently if you want to move the origin on an object, the only way of doing this is setting the origin. This has some limitations.

  • It only works for translation (not rotation or scale).
  • When applied to multiple objects at once, it assumed they should all have the same origin.
  • It doesn't have useful transform features such as snapping.

This task proposes to add the ability for transform to have the ability only to move the origins.

Internally this means the objects are transformed as useual, the object data has the reverse transformation applied.

Open topics:

  • What should this be called?
  • How should objects be handled which have no object data? (lamps, cameras, speakers & objects whos data is linked from another blend file).
  • Just moving the object centers wont give much visual feedback.

    We could temporarily enable the object-axis display so there is visible feedback - especially for rotate/scale.

Details

Type
To Do

Event Timeline

Campbell Barton (campbellbarton) changed Type from Bug to To Do.
Campbell Barton (campbellbarton) triaged this task as Normal priority.

Man, you have no idea how many people will be happy with this feature. Be able to directly transform the origin is a long time dream of millions. lol

I'm gonna strike my vote for the simplest implementation possible, just a checkbox called "Origin" in the tool settings. When checked it transforms the origin, and unchecked we're back in regular transform mode.

And finally, I hope we can have an option for the transform gizmo to not disappear when we are moving it.

Discussed various names on Blender.chat with @Campbell Barton (campbellbarton)

Currently this is how we think we will call it:

Affect Only Location is the old Only Origins. (Affect Only Location is a more descriptive name anyway for this)
Affect Only Origins would be the new option to actually only move the origin.

We have to change the name of the old Only Origins, otherwise there will be a naming clash.

Later on, there could also be an option to do the opposite, basically leaving the origin in place and only transforming the object data:

Whoa, that's over complicated and hidden imo. I thought it was meant to be a function of the transform tools.

Oh well...

@ThinkingPolygons (ThinkingPolygons) technically, it must be a feature of the transform operator. Even when you use gizmos in Blender, you are still using the transform operator.

Obviously in the UI we could limit this option to the transform gizmo tools, but then users would not be able to use shortcuts (G, R, S) to do this operation with the default Blender keymap.

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)

will it work in edit mode too or this is for object mode only??

Transforming origin (which should finally be named pivot BTW!!!) is quite frequent operation, so the workflow definitely should not be as clumsy as a checkbox inside a popover. I honestly think it should be a mode. There is edit (geometry) mode, which when enabled, moves contents of the object without affecting pivot. There should be "Edit pivot mode" which would do the opposite, and could be jumped in and out of the same way edit mode can.

Pivot editing also should not work objects that do not have object data. It should generally work only on meshes, curves and such. Basically on things where pivot placement actually makes sense. Please do not try to reinvent a wheel here in any way. The common DCCs out there such as Max and Maya do this essential thing more or less right. Don't try to be unique for sake of Blender and come up with inferior solution.

@Ludvik Koutny (rawalanche) It doesn't make a lot of sense to introduce an entire mode just to be able to transform the pivot. That mode would not have any tools or features, other than the single ability to transform origins.

As for the name, Blender's lingo for this concept is origin. Some apps call it the pivot point, but in Blender, Pivot Point means something else. It's really not within the scope of this feature or task to discuss the overall naming convention of what we call the origin in general.

For that, see T56648: Blender 2.8: Naming Conventions or you can discuss it separately on Devtalk or Rightclickselect.

Just for information, here is an interesting addon: BS Modify Pivot Addon

@xan2622 (xan2622) that addon is a hack, using hacky panels, temporary empty objects and clumsily requires users to 'commit pivot' for every change.

It's not a good reference for this feature.

@Ludvik Koutny (rawalanche) It doesn't make a lot of sense to introduce an entire mode just to be able to transform the pivot. That mode would not have any tools or features, other than the single ability to transform origins.
As for the name, Blender's lingo for this concept is origin. Some apps call it the pivot point, but in Blender, Pivot Point means something else. It's really not within the scope of this feature or task to discuss the overall naming convention of what we call the origin in general.
For that, see T56648: Blender 2.8: Naming Conventions or you can discuss it separately on Devtalk or Rightclickselect.

So... There's a ton of modes and modal operators already in Blender...

The main point here is that it needs to work while switching transform tools. For example you want to be able to:

  1. Enable pivot editing
  2. Move pivot
  3. Snap pivot
  4. Switch to rotate tool
  5. Rotate pivot
  6. Switch to move tool
  7. Move pivot some more
  8. Exit pivot editing.

If it was property of a transform tool then what happens when you keep switching between multiple transform tools?

Also, the naming really *is* within the scope of this task. It's very frustrating that everyone constantly discusses the same feature here using two different words. Ask pretty much any 3D artist who's vocabulary has not yet been damaged by usage of Blender what Pivot is, and nearly 100% of them will describe what origin is in Blender. The rename really needs to happen asap so we can at least discuss all the subsequent tasks related to pivot/origin without confusion.

So far every change to align Blender more with the other industry tools has been very beneficial. No reason to make an exception here.

after thinking about this a bit - wouldn't it make sense to unify this with the 3d cursor workflow?
I mean setting the origin shares a lot (like all?) with how you'd want to set the 3d cursor. Snapping to geometry, align it to faces/edges, move to components, align to a transform, place by setting its values etc.

The 3d cursor workflow is still a bit clunky, as it has no gizmo version and just feels very different than the common move/grab behaviour (for example you need to start the transform modal with a click-drag).
So this would need some improvements/changes of the current 3d cursor workflow. In my mind both should work pretty much the same.

To me the 3d cursor is just a 'working' origin anyways - which is nice, because more often than not I dont want to change the actual origin just for editing convenience.

@Ludvik Koutny (rawalanche) since this is a general pivot option, you could enable it and switch between the transform tools freely to move the origin aound as you wish.

@Ludvik Koutny (rawalanche) since this is a general pivot option, you could enable it and switch between the transform tools freely to move the origin aound as you wish.

Alright. I will wait and see what you come up with. Just keep in mind that in general, pivot editing needs to be fluid process. Nothing that should require more than one step to get in and out of.

@Benjamin Sauder (kioku) I can't see how the 3d Cursor is relevant. You can already snap the origin to the 3D Cursor, which is fine, but not a very nice general way to offset the origin. It's slow and overly convoluted. That's why we have so many requests for being able to just transform the origin directly.

oh thats really not what I was after - the workflow to set the origin via the 3d cursor is not great I agree!

My point was more about how you'd use the 3d cursor while modeling - there it's really just a working origin / pivot. I mean in the end to change the origin you will somehow move and/or rotate a thing in space, just as you would do with while placing the 3d cursor. So to me these operations are basically the same.

basically something along the lines like this should do the job for both applications:
https://devtalk.blender.org/uploads/default/optimized/2X/8/8d160934845e463ba6b63dd44263cbe26ebea0b2_2_1035x558.gif

Campbell Barton (campbellbarton) closed this task as Resolved.EditedFri, Aug 23, 11:35 PM

Thanks for all the feedback,
Committed rBacdb14d264c8b4eced645673f8ae8af1a96b1a90

@xan2622 (xan2622) that addon is a hack, using hacky panels, temporary empty objects and clumsily requires users to 'commit pivot' for every change.
It's not a good reference for this feature.

The way you put it sounds pejorative to the creator.

It uses the python API therefore it's a macro not a hack.

Very disappointing implementation:

  1. It's very clunky to access (2 clicks)
  2. There's absolutely no visual indication that you are in the pivot editing mode, so if you use hotkey to switch it, you have to cycle the state to make sure you are in or out of the pivot editing mode. This is big issue in many areas of Blender. Often you have no idea which state you are in, so you first need to do an error and then correct it by undoing, rather than having an indicator of the current state to prevent erroneous action.
  3. The most important feature, being able to snap the pivot does not work. It can't be snapped to the vertices in object mode for example.
  4. Affect origins and affect locations options can be used together. What sense does that make?
  5. Not working in edit mode.

EDIT:
Solution:

  1. It needs to be decoupled from the "Pivot Point" popover (Which is incorrectly named pivot point, and should be renamed to something like action center)
  2. It should have its own 3D viewport header button, with no popover, just state button, which toggles the pivot edit mode. So it turns blue when you are in the mode, therefore you have an indication. This would also make it more accessible (1 click)
  3. It should work in edit mode too
  4. It should work with snapping


This would solve most of the issues:

  1. Such frequently used operation would no longer be so hidden.
  2. It would have industry standard naming so users would not need to use google to find out how to perform such a basic tasks.
  3. Users would have constant indicator of if they are in or out of the pivot editing mode.
  4. There would be clear distinction from the manipulator centers. Those define HOW to transform. Pivot Edit mode defines WHAT to transform. Those are two very different use cases that can't be mixed.

Again, please stop trying to be unique just for the sake of Blender and get this right. The more basic the feature is, the more straightforward it should be to use. There is no need to artificially add complexity to the usage of basic tools.

We could add a visual indication to show it’s enabled. For example, we could make the origins more prominent.

@Ludvik Koutny (rawalanche) I have no idea what you mean by ‘unique’. The old method involving the 3D cursor was unique. This direct method is what virtually all other DCCs do. So the previous approach was the unique one.

As for other missing features like better snapping or ability to work in more modes, those are just that - missing features in the initial implementation.

Very disappointing implementation:

I followed the proposal from @William Reynish (billreynish) which seems reasonable.

We can always extend initial basic functionality.

  1. It's very clunky to access (2 clicks)

Only a single click-drag is needed on the pivot, release over the "Origin" checkbox, this is the case for all toggles in popovers.

  1. There's absolutely no visual indication that you are in the pivot editing mode, so if you use hotkey to switch it, you have to cycle the state to make sure you are in or out of the pivot editing mode. This is big issue in many areas of Blender. Often you have no idea which state you are in, so you first need to do an error and then correct it by undoing, rather than having an indicator of the current state to prevent erroneous action.

We can see how this goes, by this reasoning we would have to move many options in front of the user which takes screen space.

  1. The most important feature, being able to snap the pivot does not work. It can't be snapped to the vertices in object mode for example.

This has been fixed.

  1. Affect origins and affect locations options can be used together. What sense does that make?

Although it would be rare, there are times it could be useful.

  1. Not working in edit mode.

This was not planned, as with many features it could be supported.

We could add a toggle for this also in the Tool Settings header, like we do for X Mirror and Auto Merge. It’s not entirely unreasonable. We’d need an icon for it though.

As for the name of Pivot vs Origin: IMO this is off-topic. Obviously this must be consistent throughout Blender, and renaming all uses of Origin to Pivot causes a naming clash with the existing Pivot Point controls, which then also needs a new name. It can be done, but this should be discussed separately elsewhere, ie in the Naming Conventions task.

it could have self snapping or alignment to vert,edge and face normals and possibility to create a custom orientation when orientation change, not sure if it's possible with current implementation.......... but like you said these are additional advanced features request to make it more useful.

  1. It should have its own 3D viewport header button, with no popover, just state button, which toggles the pivot edit mode. So it turns blue when you are in the mode, therefore you have an indication. This would also make it more accessible (1 click)

Exactly. I was expecting it to be a toggle in the header too. It can't be hidden like that.

Very disappointing implementation:

I followed the proposal from @William Reynish (billreynish) which seems reasonable.
We can always extend initial basic functionality.

  1. It's very clunky to access (2 clicks)

Only a single click-drag is needed on the pivot, release over the "Origin" checkbox, this is the case for all toggles in popovers.

  1. There's absolutely no visual indication that you are in the pivot editing mode, so if you use hotkey to switch it, you have to cycle the state to make sure you are in or out of the pivot editing mode. This is big issue in many areas of Blender. Often you have no idea which state you are in, so you first need to do an error and then correct it by undoing, rather than having an indicator of the current state to prevent erroneous action.

We can see how this goes, by this reasoning we would have to move many options in front of the user which takes screen space.

  1. The most important feature, being able to snap the pivot does not work. It can't be snapped to the vertices in object mode for example.

This has been fixed.

  1. Affect origins and affect locations options can be used together. What sense does that make?

Although it would be rare, there are times it could be useful.

  1. Not working in edit mode.

This was not planned, as with many features it could be supported.

  1. I did not mean actual action, but getting in and out of mode. Anyone who is familiar with rapid modeling workflows knows that getting in and out of the pivot edit mode needs to be fast. It can be hotkeyed, and I will be using a hotkey, but many people won't, and for those it should still be accessible faster. The main idea here is that "Edit Pivot" is a basic feature user should not be required to perform a google search to find how to perform.
  1. No reasoning needs to be absolute, but should be combined with common sense. Visual indicator for mode makes sense for features that are used quite frequently, and at the same time do not shows any visual signs of change when activated and deactivated. For example "affect origins only" doesn't fall in this category, because while it also doesn't show any direct sign of change, it's not a frequently used feature.
  1. Such as...?
  1. If there's no valid reason it should *not* be supported, then why not support it?

We could add a visual indication to show it’s enabled. For example, we could make the origins more prominent.
@Ludvik Koutny (rawalanche) I have no idea what you mean by ‘unique’. The old method involving the 3D cursor was unique. This direct method is what virtually all other DCCs do. So the previous approach was the unique one.
As for other missing features like better snapping or ability to work in more modes, those are just that - missing features in the initial implementation.

By unique I mean the weird concept of somehow combining its functionality with the "pivot" popover. Currently this popover defines how things should be moved, while pivot editing mode defines what is moved.

We could add a toggle for this also in the Tool Settings header, like we do for X Mirror and Auto Merge. It’s not entirely unreasonable. We’d need an icon for it though.
As for the name of Pivot vs Origin: IMO this is off-topic. Obviously this must be consistent throughout Blender, and renaming all uses of Origin to Pivot causes a naming clash with the existing Pivot Point controls, which then also needs a new name. It can be done, but this should be discussed separately elsewhere, ie in the Naming Conventions task.

  1. The problem here is that the tool settings both in properties panel and in the sidebar is something that is almost always hidden. Addons utilities often use the sidebar, so I rarely have tool settings open there, and properties panel has another more than dozens of tabs. The state of pivot editing needs to be visible on the most persistent UI location, which is the viewport header. That one is sticky, and can't be occupied by being switched to other tab. It's very rare that when I am modeling, I have sidebar at the "Tool" tab, and Properties panel is completely different editor which goes away when you maximize 3D viewport for example. The header is really the only sensible place here.

As for the naming. Yes I know it's not the topic of this task, but the longer it goes unfixed the more confusing debates will be any time anything pivot/origin related is discussed in any future tasks.

currently does not work on texts

  1. It needs to be decoupled from the "Pivot Point" popover
  2. It should have its own 3D viewport header button,

My thoughts exactly when I saw the implementation.
It clearly needs to be a direct toggle in the header like in most 3d apps.

@Campbell Barton (campbellbarton) could the option be added to the pivot point menu?
It would make it easier to access regardless of making sense or not.

I'm in favor of setting top-level transformation modes (move selection, move origins, move cursor, etc) with an operator enum property. It would let us use operator enum pies for quick adjustments and it'd work well with the active tool system (tool settings header), but It wouldn't solve the problem of general header/header popover integration. It would put the features in predictable places, though, which should satisfy most users.

The main problem I see with using operator enum pies is keymap integration. We could move the transform resets to a combined menu on something like Alt + W and use Alt + G and Alt + R for the pies, but that kind of change would probably ruffle some feathers. It plays into a modifier key paradigm that I like, but it isn't consistent across Blender's default keymap.

@Ludvik Koutny (rawalanche) You have made your point and it's fine to be critical of changes, however I don't find your tone very pleasant.

We are all tying to make Blender better, sometimes we make changes in increments, first supporting functionality, then adjusting design as necessary.

  1. I did not mean actual action, but getting in and out of mode. Anyone who is familiar with rapid modeling workflows knows that getting in and out of the pivot edit mode needs to be fast. It can be hotkeyed, and I will be using a hotkey, but many people won't, and for those it should still be accessible faster. The main idea here is that "Edit Pivot" is a basic feature user should not be required to perform a google search to find how to perform.

You're points are taken, however I like to get feedback from multiple users.

  1. No reasoning needs to be absolute, but should be combined with common sense. Visual indicator for mode makes sense for features that are used quite frequently, and at the same time do not shows any visual signs of change when activated and deactivated. For example "affect origins only" doesn't fall in this category, because while it also doesn't show any direct sign of change, it's not a frequently used feature.

It's possible this feature isn't used as frequently as you assume. There is no great harm in waiting for feedback from multiple users.

  1. Such as...?

Moving object centers apart (by scaling), without it changing the scale.

  1. If there's no valid reason it should *not* be supported, then why not support it?

Object mode options are used, when in edit-mode some of them aren't accessible. If exposed in edit-mode, that should be addressed.

It would also need to be supported by the undo system which currently only stores mesh data (and won't properly track object level transformations).

Since this task is marked resolved and there are further changes that could be made to transforming origins, I've created a new task T69132: Transform object origins design task, including some suggested made here.

As for the name of Pivot vs Origin: IMO this is off-topic.

You cannot rename pivot and origin because they are different things.
Pivot - is a decorative coordinate system, that is built ontop and hides origin in max and maya.
It is like 3d cursors, that are binded to every object to display their transformation points, to avoid instances problems))

Maya and max still doesnot have 3D cursor, so they made such compelled solution.

This comment was removed by Paul Kotelevets (1D_Inc).
This comment was removed by Paul Kotelevets (1D_Inc).