Hi all, I have been looking into implementing a new ‘User Coordinate Space (UCS)’ feature and I would like your feedback on workflow and usability.
The basic idea is to allow the definition of new coordinate spaces at the scene level, allowing navigation relative to that space instead of the world.
The coordinate spaces would be manually defined (similarly to Transform Orientations). One could define a space for an object, or for some other useful alignment to the object/scene.
There would be a list of available UCSs, if one is chosen as active, the 3D view would behave as if this space is the world, without actually being. The numpad view switching would work in this space, as well as the grid. A more optional point is if the transforms should also be in this space, or controlled by the Transform Orientations.
Some use cases:
define a UCS for an object and be able to edit it in place, as if it is in the center of everything
define UCSs for a complex object (or several objects that compose it). Examples: buildings and cities that are not simply perpendicular.
Some points:
Should the list of UCSs be a separate thing from the Transform Orientations?
Implications would be
-to have a separate interface or not
-independence of view manipulation with the transforms manipulation. This is an important point, would it be more useful to be able to transform an object in a space that is not the space of the view? or more useful to select the ‘local’ or ‘normal’ Transform Orientations, that are already there, and just switch to that, without having to explicitly create spaces (and still being able to create more)?
How would the new numpad using be best out of the way of users that don’t know nor care about this? (and still be useful and fast for people that do).
Possibilities are to:
-override the normal ‘1/3/7’ numpad switching. The default would be the world so, unless someone sets up a new UCS (or changes the Transform Orientation if the concept is merged), this should not affect other users.
-override the ‘shift+1/3/7’ that currently aligns to the object’s local axis.The default would be local, preserving a bit of the current behaviour, with the additions of also rendering the grid and centering the translation.
This feature should be accessed via a shortcut enabled UCS menu or can be integrated into the existing Pivot menu, or both
The menu would list the following items, in addition to the existing View, Normal, Global, Local, Gimbal menu items:
Object - Cursor changes to indicate ‘Select an object’. Creates a new UCS aligned to the local coordinate system of any selected object. (Object mode only)
3 Point - Cursor changes to indicate ‘Select 3 points’. User select 3 points in space. User can snap to existing vertices. The 1st point selected will be the new origin, the 2nd and 3rd point defines the direction of X and Y axis. (Object and Edit mode)
Face - User drags cursor over any object. A UCS is created at the cursor location, with X and Y axis aligned to the plane of the face, with Z axis aligned with the face normal. (Object and Edit mode)
Save - User is prompted for a name. User can save an existing UCS. (Object and Edit mode)
<Saved UCS1> - Existing saved UCS are listed. User can select the saved UCS. (Object and Edit mode). A ‘Cross’ icon next to the Saved UCS name will allow removal of the UCS from the list.
In all cases, a visual representation of the UCS will be shown dynamically while creating the UCS, giving the user a preview of how the final UCS will look.
Once a UCS is set, the grid / axis and any newly created object will be aligned to the new XY plane and all transforms will be with reference to the new UCS.
I presume, Brita_ you are planning to develop this feature and propose to integrate into main trunk of Blender. If that is the case this effort is much appreciated and look forward to it. Thx
@jadhav333 The idea would be for it to be in master, yes. I’ll started a discussion on phabricator with the UI team.
I also agree that it would be good to have a nicer way to define a new coordinate space than the transform orientations one. For instance, this is how sketchfab does it: http://youtu.be/43sK5hk3aAY?t=25s
@RickyBlender What do you mean by ‘a script to add some tools’ and ‘face mode transform’? For the rotation, you know you can activate the rotation manipulator? But is this even related to User Coordinate Spaces?
@bluecd thanks for the links, it is nice to know that this is useful
After much discussion, I have considerably reviewed the idea so far. I think it is really best to keep the user defined spaces that will be used for viewing and navigation separate from the Transform Orientations. Also it would be more consistent to use directly the numpad instead of shift+numpad for view switching, thus answering my original 2 doubts.
Here is a copy of what i wrote on phab:
The basic idea is to be able to define new coordinate spaces (like in Transform Orientations) and use that as if it is the world. It would affect:
the grid (so it is visible what is the working coordinate system)
the numpad view navigation, home key and all other view commands
quadview
transform system (the axis locking are the axes of the selected UCS)
walk and fly modes
all other operators who use the Global transform would be using instead the UCS
I would propose to make a new list of coordinate spaces that is attached to the scene.
This list would have the ‘World’ coordinate space as predefined default and would hold all the new user defined coordinate spaces.
The user could define new spaces that are aligned with objects or in some useful alignment of the scene and switch to them for viewing and editing. This would be very useful to edit an object in place or to model something as in this example image.
The feature is opt-in, the default space is the ‘world’ and if no new space is created and selected everything will work the same as now.
Left to discuss is:
a good interface to define a new coordinate space (easy positioning: align to object, view, face… and wiggly widgets from antonis to view and edit the result?)
the interface to select and manage existing spaces (UIList, rename, modify)
quick switching of spaces
possibility of having also automatic UCSs in local view or depending on data selection. Example: have a ‘local’ predefined UCS that will mean the local space of the selected object without the need to setup the space previously. This can be tested and better discussed after doing all the rest.
@bluecd, this is particularly unhelpful feedback, and assumes developers are experienced Sketchup users. (“present-look axis snapping, component nesting, groups. etc etc.” - is basically gibberish to me), and a quick Google doesn’t show up “present-look axis snapping” as being a thing. so it seems this is your own terminology?
If you think another application already got-it-right, please explain why, doing an exact 1:1 copy of a feature only really works if your going for a direct clone of another application. In this case we need to make sure this fits in with the rest of Blender, even if UCS in Blender ends up working in a similar way to other applications, we should at least do it because it fits with Blender’s design, not because we can’t think for ourselves and have to slavishly copy someone else.
Awesome initiative! I’ve always wanted this. Until now I’ve been making an instanced duplicate and aligning that with the world axes.
It should most certainly be separate from the transform orientations. The custom transforms are something very short term, to do one or two tricky grabs, punctuated by normal worldspace transforms too, and I update them very often, while in my view UCS should be something more permanent that stays with the object or scene being edited.
I don’t have a strong opinion on the numpad, but I’d very much like UCS to work with the MMB-alt snapping.
Also, it would be great if we could define the UCS with an object that actually exists within the scene (like an Empty) and is subject to the usual grabs and rotations, rather than trying to define the UCS by using existing faces, or vertices like the current Create Orientation op does. (The Create Orientation op behavior is great for what it does, but UCS is a different use case)
It might also be useful to create operators to re-orient objects’ local spaces to the UCS. Sort of like Apply Rotation, but in UCS.
Why Iam talkin about Sketchup?
As you may know it had been developed by Google, it proved (and still does) to be fastest modelling tool, seems those people really achieved their goal for intuitive,simple and clear approach to 3D (in some extent-I dont mean Bezier, Free form by now-but it comes with Addons).
eg. for quick Archviz and model making for futher viz. in eg. Blender, 3D Max amd similar.
Therefore I would insist to look for some inspiration that could be incorporated into Blender.
Sketchup by itself has simple UI, simple workflow and yet is very effective. Overload of unordered options and Addons seem to be an ilness of Blender-on the other hand.
so this new UCS would simply be use for basic viewport edit for making scenes!
So it would be like a new rectangular UCS with different location and rotation
not cylindrical or spherical or polar UCS here !
and if you build a scene with a new UCS it would not be possible to use this UCS for the anim features?
also this means that the Custom transforms would have to be able to work in this new UCS too!
how about the other tools like snapping mode ect…?
I have years of experience in CAD and USC are a great and handy tool for adjusting orientations when working on parts.
Here are some thoughts:
Keep Custom Orientation alone - because it is not linked to USC this can be handy when you need to save translation vector other than global and local - hardly any CAD app has this fine tool option!!!
USC is great only when:
A) The view completely reset to the new orientation
B) USC can be set for individual view ports
C) 1 3 7 view keys work with the new USV orientation and do not over write them like in Rhino
D) Objects created in a custom USC have their local value adjusted like in Alias
Here is a video check out how Rhino works compared to Alias and you will see that Alias is a great workflow to shoot for while Rhino is so so. Alias and Blender have a lot in common actually.
@cekuhnen,
re: “USC can be set for individual view ports”
Can you give some info on why this is useful/important?
(Was thinking this would be set on the scene-level so its not so much a hassle to manage each view).
@BluePrintRandom, in this case it would just be a way to change the user interaction (no increased precision because internals would be the same).
@RickyBlender, not sure how snapping tools are related to UCS. Aside from the change to axis-snapping which would be supported of course.
Well, snapping to the UCS grid would be very nice. Actually, just snapping to the grid at all would be very nice. (And please don’t even bring up the Shift-S->Snap to Grid op. It’s mostly useless because it always works on all three axes.)
Also since we’re talking about snapping it’d be nice to get separate settings for grab/rotate/scale snaps. You almost always want to have increment snapping on rotations, but not very often on grabs for example.
@bluecd thank you for explaining better. You keep mentioning Object Grouping, is this some issue related to UCS or just something that could be better, but not related?
@piotr idea is that everything works with UCS if you have one selected that is not the normal world. everything that would work ‘globally’ would work in the selected UCS: the mmb-alt snapping, all transforms constraints. I expect this to be intuitive because the grid and the the axis widgets will reflect this visually.
Creating the UCS: my idea is to use psi-fy’s 3D widgets. this would allow a good visualization of the coords you just created, and ideally editing it intuitively too. These widgets are still in development with no ETA, though. For the initial creation, the align to object and geometry is not useful?
Apply rotation/etc : should this work by default with the selected UCS?
@cekuhnen in 1, you mean keep transform orientations separate from the UCS, right?
2. are independent viewports so important? if the UCS is fast to change, maybe not? I imagine it similar to what you show in the video with Alias, if you have more viewports, they’d follow the same UCS, so that everything is consistent.
