Transform object origins (adjusting origins, not the data) #69003
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
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
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
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
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
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#69003
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
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.
Added subscriber: @ideasman42
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.
Added subscriber: @WilliamReynish
Discussed various names on Blender.chat with @ideasman42
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:
![Screenshot 2019-08-21 at 19.12.30.png](https://archive.blender.org/developer/F7682271/Screenshot_2019-08-21_at_19.12.30.png)
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)
Added subscriber: @Znio.G
will it work in edit mode too or this is for object mode only??
Added subscriber: @Rawalanche
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: @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.
Added subscriber: @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.
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:
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.
@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.
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.gifChanged status from 'Open' to: 'Resolved'
Thanks for all the feedback,
Committed
acdb14d264
Great. Will it support snapping in the future?
Added subscriber: @jeacom
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:
EDIT:
Solution:
This would solve most of the issues:
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.
I followed the proposal from @WilliamReynish which seems reasonable.
We can always extend initial basic functionality.
Only a single click-drag is needed on the pivot, release over the "Origin" checkbox, this is the case for all toggles in popovers.
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.
This has been fixed.
Although it would be rare, there are times it could be useful.
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.
Added subscriber: @TheRedWaxPolice
Exactly. I was expecting it to be a toggle in the header too. It can't be hidden like that.
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.
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.
Such as...?
If there's no valid reason it should not be supported, then why not support it?
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.
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
currently does not work on texts
My thoughts exactly when I saw the implementation.
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.
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 useAlt + G
andAlt + 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.@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.
You're points are taken, however I like to get feedback from multiple users.
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.
Moving object centers apart (by scaling), without it changing the scale.
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 #69132 (Transform object origins design task), including some suggested made here.
Added subscriber: @1D_Inc
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