@Bastien: I agree with Donatas. Ask architects why they prefer modeling in Rhino (or ArchiCAD or SketchUp up to some point): because it's easier (= more intuitive (= has better snap tools)). So at the moment the only reason why this patch would not be used so much, is because architects don't use Blender so much. It's exactly patches like this making Blender better for architects. So arguing against it, because it would not be used, is a bit unfair. I think it's an amazing proposal and a great work by Justas and everybody who started working on it. It's a VERY(!!) helpful step towards more architects using Blender.
Example: With this feature I don't need to create transform axes anymore. You know how many times I tried to teach that to my students? When I did, they always asked: uhm, why do we have to learn Blender? Even some of those who were not as skeptical abandoned Blender after a while. Probably because they did not remember the workarounds anymore (or thought it takes too long to create transform axes).
So, if this patch makes messy code even messier (didn't look at it) then the whole code probably needs to be redesigned anyway? I can understand your concerns about the code. I also don't like code to be a huge mess. But this feature should definitely go into master as soon as possible to my opinion.

Hello everyone, just want to add an additional voice to the already vocal people here, as an architect myself and blender blender user of about 7 years I want to add my support to this feature . I can't possibly stress enough how important this improvement is, it's one of the last remaining big gripes I have with Blender and what has made me reluctant and prevented me from introducing more fellow workers to this absolutely fantastic software.

Just to make it clear this is a VERY MUCH NEEDED tool for architecture and any generic type of precision modeling, just want to show this is not at all a niche feature. I am really hoping this makes it to trunk.

A very deep thanks to Justas for this :)

In T45734#331170, @Lukas Treyer (cnd) wrote:

You know how many times I tried to teach that to my students? When I did, they always asked: uhm, why do we have to learn Blender? Even some of those who were not as skeptical abandoned Blender after a while. Probably because they did not remember the workarounds anymore (or thought it takes too long to create transform axes).

Exact same experience here. From 60 students last semester, 2 used Blender for their project. My students are happy with my courses (we get marks and remarks fro the students) and I teach other 3D Packages where much more students continue to use what they were taught. I love Blender, and that's why I like patches removing those barriers to adoption. It doesn't change behavior for artists happy without it (just a modal shortcut), so I also would love to see it committed.

I would like to add my full hearted support as well. I am an architect as well. Architects today do CGI all the time. It's just 3D scenes like many other 3D projects. But it needs to be precise. Good snapping is a must and this is about half of the way to reach that goal already!

Question is whether snapping code wise needs to be rethought in blender. For example, in the future, how would you make it possible to snap to both a vertex or an edge without needing to change snapping mode? Or what about midpoint , aligned or perpendicular snapping?
Would this muddy the transform tools code even more and what would be the best future proof way forward here?

Moderation
Please, let's not turn this into a forum-like discussion. Giving feedback why this feature may be useful is okay, but discussing why people prefer other applications is totally of-topic.

Well, that's what you get if you start arguing that a major useability improvement might not be necessary...

*just an artist not a coder*

i have some background in the CADD field and i can say this kind of functionality is something i've always missed in blender even though i don't do much CADD work in it.
the hoops we jump through now to line things up properly are a little bit ridiculous from a usability point of view.

the current process is a slowdown and flow breaking to have to stop and turn on and select snap options as well as position the 3d cursor, and even change the pivot point options just to properly align things before turning off/changing back snap options and pivot settings just to get back to our regular modeling settings and otherwise quite speedy modeling workflow.
i've seen multiple tutorials for new blender users cover this sort of thing because it is something that you end up needing to do more often than you'd think.

i really want this proposal to make it into blender.
the way it's proposed seems dead on. this would certainly speed that whole process up and in a way that allows us not to have an odd break of our work flow.

that said it may be nice to be able to choose the middle point between multiple vertices for the base point of scaling things somehow.
especially in instances using the mirror modifier where right now you've got to move the 3d cursor somewhere on the mirror plane and then set the pivot center to 3d cursor in order to scale things without deforming the shape you've made.
usually you end up snapping the 3d cursor between the two vertex points of the edge loop that touch the mirror plane.
so if you could somehow select both of those vertices to place the base point for scaling between them that would really make those instances faster and easier as well. maybe hold shift or ctrl after selecting the initial base point to select a second vertex to place the base point between? or some other way?

i really just wanted to say that this is a fantastic suggestion and point out that there are times when you do need to scale from between multiple vertices rather than just the one.

Moderation

Talking about moderation, could somebody copy description of Duplicate with basepoint, Multiple duplication proposal, Mirror with basepoint from one of my comment in the middle to main task description? Or grant me ability to do that, because I can not edit task.

And also thanks for support! We all want to make Blender better :)

@Justas Ingelevičius (ingis), you can do that as a non-Mod by claiming the task (Action->Claim - don't forget to un-claim afterwards)

Base point snapping is a great idea. Any way to integrate base point selection with accumulated snap points (pressing a over a snap point in transform)?

Base point snapping is a great idea. Any way to integrate base point selection with accumulated snap points (pressing a over a snap point in transform)?

This exactly what is proposed. While selecting basepoint snap should be activated and vertex selected accurately. As Jaume shows in video it works perfectly: https://vimeo.com/137361362

But for me on Ubuntu 15.04 and Blender build with CMake snap while selecting basepoint not always works. For Donatas (Zigzauer) also Ubuntu snap on selecting basepoint does not work at all. Is it way to investigate what causes this behavior? Did anybody else try this patch? Does it work for you?

Also I didn't find how to claim this task to update description. Maybe it is obvious, but I can't see such option :) Should it be there?

Some feedback about this.

Problems:

• The name is not consistent with b3d. A proper one would be Manual Snap Target.
• As currently, the feature has very low discoverability - it's accessible by a key during transform, and has no GUI element that would hint that such a thing exists.

Solutions:

Place the feature here:

Add info how to set the manual pivot in the tooltip, and in the 3d View header, when it is on, during transform.

• The name is not consistent with b3d. A proper one would be Manual Snap Target.
• As currently, the feature has very low discoverability - it's accessible by a key during transform, and has no GUI element that would hint that such a thing exists.

Good point! So you suggest that when user selects Manual Snap Target everything works even without hitting B during transform?
User selects object then on pressing G object does not move until "basepoint" is selected then moves along cursor ant at the end is released to selected second point. The same with rotate, scale and duplicate.

Yes it would be even better.

For "Duplicate multiple" check box near linked could be added

I am not sure about buttons. Adding two more one for Duplicate Multiple and one for Duplicate Linked Multiple sounds too much..

@Justas Ingelevičius (ingis) above the comment area the is an action drop down. in that drop down select reassign/ claim

Thanks for feedback,

Justas, I do not know at this moment why is not working always not working the snap in your system, mine is debian 8. When not working try to move around the vertex with CTRL Key pressed (invert the snap flag) , or SHIFT+TAB to enable/disable it.

Pawel,

I agree that name it as "Manual" is best consistent in Blender and placing it on the UI is good, and allows visibility. I'll check it.Having the keystroke is in may opinion more important, but then maybe should be set to "M"

I've uploaded a new video, showing the use of this feature on rotation.

Works setting the Snap Target during the operation once the B Key is pressed. You can also use the resulting vector on the center of rotation as axis, allowing to align objects, this is done with W key.

Selecting the center of rotation during transform is not performed, and i think it should be done with another key. So, maybe the need of selecting always is not necessary. In the video I'm placing first the cursor, and then using it. Having the keystroke would avoid all these extra steps.

https://vimeo.com/137948265

I work in Industrial Design and teach also in Interior Design and the build in spanning in Blender is so so often it does work but not always.

The proposed addition is really welcome and works well.

I agree Pawel's suggestion to add it to the snapping list as a type to expose it better.

For the rest setting a start a second reference and a target point is pretty common to me when I work in Rhino.

I've uploaded a video showing the multiple duplication feature.

https://vimeo.com/138325421

I've have done it in a generic way, so it works for all transforms (tested only on 3D space).

I'll submit another patch for this feature.

Nice patches. In the duplicate panel (left panel when you call it), it would be nice to add a number for M. I would allow to make a street for example with 10 lamps in one go. Best would be able to type it directly, along x, y and z values directly in the viewport.

In T45734#332692, @mathieu menuet (bliblubli) wrote:

Nice patches. In the duplicate panel (left panel when you call it), it would be nice to add a number for M. I would allow to make a street for example with 10 lamps in one go. Best would be able to type it directly, along x, y and z values directly in the viewport.

I think the use case of your proposed M number is not clear. When I want 10 lamps in fixed distance from each other I use array modifier. This multiple duplication is used when I want to copy objects in irregular, manually specified places. Basically if we add this M number you will hit 10, then click around 10 times on different spots, get ten objects and operation stops. So it just helps count to 10 and no more in this case. I'm not sure if you expect this behavior :) If you want to add ability specify distances between objects, you get almost the same as array modifier and this duplication of features would not be good thing.

Which version of Blender do you use to have modifiers available for lamps??? Anyway, the Array modifier doesn't create instances, so it's rare that it is a good choice when you want to optimize your scene. My Idea was to simplify the actual workflow of Shift/Alt-D, enter values and axis, hit Shift-R 20 times if you want 20 instances.

Another video showing the selection on the fly of the center of transform, with "C" key, which can be useful on rotate/resize. Note that according to consistency, the B key acts as Manual Target, so it should not be used for Center selection.

https://vimeo.com/138512129

At this point will be missing from this task to get a reference value for scale (another shortcut with 2 points ?), the plane select with 3 points for mirroring, and UI discussions about shortcuts / buttons.

Another video showing the selection on the fly of the center of transform, with "C" key, which can be useful on rotate/resize. Note that according to consistency, the B key acts as Manual Target, so it should not be used for Center selection.
https://vimeo.com/138512129

Center of Transform is called a Pivot Point in b3d. A Manual Pivot Point should be placed here:

UX wise, I would expect it to ask the user to specify an element (vertex/edge/face) where the pivot point is to be placed when a transform is started, use the last one used by default, and allow to reselect one by using a shortcut displayed in the header.

May I suggest in the proposed mirror operator that it default to mirror only in the XY plane.
Then pressing a button if you want to specify three points for the exact plane?

From working with rhino I know that you often use XY plane more often than three point placement.
I like where this is going though.

Hey @Justas Ingelevičius (ingis), @Jaume Bellet (mauge), this has a lot of promise, and in essence is a very valuable and powerful feature. However, as it stands right now it needs a lot of work and/or rethinking.

Feedback

• Separation between the 3D Cursor and Basepoints is very muddy:
  • It's not clear to me if Basepoints are intended to be Transform Origins or Snap Targets / Elements or both.
• Modal interaction and user feedback is very poor right now:
  • When using Manual snapping for example, there's no visual feedback for selecting basepoints. No hover, or other feedback to indicate that you're in a transform operator. The toolbar callout of Select a Base Point is not sufficient. It needs directions for how and why.
  • How is a user to know what a base point is, or how it relates to Manual Snap Targets?
  • The Base Point sub-modal is causing a lot of confusion. For example, if Manual snapping is enabling and you start a Rotation Operator, then the dashed line indicator is still drawn, but it doesn't do anything as it's waiting for a Base Point.
• Discoverability is really poor, leading to less usefulness and more user frustration:
  • As with multiple snap targets in transform (A), this is very difficult for new users to discover since it's hidden within the modal operator and is dependent on snapping configuration.
  • The discoverability is not just a problem with these Base Points, it's a problem with most of Blender's modal operators, which is one of the issues that (I personally hope) needs to be resolved during the 2.8x project, but it's particularly evident here.

Suggestions

We discussed this a bit in the #blenderui IRC channel (@Campbell Barton (campbellbarton), @Julian Eisel (Severin), @Paweł Łyczkowski (plyczkowski), and myself), and it was mostly agreed that this is a good feature to support, but it needs to be done more carefully and comprehensively. Blender's snap system is really quite primitive and needs a lot of improvements (such as this one), but it needs to scoped out well made to work well together with other parts of Blender, such as the 3D Cursor.

At this point it's probably best to step back and scope it out more carefully, perhaps for inclusion in the 2.8x project.

Here's a few questions to consider:

• How do base points and the 3D Cursor interact?
  • Are there changes that could be made to the 3D Cursor to let it take on the functionality of base points rather than adding another tool? For example, this patch makes some progress in that direction: T40952
• How can the functionality be integrated with all snapping modes and exposed to the user in a clear way?
  • Perhaps this should be integrated through the Widgets work @Julian Eisel (Severin) is doing? https://code.blender.org/2015/09/the-custom-manipulator-project-widget-project/

Thanks for your comments!

I agree that is still needing some works, regarding to UI, some things like changing the cursor when selecting is already done (removing the helper) in rotations but not uploaded in blender patch tracker. But maybe another cursor should be set to realize you must select a point/reference.

I think that the feature has been designed at the beginning according what a CAD user expects to found. I would remove the term of "BasePoint" and use the proposed "Manual Pivot Point" and "Manual Snap Target".

The sub-modal(s) should also be checked and not pass through all events, as is currently done. Also the whole changes should be checked in other areas of blender, as the transform code is not used only on 3DView space

Currently they are missing the submodals to select two points for reference (Vector) for scale reference, and 3 points reference (plane) for Mirrors.

Anyway, i can see that maybe the transform code will change on 2.8x ¿? Should I continue working on current code ?

Is there any place to checkout the custom-manipulator-project and see it's status ?

Custom manipulators are a branch of official git repo (https://developer.blender.org/diffusion/B/browse/wiggly-widgets/). :)

https://vimeo.com/139064792

I've been solving some issues, and showing a cursor while selecting a point, and setting manual pivot and manual snap target as options.

just my perspective on the feedback and questions as a user with a CADD background.

feedback

separation between the 3d cursor and base points is muddy because the 3d cursor is a base point if you set it as the transform origin/pivot point.
in other programs a "base point" is a transform origin and a "snap target" is what you want that transform to snap to.
in blender a "snap target" is kind of a mix between what is, in this proposal, called "base points" and "reference" points.
in the case of using the move/grab tool the snap target would be the base point but in regards to rotation/scale tools then blender's snap targets would be "reference" points.... because blender is just weird like that.
blender's implementation of these things seems inconsistent to me. i mean everyone calls it the transform origin rather than the pivot point regardless of what blender's tooltips say and let's be honest i don't expect "snap target" to have anything to do with what i've already selected rather than what i'm aiming at snapping to so the default "closest" seems like a great choice when honestly it's a horrible choice for precise work.
it took me forever to figure out that you could do all the same things as this proposal allows (though it's much more roundabout than how this proposal does it) and i don't believe i've ever seen a tutorial actually cover how to do it much less seen a tutorial where anyone ever changed that from "closest" i have seen tutorials where they say you have to basically make two moves/grabs in order to precisely snap that way though. so that wording seems likely to throw people off rather than help.
i'm embarrassed to say that i've been using blender since at least 2008 and have only just figured out how to do this stuff recently.

questions to think about

1. 3d cursor is a base point. it's just currently much more of a hassle to use than this proposed implementation of a precisely and easily chosen base point

2. the 3d cursor already has the functionality of a base point it just isn't used as well as it could be and it also has problems for precise rotation/scaling since it is just a single point (set blender's snap target to active and go into edit mode to make a precise choice of the second point needed for precise rotation) and in the case of moving/grabbing it gets entirely replaced by the snap target option selections rather than being the "base point" there too.

essentially blender's tools already have "base points." you just happen to know them as transform origins or the "pivot center for rotation/scaling" (active element/median point/individual origins/3d cursor/bounding box center) and the snap target options for the move/grab tool.

in order to precisely do things like this proposal easily lets you do, you have to set yourself up so you can. again, for the move/grab tool you just have to change the snap target to "active" and enter edit mode. the center of the active element becomes your "base point"
for rotation/scaling you have to first turn the transformation origin to the 3d cursor, then snap the 3d cursor to your "base point." now you turn on your snap mode to edge or vertex (really anything other than increment but those work best for precision work) and set the snap target to active. then select what you're going to rotate/scale and make sure you select your "reference" point last so that it is the active element so that it will actually act as the "reference" point. now you can just activate a rotation or scale and it will snap to things like is easily and quickly done in this proposal.

3. the base functionality is already integrated with snapping modes it just isn't very noticed by us users or even that clear that this kind of thing is doable. you just have to go through the process of swapping the transform origin, snapping the 3d cursor, setting the proper snap mode and target and making sure you've got the right thing selected as the active element, every time before you rotate or scale. granted you'l likely undo or have to change at least 3 of those 5 things every time you want to do this process.

4. what do widgets have to do with this? if i read that page right that work is essentially about making the workspace more workable rather than having to rely on buttons and sliders in panels or tabs. granted that project would work great for things like spin where you've got number of values and settings to adjust but move scale and rotate already have widgets and while they're nice they're no good for quick but precise work and they won't really be much good for selecting base points, reference points, and snap targets.

personal thoughts

you can do the basics of this stuff already (in edit mode) except maybe the mirror thing but it is a much bigger hassle than this.

in the last video that Jaume Bellet posted the only problem i see is that when you add these as new options for snap target modes and pivot points/transform origins why would me or anyone else bother to use the old ones instead?
the only reason i can think of is if we just don't bother picking them because we use the hotkeys for this.
i certainly don't enjoy having to stop and swap my pivot point every time i need to do something like this when i know i'll have to swap it back right afterwards. i know . and ctrl comma but those are usually out of my natural reach so i use the mouse instead.
the only possible concern i have for this is that maybe there won't be a setting in the user preferences that allows me to have blender temporarily swap the snap mode to vertex (or user's choice) when i hit the b hotkey only to have it automatically swap back to increment once the move/rotate/scale is finished.
if it does do that then i can just leave the default snap mode as incremental and i'll virtually never have to touch that setting ever again.

