Transform object origins design task #69132
Labels
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
16 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#69132
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
Note that this task is only intended to cover transform the object's origin. Changes to pivot point behavior aren't part of this task.
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 #69003 (Transform object origins (adjusting origins, not the data)) for the previous task.
TODO's
Other Possible Improvements
db851c78b4Currently disabled since the the geometry is assumed to be moving too - in the common case.
Since each data-blocks is isolated, these could be split between multiple processors.
UI
Since this is new, we have to see how often users will access it.
Currently object axis are temporarily enabled during transform.
Added subscriber: @ideasman42
Transform object origins design task (additional features)to Transform object origins design taskAdded subscriber: @Znio.G
hey @ideasman42 .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.
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:
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.
Added subscriber: @ThinkingPolygons
Yes, please. This is basically a mode, it's important to see at a glance if we are in this mode or not.
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.
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.
Added subscriber: @Rawalanche
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.
Added subscriber: @1D_Inc
What is the point of that?
What will happen if object have instance?
Added subscriber: @JulienKaspar
Added subscriber: @nokipaike
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.
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...
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?
Added subscriber: @WilliamReynish
@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.
Making Blender easier to use, and making it easier to accomplish basic tasks, such as moving the origin.
@ideasman42 actually with the objects in instance this function has a strange behavior ... take a look at the gif ...
@nokipaike 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.
@WilliamReynish
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:
That would cover all possible workflows. It's just matter of pivot/origin being property of the object datablock, not mesh datablock.
Added subscriber: @kioku
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.
Added subscriber: @Regnas
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.
I guess i didn't explain it well when i said this.
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.
Added subscriber: @benjamin-19
Yeah, that's the snapping I was talking about in the other thread. https://developer.blender.org/T69003#761484
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 .
I see, a lot of people even don't know the difference between pivot and origin. What is the use of their requests?
I've asked a simple question, and has got such an answer from a core developer:
So, you are about to write some nasty crutches just to make the same, that Blender already have... well, are you kidding us? ))
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.
@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.
This isn't an addon.
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.
@Znio.G 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).
Or block, in case if instanced model is a gamedev model, and it have to share same origin with it's LOD's?
@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.
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.
Added subscriber: @paul-124
@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
Added subscriber: @ThatAsherGuy
If you set your pivot point to Individual Origins and select all linked objects with
Shift + Lbefore 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.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.
db851c78b4also...
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.
Rotation works, again - multiple instances are the problem here.
Something like this could work, although this would need to be part of a larger change since it's has many implications.
Well, there are three ways of solving that
Can't say, that total disallow is nice, but, from our maya experience, it is way better than pivot solution.
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.
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 subscriber: @TheRedWaxPolice
It's not possible to make the shortcut a one key press only? Ctrl-Period is kind of a tough combination imo.
@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.
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.
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.
Well, why not.
Here's a typical example of something that was very difficult and slow to accomplish with the old 3D cursor origin workflow:
2019-08-27 12-14-20.mov
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.
i am with @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.
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.
2019-09-05_03-44-54.mp4
Also maybe they could share the same colors of the axis gizmo. Currently their colors are hardcoded, right?
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.
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.
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.
@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.
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.
Added subscriber: @Mets
Currently in transform origins mode, transform operations like resetting a transform with Alt+G/R/S, or snapping to the cursor, still moves the object. Is this a bug, or intended? Feels strange to me. How would I go about moving only the origin to the cursor?
Quit from editing origin mode to object mode, set origin - origin to 3d cursor.
Editing origin mode functionality does not replace the original object mode origin operations, just allow to perform faster some of them.
Yes. I was about to post the same thing. But I was waiting to see if it's a todo situation.
Except that I can do that in other apps.
For ultimate flexibility, the origin transform should have it's separate xyz parameters (tweakable) in the N panel/obect tab. Otherwise it feels like a bug/incomplete.
It's an average flexibility. For ultimate flexibility it need at least proper instances compensation mechanism and 2-point and 3-point aligning, like in other apps already for decades.
N-panel Parameters are available for 3D cursor, so it is the same issue, that was described by Mets.
No, it's not. 3d cursor and origin are two different things.
Positioning of them is the same thing.
Precise positioning of the origin is available through 3D cursor operation.
We shouldn't rely on 3d cursor for this, that's the whole point of having this origin transform feature.
3d cursor is a slow workflow.
I know. 3D cursor is a slow workflow, 3-point alignment is not available workflow at all.
As it have been told, this entire proposal is totally raw, hasty and incomplete.
Guys please, this proposal on devtalk makes a lot of sense:
https://devtalk.blender.org/t/not-so-good-design/9581/2
This is called a "research development". I make a lot of research development in sandbox, paying to python developers for making concepts of tools to test it's workflow before proposing them to the core.
You should not turn core development into research development.
It cannot be like "we want just to move origin", and then "please, just not like that, it have to be performed in other way".
Please, users, sit down for a month, think over an issue and arrange everything in one normal proposal, that takes into account everything at once. With all possible cases.
Then get criticism. Then redo everything if necessary, That's how it works, that's what powerful software is made of.
Someone, who was fighting so bravely for something here...
Added subscriber: @Russ1642
The transform box in the sidebar should operate only on the origin when in this mode. Otherwise there's no way to place the origin by keying in coordinates, other than the old method of keying in the 3d cursor coordinates and then moving the origin to the 3d cursor. I also don't think that gizmos and snapping should be the only way to complete a transformation. There should always be a spot where you can key in precise values.
Okay, let me spend some time instead of you to help you a bit, users, to see entire picture in terms of usability.
First of all, speed of action.
Transform origin for single element reqires a shortcut to enter mode - then tracking/aiming - then a shortcut to quit mode.
Shortcut is located in right side of keyboard, so it requires moving some hand to it.
So it is just as long as 3D cursor manipulations at that point, but 3D cursor actions are more confident and imperative, so it is, actually,
still faster for most cases.
We will come back to this.
Import issues - compensated wrong size and far origins locations.
Very common case for 3Dsmax/CAD FBX imported scenes - all objects have scale 0.001 and are scaled to 1000 to compensate, or origins are kilometers far away from objects.
So mode swiching is not even clear - indicators are not displayed in both cases, so you have to find them first, and figure out if you pressed wrong keys or they are just so small to be displayed.
Can't be solved for transforms, as it depends on scene, sufficiently shrinking their direct scope.
Apparent snap
For example, center of base of cylinder, that contains no geometry to snap.
3D cursor only.
Multiple items.
For example, operation to set origins of multiple LODs to the same place with no geometry to snap.
3D cursor only.
No parametric input for origin transform.
No way to solve, except compelled doubling 3D cursor abilities. No comments.
3D cursor only.
Dense meshes.
While transform origin can be performed precisely only with snap, dense meshes/scenes makes snapping problem.
3D cursor is faster as it is imperative and more confident.
Absence of 3-point alignment.
Unlike in other applications, there is no way to quickly and confidently align origin indicator to geometry.
Case - import rotated head from OBJ (part of sculpture, origin is reset to zero) and try to make symmetrical sculpting.
Unsolvable in Blender without scripting.
Unlike in other applications, origin transform messes up with instances visual appearance and placement, making transform even less useful.
No protection from instances editing or no suport for instances compensation, so issue is just the same as in 3d cursor workflow, and even worse, because 3d cursor already have support for translation compensation, if instances are selected.
Unsolvable in Blender.
So, it is a bit not clear - where is all that speed boost we were talking about, except a couple of primitive cases?
You should remember, that 3D cursor was designed by a wise man, and only thing you can do is just doubling some of it's abilities to save a couple of a minutes per day, at the cost of an interface and semantic overload.
You are already there.
I find it disappointing every time someone says something like "can't be solved". "No parametric input, can't be solved"? Seriously? If it can be done with the 3D cursor method it can be done without the 3D cursor. We're not re-inventing the wheel, we're just bypassing the step of moving the 3D cursor and then moving an origin to the 3D cursor. At this point most people would accept simply automating these steps a bit more.
Never told it is impossible. Just showed that there are too many wheels yet to reinvent to get rid of using "origin to cursor" action.
This option currently only works for transforming objects so it's not a bug that other operators don't use this option.
It could be supported by other operators, added #70410 (Support "Transform Origins" for Clear Location/Scale/Rotation) for clearing transform.
Snapping could use it too, although think clear transform is an obvious candidate to use this, where as other operators less so.
@1D_Inc I don't think anyone is considering removing Snap Origin to Cursor.
Not get rid from program solution, of course - but get rid of the action from the workflow.
I don't even know what that means. The ability to snap the origin to the cursor has not changed at all. Better go to Blender.chat if you have anything off-topic to say, rather than permanently litter this developer portal.
Seems to be a little misunderstanding. Here is comment.
This is why this topic was even started - people asked for ability of moving origin without 3D cursor operations.
Now users wants features for transform origin tool that will allow less using 3D cursor-origins operations.
That means, that they want to "get rid" of using 3dcursor-origin operations from their workflow.
There were no any single word in this tread about removing Snap Origin to Cursor from Blender.
Yes, and that would be a good thing. One less tool to care about when transforming origins to care about = faster workflow. As long as the tools you use are not being removed, why do you care?
I kinda get that though, if in a few years, you are one of the last few people utilizing 3D cursor to do stuff, then it will be a candidate for removal, so then it probably will hit you eventually...
Because it can be a way more useful than it is now)
We perform a wide range of workflows, and don't even feeling need in it's current realization. It definitely have a potential, but it is hard to call it an "enhancement" yet.
Well, as it was predicted, to that time transform tool will have translate/transform abilities,
better snap, than Blender ever had, including apparent and projections,
separate GUI with parameters, menus and functions,
addititional modes, incliding 3-point aligning, superior instances support,
and it's own addon's base, including aligning tools in a "collapse top left" way.
And most of this just to replace "Shift+S - origin to cursor" action.
That can be, actually, funny =)
I've already above shown you many cases where origin to cursor just does not work. And it's not just Shift+S origin to cursor, prior to that it's also another shortcut to first place cursor to selected, and that applies only in cases where you want your origin to be on the same place something selectable is at, which is not the case all the time.
Removed subscriber: @Mets
Well, cube is never a prectical example.
In practice, imported parts may have origins in kilometers far away from the model, so first you need to find them somewhere.
It is a question of relevance.
Statement: If the operation, which is used in practice several times a day, can be performed a couple of seconds faster, you save just several seconds per day.
We easily handle that case, avoiding the need to search for the origin throughout the scene, being concentrated on the model.
A nice example! Something else?
We will keep the ability to snap the origin to things like the geometry center, 3d cursor and other things, and we also now have the ability to transform (move, rotate, scale) the origin. Pretending like it's either/or is disingenuous. Just like you can also snap objects normally to things also.
I am sure you are well aware duplicating a vertice and then having to clean it up is a ridiculous workaround to that.
I am more or less 100% sure if Blender had direct origin transformation from the start but did not have 3D cursor, and right now 3D cursor based origin transformation was added, and you would be the one asking about this cube case, then if someone showed you the workaround you have just shown me, your answer would be exactly the same as mine is, that it's ridiculous. Yes, cube was just an example, more practical one can be putting a pivot of the car body to the base in the center of all 4 wheels (which aren't part of the car body mesh).
I am talking about usability issues that reduce the likelihood of using this tool.
First of them, origin have to be found to be transformed by origin transforms.
It is not tool's issue, but general usability issue. What will be faster - the workflow of the 3D cursor that avoids searching for origins, or the origin transform tool that performs fewer operations will always depend on the scene conditions that you faced with. This way, transform origin scope is a subject for accurate vanilla setups made from scratch, because you will definitely never want to perform origins searches throughout scenes like that.
Second, you also still have to check if there are instances in selection both for cursor and transform.
A car is an excellent example by the way, thank you for it - you can transform hood origin, but can't transform wheel's origin - other wheels will fly away.
So, if you perform wide range of workflows, and working with imported assets and scenes (making complex projects), you will prefer to use single universal method for origin transformations, that will allow you to concentrate on your selected model, even if it requires a bit more actions.
Because at the end... this is just transforming origins.
3-point origin alignment is the only thing, that can change game rules, because 3d cursor workflow will never be able to perform it.
I think, I can order key-selected driven script for this already, like in 3dMatch, it is indeed highly anticipated feature for imported assembly retopology process in gamedev.
I will ask my local devs.
Nailed that.
Short GIF demo.
Explanation - we selecting a key (a loop from 3 vertices, side is active), that describes XY plane for origin transform placement, and just aligning origin tranform to it.
Now we can easily align object's origin transform to rotated objects (box, cyllinder), and also retrieve symmetry, for example, for obj imported elements for sculpting (scull).
It's all about differences
between imperative way (select object, enter edit origin transform mode, find origin, grab it to destination, align with multiple rotations to desired position)
and declarative way (we want origin tranform be placed there and like that).
Now we will reduce the number of steps to achieve result (will make a single button) and provide support for single vertex input, single edge input and also instances support.
Added subscriber: @giuseppebufalo
Please developers listen to what professional modelers say they know a lot more about 3D modeling and see what other softwares do, as the solution can be out there, use that as a starting point and make it better, there is no need to live in your own bubble or try to reinvent the wheel, this will save you a lot of work in my opinion.
For example Modo has an integrated 3D cursor to his gizmo and by far it is one of the best gizmo system out there very easy, intuitive and efficient. Same can be applied to its origin system, if you add 3 little axis to the origin (orange dot) you only need 2 commands
1-set origin to selected element (when in edit mode)
2-set origin rotation to the normal of the selected element (when in edit mode).
You can also go in 'origin mode' (somewhere that can be access easily) and use the gizmo to free move and rotate the origin using also the snap tools.
See how it works in Modo as I said the solution is already out there, you are just making it more complicated at the moment.
Hi. There are a lot of us already. Don't panic.
Seems, you are talking about Origin + Pivot system.
http://modo.docs.thefoundry.co.uk/modo/801/help/pages/layoutsimulate/CentersPivots.html
https://youtu.be/0ppjmx39HUc?t=395
There were discussions that Origin and Pivot are, in fact, different types of systems.
Thus, Origin is a true mesh base, and Pivot is an offset that is counted from the Origin and is used for transformations and animations.
Origin+Pivot system have different names in different software.
In Modo they are Center + Pivot.
In Maya the are Origin + Pivot, but origin is unaccesable to user, so it's realization cause more problems than solves.
In 3dsmax they are Pivot + [Working Pivot ]] (also another [ https:*forums.autodesk.com/t5/3ds-max-forum/3ds-max-pivot-problem/td-p/6235423 | unobvious realization )
Are you asking about functionality, like we made as an addon? (watch this GIF )
Also, are you asking about aligning snap tools, like we made as an addon? (watch https://youtu.be/w_zJAlN6vqc)
Well, Modo Pivot realization is quite flexible and clean, better than in Max or Maya, but, definitely, not the best possible.
In addition, the most beneficial advantage of the Pivot system over the 3D cursor is the possibility of animation. The advantage in modeling is quite doubtable (if there is a CAD snapping system in a software).
In Blender there are pure Origins and separate 3d cursor, it doesnot have a Pivot system at all, "Pivot" in Blender is an "around" abstraction.
Thus, adding a common Pivot system to Blender may require a rebuild of everything on a depsgraph level, and will vastly break backward compatibility.
Also, as we can see from 3dsmax or Maya example, Pivot system implementations can be a bit unsuccesfull =)
This comment was removed by @giuseppebufalo
Note that replies here about more general pivot point behavior are off-topic.
The feature in the design tasks relates only to adjusting the objects origin, while it happens this can be used as a pivot, this task isn't meant to be a design task that covers change to how Blender's pivot points work.
While I can see how the misunderstanding occurs, it's been pointed out here already.
Further posts about how Blender's pivot points could work differently will be removed.
Thank you so much for this.
We were afraid of changing the essence of the way Pivot points work because of the many negative examples in various programs.
Yes, dedicated pivot point system can be more flexible as it allows you to manage instances (linked data objects) without causing them to fly away, but pure origin is much cleaner and more consistent for any other case of use.
In short, pure origins are way more truthful.
A couple of examples about origins appearance and management that can be interesting.
Colored axis for dislaying origin orientations while Gizmo is off in object mode. Color represens axis, this can make viewport display less overloaded. MACHINE realization - https://youtu.be/HdKkskyFDN4?t=142
We updated our concept for aligning origin tool.
This single button tool can align an origin to a
- key from 3 vertices (3-point aligning)
Here is GIF
This tool has got basic instances support, but, as far as it is just an addon, it replaces objects with previous origin orientation with new one every time, but it already allow to not to lose objects appearance while aligning the origin of the instance.
We use this concept when cleaning imported models that contain messy origins locations and many instances due to homebrew origin transformation compensation.
The example shows that the declarative way of origin orientation allows both precise origin alignment and instances compensation mechanism.
It may have some lags with ortho orientations (like with defaul cube), but it works pretty much well with non-orthoes.
OriginToKey 2.79.py
Man you said exactly the same thing I said in my previous post that was deleted. I never spoke about pivot points. I’ve always talked about centre which is another word for origin.
i m surprised @ideasman42 didn't understand it.
I also made a video what show how the origin works in modo which is what we trying to aim for.
https://youtu.be/mQkRWjnvfAc
Yes, your latest post was about modo Centers (in Blender terms they are Origins)
Well, as you can see, this is such a contentious question that it’s easy to get confused.
Actually, every Maya screenshot or GIF is about dedicated Pivot system, because Maya don't provide the ability to move an origin with arrows or even to see it.
Modo allow moving both. It is hard to know every software on a market that deep.
Yes, I've seen it. There were behavior that we try to enhance with our proposal addon - precise origin aligning abilities in a declarative way.
Can you make another video - this time with instances to show how origin transforms in Modo influences instances locations?
It will be useful to know if modo have instances transform compensation mechanism.
You need to create several instances and move/rotate/align a Center (an Origin) of one of them.
Yes, I'll try to make another video soon. The behaviour is the same as in Blender when using instances.
I made a quick mockup of what i was thinking the UI would look like. In my opinion the Mesh Machine axis are too big, even the one that we are using now seems too different from the rest of the ui style-wise. Perhaps we should think about something a bit smaller and different from what we usually see in other softwares.
Added subscriber: @Zeirus
This matches Blender's pivots, not object origin - from what I can see.
I assume it's not transforming all the vertices to move this point about.
Changed status from 'Open' to: 'Archived'
Closing this task as the design for the feature is not likely to change.
Most replies here veer into improvements to pivot or deeper changes to how the origin & pivot fit together.
I'll link the remaining important TODO's directly from the modeling module.
Actually, it does. It transforms all vertices to make origin placed into desired position, and compensate vertices transforms with backward object transforms, to keep mesh visually placed the same way it was before transformations.
The same thing - transform compensation - also have Sketchup and our Origin to Key script I placed here with GIF some posts ago.
Sketchup and our script also have instances compensation support, so origin transforms also recalculates instances transforms, to make their visual appearance intouched, but I don't know if modo support it the same way, so I asked for such video.
That will be interesting to know.
By the way, basically, this entire topic appeared because people asked about pivot ability (transforms) for an origin, because most of users don't see a difference between them, and, actually, don't care about such differences.
Most of programs disallow transform or even see an origin at all (like maya and 3dsmax, you can just rest pivot to see actual origin position there), but modo decided to break it through at some point.
In modo there is pivot and ability to see and transform pivot and origin with separate modes.
So all this tread was about applying pivot abilities from other programs to an origin from the very begining.
.
And we got it.
We got pivot actions for an origin)
Now we can not only to see and setup, but even transform an origin with arrows, that most of other programs disallows entirely.
So we faced with predicted behavior - origin transform makes instances (linked data objects) fly away.
Exactly this behavior was prohibited by hiding an origin from user behind pivot system in other programs, so you cannot messup with instances by moving pivot.
And that's why all those origins are so messy, when you import fbx from 3dsmax - in Blender you see their true locations.
Instanced cubes, 3dsmax (pivot setup, no ability to see an origin directly) , before FBX export:
Blender FBX import - true origins only:
For the most of users they are "just arrows" that allow to "move some center of an object", but in practice they are completely different systems that behave differently .
Where can I find your addon?
Here in attach
Also, Maya instances example (pivot setup, no ability to see an origin directly) , before FBX export:
Blender FBX import - true origins only:
So what happened:
Many users: wow, Maya and Max have arrows to move centers, we need the same in Blender to move an origin in the same way!
A problem: pivot and origin are the different things in that software, moving origins is prohibited there, so there is no "the same way".
This tread about moving origins: started because of Many users anyway... )
I think closing and archiving this task is the right way.
Currently, we have a tool that works for unique objects, therefore, this part of the problem has been resolved.
It will take some time to users to understand that this tool mess up with instances, this will take a while,
so it’s best to spend this time resolving critical issues, for example, those that forced our organization to decline the transition to 2.8X version for the production cycle,
and return to this task later.
Also, I made a table of an Origin/Piviot/3D Cursor realizations in different software.
Also tried to put C4D here with their Axis Point and Pivot object, but, it seems, they changed some rules , making origin less accessible.
If it is interesting table looks something like that: