Transform object origins (adjusting origins, not the data) #69003

Closed
opened 2019-08-21 18:14:35 +02:00 by Campbell Barton · 49 comments

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.

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.*
Campbell Barton self-assigned this 2019-08-21 18:14:35 +02:00
Author
Owner

Added subscriber: @ideasman42

Added subscriber: @ideasman42

Added subscriber: @ThinkingPolygons

Added subscriber: @ThinkingPolygons

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.

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.

Added subscriber: @WilliamReynish

Added subscriber: @WilliamReynish

Discussed various names on Blender.chat with @ideasman42

Currently this is how we think we will call it:

Screenshot 2019-08-21 at 19.09.10.png

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:
Screenshot 2019-08-21 at 19.12.30.png

Screenshot 2019-08-21 at 19.14.07.png

Discussed various names on Blender.chat with @ideasman42 Currently this is how we think we will call it: ![Screenshot 2019-08-21 at 19.09.10.png](https://archive.blender.org/developer/F7682226/Screenshot_2019-08-21_at_19.09.10.png) **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: ![Screenshot 2019-08-21 at 19.12.30.png](https://archive.blender.org/developer/F7682271/Screenshot_2019-08-21_at_19.12.30.png) ![Screenshot 2019-08-21 at 19.14.07.png](https://archive.blender.org/developer/F7682296/Screenshot_2019-08-21_at_19.14.07.png)

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

Oh well...

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

@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)

@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)

Added subscriber: @Znio.G

Added subscriber: @Znio.G

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

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

Added subscriber: @Rawalanche

Added subscriber: @Rawalanche
Contributor

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.

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.

Added subscriber: @kioku

Added subscriber: @kioku

Added subscriber: @ThatAsherGuy

Added subscriber: @ThatAsherGuy

@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 #56648 (Blender 2.8: Naming Conventions) or you can discuss it separately on Devtalk or Rightclickselect.

@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 #56648 (Blender 2.8: Naming Conventions) or you can discuss it separately on Devtalk or Rightclickselect.

Added subscriber: @xan2622

Added subscriber: @xan2622

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

Just for information, here is an interesting addon: [BS Modify Pivot Addon ](https://blenderartists.org/t/bs-modify-pivot-addon-release/694962/17)

@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.

@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.
Contributor

In #69003#759465, @WilliamReynish wrote:
@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 #56648 (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.

> In #69003#759465, @WilliamReynish wrote: > @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 #56648 (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.

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.

@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.

@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.
Contributor

In #69003#759822, @WilliamReynish wrote:
@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.

> In #69003#759822, @WilliamReynish wrote: > @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.

@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.

@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:
8d16093484_2_1035x558.gif

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
Author
Owner

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Author
Owner

Thanks for all the feedback,
Committed acdb14d264

Thanks for all the feedback, Committed acdb14d264

In #69003#761437, @ideasman42 wrote:
Committed acdb14d264

Great. Will it support snapping in the future?

> In #69003#761437, @ideasman42 wrote: > Committed acdb14d264 Great. Will it support snapping in the future?

Added subscriber: @jeacom

Added subscriber: @jeacom

In #69003#759624, @WilliamReynish wrote:
@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.

> In #69003#759624, @WilliamReynish wrote: > @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.
Contributor

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

image.png
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.

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 ![image.png](https://archive.blender.org/developer/F7701464/image.png) 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.

@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.

We could add a visual indication to show it’s enabled. For example, we could make the origins more prominent. @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.
Author
Owner

In #69003#761596, @Rawalanche wrote:
Very disappointing implementation:

I followed the proposal from @WilliamReynish 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.

> In #69003#761596, @Rawalanche wrote: > Very disappointing implementation: I followed the proposal from @WilliamReynish 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. > 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. 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. > 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. This has been fixed. > 4. 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. > 5. 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.

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.

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.

Added subscriber: @TheRedWaxPolice

Added subscriber: @TheRedWaxPolice

In #69003#761596, @Rawalanche wrote:
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)

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

> In #69003#761596, @Rawalanche wrote: > 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) Exactly. I was expecting it to be a toggle in the header too. It can't be hidden like that.
Contributor

In #69003#761606, @ideasman42 wrote:

In #69003#761596, @Rawalanche wrote:
Very disappointing implementation:

I followed the proposal from @WilliamReynish 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.

  2. 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.

  3. Such as...?

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

> In #69003#761606, @ideasman42 wrote: >> In #69003#761596, @Rawalanche wrote: >> Very disappointing implementation: > > I followed the proposal from @WilliamReynish 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. > >> 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. > > 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. > >> 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. > > This has been fixed. > >> 4. 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. > >> 5. 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. 2. 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. 4. Such as...? 5. If there's no valid reason it should *not* be supported, then why not support it?
Contributor

In #69003#761605, @WilliamReynish wrote:
We could add a visual indication to show it’s enabled. For example, we could make the origins more prominent.

@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.

> In #69003#761605, @WilliamReynish wrote: > We could add a visual indication to show it’s enabled. For example, we could make the origins more prominent. > > @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.
Contributor

In #69003#761614, @WilliamReynish wrote:
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.

> In #69003#761614, @WilliamReynish wrote: > 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.

Added subscriber: @nokipaike

Added subscriber: @nokipaike

currently does not work on texts

currently does not work on texts

In #69003#761596, @Rawalanche wrote:

  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.

> In #69003#761596, @Rawalanche wrote: > 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. ](https://blenderartists.org/t/2-81-development-ui-ux/1172745/186?u=thinkingpolygons) It clearly needs to be a direct toggle in the header like in most 3d apps.

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

image.png

@ideasman42 could the option be added to the pivot point menu? It would make it easier to access regardless of making sense or not. ![image.png](https://archive.blender.org/developer/F7701816/image.png)

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.

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.
Author
Owner

@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.

In #69003#761641, @Rawalanche wrote:

  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).

@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. > In #69003#761641, @Rawalanche wrote: > > 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. > 2. 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. > 4. Such as...? Moving object centers apart (by scaling), without it changing the scale. > 5. 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).
Author
Owner

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

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

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc

In #69003#761614, @WilliamReynish wrote:

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.

> In #69003#761614, @WilliamReynish wrote: > 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 @1D_Inc

*This comment was removed by @1D_Inc*

This comment was removed by @1D_Inc

*This comment was removed by @1D_Inc*
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
12 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#69003
No description provided.