I'm also a CAD user and actually work on CAD enviroments.

IMHO the shorcut proposal is what you could expect.

On translations
Start operation
[B -> selects a reference point]
Place it

On rotations
Start operation
[C -> select the center of rotation]
[B -> select a reference point]
Place it.

On scale
Start Operation
[C -> select the center of scale]
[B -> select a reference point]
Place it.

Note that CRTL+SHIFT+TAB is working during point select so you can change this setting during the operation.

The settings and names on the UI were added to match what you currently find in Blender. If you set the snap target as manual, you will be must always select the reference point, so i think it's not so bad. The same for the center of transform. In case both settings are enabled, center goes first. Maybe a way for selecting the last one used will be also useful.

I'm assisting to Blender Conference. So if anyone is interested and is going there we can talk about it and other cad improvements :)

@Justas Ingelevičius (ingis) and me we have a presentation there

https://www.blender.org/conference/2015/presentations/199

I've upload another video showing combination of snap and multiple transform feature.

https://vimeo.com/143426398

The presentation was not as good as expected as we had linux problems... for getting output to projector, so realtime demonstration during it was not possible.

Following our discussion in the diff thread, could you add the possibility to move the view to the whole process? At the moment, most user will zoom in to select snap point and will then be unable to select target because Blender blocks the view when grab/rotate/scale or duplicate starts. I know this is not due to your patch, but at the moment it can't work properly in real cases (relatively complex scene with lot of possible vertices to snap from/to).
Your patch is on a really good way :)

The availability to move the scene during point selection is done bypassing events and maybe some checks could be done there. As blender has especial mouse input during operation, I maintain as is when applying it because i do not want to change blender user inputs, so maybe and option should be having a flag enabled by user, allowing the transform use the mouse input as usual or moving around the scene. I think lots of user are missing this, and moreover is you want to place and object from one place to other with precision, or need to zoom in/out for selection, or if you use the multiple transform feature also added in the patch.

It should be good to know the opinion of @Julian Eisel (Severin) and as i think he is working over the UI

The problem of working on a patch, is maybe is difficult from some users to apply it, just to check it's functionality. Also the transform code is used in lots of places in blender, so changes on it can introduce a bug in other ares, i have only tested on 3D view. Maybe splitting the patch will be useful, although is a little difficult as the whole functionality of it is related. Also blender is changing relatively fast, so there can be changes that they break the applying of the patch as already happened, or the patch functionality.

As I said, it's impossible to use it in large/complex scene at the moment because of the conflict between precision needed to select the snap element end the large view user need to move the object. Maybe you can add a key like you did with B to free the view position during grab?

As an architect using Blender for archviz and precision modeling frequently I can't really stress again how important of an improvement this is for Blender.

I have not tested it myself, but from the very thorough videos and step-by-step screenshots posted here I would argue that usability wise this seems very close to the workflow other CAD-like applications use, and probably very much in line with what most users seeking this functionality are most likely expecting to find.
I would dare say that a "hard to find feature" or "hidden" is better than no feature at all, and has it stands it doesn't seem any harder to find than the current XYZ axis constraints.
Bottom line I really hope Blender devs seriously consider this for inclusion as it currently stands, since this solves what is currently one of the most serious limitations of Blender for hard-edge or precision modeling in a very standard and non intrusive way.

As mentioned by @mathieu menuet (bliblubli) the ability to manipulate view during operators would be really nice addition, not only during transforms but other operations too, though that would probably be deeper change with many potential complications and conflicts better suited for a more general revamp beyond the scope of this patch.

I want this, how can I have it?

I want this, how can I have it?

With T47032 in the tracker this work could really integrate with the new widgets as suggested by Jonathan Williamson
Just like the widgets draw the transform axis with the XYZ labels maybe the origin center, base points, and reference points could also have the corresponding hotkeys displayed as a label as well, allowing changing them either by clicking on them directly in viewport or by pressing corresponding hotkey, improving both usability and discoverability.

Forgive my insistence but I really appreciate Justa's work and think this is a very important improvement for Blender.

In my opinion as a cad user the place where the XYZ axis are drawn should be the origin of coordinates, and not a base point. So a user could expect / need to place something from one point to a specific coordinates that could be based on this origin. At the moment with the changes implemented this could be achieved using the 3D cursor.

Some time ago i tested the changes related to this task D1501 on the widget project branch as working, i'll check again, and also i'll follow the changes related to the project ;)

It is great to see that the widget system is being reworked, but I think it might miss some of the glorious aspects of this proposal here:
Defining a start point, defining a mid point, then scaling/rotating to a target point.
Everybody that works in object design uses that in nearly every other application.

In terms of how well this feature is presented through the UI could easily be solved by adding something inside the pivot point menu and good it is.
For further information read the manual.

I am somewhat a little surprised to see the resistance here the proposed enhancements.
I am curious about how many of the the critics work in other CAD apps and not the workflow there?

Maybe you are not just comfortable with the proposal because it works different than you personally do work?
I am just genuinely curious.

@Justas Ingelevičius (ingis) maybe you could add a section to the task description that lists the currently open questions to discuss, and what general consensus is? Just so that people can get an overview of the discussion without having to read up on all comments (I for my part already lost track long ago already :S). Assigned the task to you, so you can edit the description.

Good idea. I will be away for some days. Could work on that next week.

@Julian Eisel (Severin)

Well in case that is the goal, then I am all for it.

The proposed widget idea is good, making it movable like an object.
This should be true also for the 3D cursor. You still cannot move drag snap it in object mode.

But the value of Justas idea is less an improvement to the widget but providing really needed
translation options.

Start point, reference point, target point for scale and rotation.
Start point for object snapping.

Currently you can snap in Blender objects to objects but you have to perform man x y z commands to
snap it the way you want and not the what Blender can come up with a possible solution.

I'm not sure if it's good place to post suggestion but couldn't find better.
In CAD objects are moved after selecting point not directly after command like in Blender. CAD simply waits for input after command.
I think that instead of selecting point via B and C user should press modifier key (alt maybe?) or "precise snap" key like suggested "B" to disable transform (make Blender wait for input) and turn on snapping. It would allow selection of multiple points regardless of transform and wouldn't require many keys that can conflict.
It is really similar to CAD way, as we are told there to select points one by one and we are doing it in certain order. It could be universal for all operations.
Here gifs from FreeCAD. To move I selected object, then press MV (move), selected first point and then second. Similar with rotation: select, RO, first point as base, second as reference, third as target.