Such a nice theme! It was was waited for a very long time)

I am maintainer of 1D_Scripts - a toolset with goal to define how CAD/snaping can be enforced in Blender 3D

I think, it can include alignation tools as part of CAD/snapping issue.
For example, a tool like 3DMatch tool
https://youtu.be/gfnX5MYXNfk
with ruler-based keys for transforms, that reqires snaps.
https://developer.blender.org/T45734#506696

Also, some feedback on proposal.
A bit obsolete, but still active.

@Paul Kotelevets (1D_Inc), the 3DMatch tool's ideas are really good!
I can already imagine something similar to improve the features of the 3D Cursor.

But as a first stage in development I think it would be good to focus on improvements to the snap system and existing tools.

Also for this first stage, I have in mind some of the ideas proposed in the devtalk forum (later I will list and give credit).

New tools can be planned at a second stage of development.

EDIT:
(But these decisions will depend on meetings and discussions).
I just downloaded the pdf, reading now ;)

Okay!
To this time we've collected a lot of interesting concepts, that can be useful.
A lot of them were tested during different types of production.
That will be awesome)

I am both an architect that maintaining a lot of CAD addons, and baroque modeller, so I can observe problems for both CAD/organic modeling,
so I've tried to structure all those problems in a single table for overview.

Does this looks truthful?

Thank you, it's well organized and descriptive.
It is good to see that the proposed improvements are in common agreement.
I will use it as a reference to improve the description of the task.

I didn't understand what you meant by "Base point support -> [2 and 3]point Alignation".

In T66337#724459, @Germano Cavalcante (mano-wii) wrote:

I didn't understand what you meant by "Base point support -> [2 and 3]point Alignation".

I think he means rotating/aligning/moving an object by defining three arbitrary base points which define three axis, and then specifying three other target points which define the position for the object destination, if I'm not mistaken.
You can see a basic demo at 1D_Script video

There are sets of CAD basepoint ("from-to") operations, which are characterized by the numerical capacity.

1 - point alignation (A-A') gives 1-axis basepoint CAD snapping for translation or rotation or scaling.

2 - point alignation (A B - A`B`) allows 2D alignation (which is so useful in architecture).

3 - point alignation (A B C - A`B`C`) allows complete 3D alignation

Well, 1 -point alignation (classic CAD basepoint "from-to" snap behavior) for moving/rotation/scaling is the thing we are fighting for decades.
There were a nice refrence proposal for basepoint operations that was already mentioned there.
https://developer.blender.org/T66424
Currently Blender doesnot performs basepoint snapping, and object snapping is looking like that, that makes impossible to snap, for example, instances precisely:

2-point and 3-point have higher capacity, so it requires a separate generalized tool to design, that will perform such alignations.
We designing the shape of such a tool for a long time, as a research (it is shown on GIFs).
Direct writing of such a tool can be out of scope the current development, but I put it in a table to make the review of problems completed, leaving less blank space in a map, and to show, that they are parts of one system.
Who knows, maybe it will lead to some API changes, that will make writing such a tool easier.

Nice concept) Basepoint alignations is always very useful, but it seems, it can be implemented as extention mode of default tools.

But of course! All of them are, basically, parts of the transformations!
Now I need to sketch some)

Oh, God. That's actually gorgeous!
I've spent some time to sketching, and figured out, that this generalized system is possible to be implemented as extentions to default tools!
All this years, since 2012 I've been trying to figure it out, making different tools like 3Dmatch, Sideshift, 3D Rotor/scaler, finding awesome solutions by Okavango and other developers, and, finally, combined all of them!

Here is that proposal, a solution, that unifies everything:

I made a copy in the relevant topic.
https://developer.blender.org/T66424

By the way, what do you think?)
Do you like things happening on GIF's?

@Paul Kotelevets (1D_Inc) This is pretty close to how I'd envision things, if we ever get something even remotely like this that'd be perfect.

A few comments that come to mind:

On rotate with 3 base points RB3 I'm wondering if rotation should be performed around A instead, as in you specify center first, then base point then target.
I think it is default behavior on some "industry standard" CAD applications, and in terms of workflow there is less "jumping around", because you specify the base point and the target in sequence, rather than jumping to center in between.

With rotation operators can we still freely combine axis constraints with these new systems? What I mean is are we able to arbitrarily do R X B or R B Y, or three points with R B 3 Y ?
Just wondering, even if we can't this already a great improvement

In T66337#730138, @Duarte Farrajota Ramos (duarteframos) wrote:

@Paul Kotelevets (1D_Inc) This is pretty close to how I'd envision things, if we ever get something even remotely like this that'd be perfect.

Thank you!

On rotate with 3 base points RB3 I'm wondering if rotation should be performed around A instead, as in you specify center first, then base point then target.

Agreed, most of applications have such behaviour in that order, but it is a bit hard to draw such concept - if to try, you will get BAC angle, or inverted ABC, that can be looking pretty much confusung, so I proposed this order to make sketch of concept most reable.
It is just looking more clean on still image)
But yes, order can be changed to industry standarts in that case.

R X B or R B Y, or three points with R B 3 Y ?

For sure!
Also, there is still no preference in axis placement order - here is still possible RB3-Z, R-Z-B3 or RB-Z-3 with the same result. Only RB3 part is in certain order.

Also I thought about RB3ZZ for locals, but it seems to be fixed in 2.8, so Z always uses current coordinate system, and there is no need in doubling it.

In T66337#730538, @Paul Kotelevets (1D_Inc) wrote:

In T66337#730138, @Duarte Farrajota Ramos (duarteframos) wrote:

@Paul Kotelevets (1D_Inc)

Also, there is still no preference in axis placement order - here is still possible RB3-Z, R-Z-B3 or RB-Z-3 with the same result. Only RB3 part is in certain order.

That sounds great, perfect from my point of view, hope it supports all object types properly, especially bezier curves and empties with dupligroups.

Nice to hear that)
That will depend on realization. I also interested in supporting mesh editing mode as well.

Just one small note that came to mind now. Using 2 or 3 as hotkeys keys for two or three base points may cause conflict with introducing absolute values for rotation (as in 2 our 3 degrees).

If those only work after pressing B for base point that the chances for collision are reduced, but you still lose the option to rotate by value after defining base points (not sure if it was planned to be supported).
Still, if we could come up with different keys it would avoid possible limitations down the road.

Yep, that's why B with straight order RB3 was brought to proposal.
I've tried to get rid of it at first, but it clearly splits tool's behaviour between default numeric input and geometry-based Basepoint input.
So, that's the key to whole solution)

One of the mentionable problem, I were also thinking about, is that it is a bit discomfotrable pressing GR2Z for multiple times in a row, for example, during 500 windows to wall alignation.
But if this task appears such often, it will be much better to script this shortcut for a separate simple tool locally.
So, it will be nice if API part of B.A.S.E. proposal will allow making such scripting easier.

Besides modal maps, if these were also exposed as operator options for the move, rotate and scale tools, we could even define custom key map entries for direct access to any desired combination of base points

I know that this is more for development purposes, but precision modelling does bring up a certain topic which is not really covered by most 3D applications (apart from Rhino)....

The precision of the world, is reduced further away from 0,0,0 you are, which for a general scene is fine... The problem that we are running into, is working with CAD diagrams, which are georeferenced, means that we have to preprocess the CAD to work around 0,0,0, rather than to work in their native mapping method. To put it in perspective, a project we are currently working on, we have moved the diagrams from 371000,6600000,0 to 0,0,0. becasue working at 371km by 6600km away from the origin is way to inprecise.

I hope this 'precision modelling' improvements, improve the accuracy of scenes not based around 0,0,0. Or being able to set where the actual 0,0,0 is behind the scenes etc.etc.etc. or able to increase the precision (not sure if blender works like this but using double over float) would help aswell.

In T66337#736695, @Carlo Andreacchio (candreacchio) wrote:

...
I hope this 'precision modelling' improvements, improve the accuracy of scenes not based around 0,0,0. Or being able to set where the actual 0,0,0 is behind the scenes etc.etc.etc. or able to increase the precision (not sure if blender works like this but using double over float) would help aswell.

Even if this brings benefits to precision, it would bring regressions to memory and performance. (And would require a lot of work to get it done.)
In theory, to remedy the memory problem, we could just turn the matrices (of viewport and objects) as double precision. This would convert local coordinates (single precision) to global coordinates in double precision. Thus objects could be moved over long distances.
But that wouldn't solve the performance problem (which is hardware dependent) and changes of this kind can result in many bugs for older graphics cards with limited double precision support.

So it takes much more convincing arguments for developers to start such a task.

In T66337#736709, @Germano Cavalcante (mano-wii) wrote:

Even if this brings benefits to precision, it would bring regressions to memory and performance. (And would require a lot of work to get it done.)
So it takes much more convincing arguments for developers to start such a task.

For sure. That's the problem of computer system's capacity, and it cannot be fixed.
Professional CAD systems (like autoCAD) have about 8 digits of precision before and after dot.
In practice, if it is too far away from origin in AutoCAD (about to 10e16), at some point it starts to behave like values doesnot have digits after dot - even cursor movement "snaps" to grid of integer values, as it uses all available 16 digits for integer part of coordinates.

Professional mesh systems like B3D, Maya, 3DSMax, C4D always have about 3 digits of precision after dot, that shrinks accuracy at lesser distance, bringing jitter to values, but it also brings a huge perfomance boost for animation and art.
That's why they can store so much geometry in scene, comparing to AutoCAD.

I produce baroque models scaled up to 100 times - that allows to aviod jitter of thin edges that are lesser than 0.001 after saving file.
We also working with 50km squares with precision of doorhandle, so we just setting some point with round value as zero (for example, x =357000, y =756000) and using this vector for translations between CAD and any mesh editor.

This is the only way for computer systems available today.
Writing CAD engine with PBR support for Blender is definitely out of scope for current task.

In T66337#736721, @Paul Kotelevets (1D_Inc) wrote:

Professional mesh systems like B3D, Maya, 3DSMax, C4D always have about 3 digits of precision after dot, that shrinks accuracy at lesser distance, bringing jitter to values, but it also brings a huge perfomance boost for animation and art.

For single precision-floats (what Blender and the other mesh systems use), the rough guide I go by is 7 digits (figures) worth of precision. In other words, you should be able to store all 3 values below in Blender without losing a digit.

1234567.0
123.4567
0.1234567

I made a "digits of pi" script to test this out when I was working on my first version of Exact Edit (Exact Offsets).

Well, python's math is not the way blender stores data.
In practice, everything below 2-3 digits after dot is risky even if it is near to scene's origin because of jitter.

This is not related to Python math. The data you have access to through Blender's UI gets rounded before being displayed. This happens because values like 1.2 are easier for most people to understand and work with than 1.2000000476837158 (or 2^-22 * 5033165). All major 3D packages do this with the floating point data in their UI to varying degrees.

You can verify the above by entering the bottom 2 numbers in my last post for coordinates in Blender's UI (Blender will not let you enter 1234567.0 because that exceeds the max value it allows for coordinates, 10000).

Go into object mode, select any object in the 3D view, open the "N panel" and for the selected object's "Location" setting enter 123.4567 for the X value and 0.1234567 for the Y value. After you have entered those values, Blender's UI will show them rounded as something like 123.46 and 0.12346 (do not click on the Location number entry boxes again because Blender will mess up your values).
If any BF devs are reading this, why is it not
if input_string == displayed_string: return unchanged_float ?

Anyways... with those 2 values entered (and without selecting a different object), switch the editor over to Blender's Python console and type (or paste) this into the console:
bpy.context.object.location[:2]

Now press Enter. This is what Blender will return:
(123.45670318603516, 0.12345670163631439)

Note the full 1234567 part of the values you entered is still there in both numbers.

Regarding the key sequence described to call basepoint grab/rotate/scale, I have a suggestion:

1.If we call G: start grab command;
1.1. Traditional grab command will start working the same way it is today
1.2. If we call B: blender waits for a basepoint wih a mouse click
1.2.1. If we click in a second point if moves the object
1.2.2. If we call B again (after the basepoint was clicked): blender waits for a secondpoint

The ideas Paul described above, such as 2 and 3 basepoint transformation, would be incredible for architectural work. Although I agree that a big sequence of keys is annoying. I think we could hit B before each basepoint until a maximum of 3 so blender would understand which command we want. Another thing is that it would not create confusion with distance (2 or 3 units)

Another thing is: if we could toggle on/off basepoint transformation would be great. If I could toggle it on, I would use almost every time grab with 1 basepoint.

A third thing that should be considered in the “precision modelling” is the ability to toggle on/off orthogonal only transformations. It would work just like ORTHO on AutoCAD. For me, I need to hit X, Y or Z all the time when I’m moving an object.

In T66337#739928, @Ugo Santana (ugosantana) wrote:

I think we could hit B before each basepoint until a maximum of 3 so blender would understand which command we want. Another thing is that it would not create confusion with distance (2 or 3 units)

That's, actually, interesting idea) For further conversation I will replace "setting base point with click" with "+" sign. That means

GB+B+ (instead GB ++) will bring 1point from-to translation
GB+B+Z++ (instead GB2Z ++ ++) will bring 2point
GB+B+B++++ (instead GB3 +++ +++) will envoke 3point alignation.

I like this concept, because B key clearly defines that user want to set a basepoint, and how much of them.
Similar type of behaviour I've designed for F2 tool, where single F key builds different types of quads, depending on selection context.

This behaviour brokes on R a bit. There is no RB2 between RB and RB3.
It is not critcal, that means that blender can just wait for 3rd B point after 2nd to finish operation.

Scaling is a bit controversial.
It will became SB+B+B+ to define SB, and SB+B+B+B+ to define SB2. It is longer, and also means, that there will be jump between 3rd and 4th "B+" action. Also not critical, if expected.

Some problem can cause defining operation for repeat, for example - RB3Z is a "name" of function. If to make function that repeats latest transform, it can show that it currently repeats RB3Z action.
Unnamed invoke can also cause problems with tools description.

Also like ability to set different type of snaps for different basepoints during evaluating - for example GBV+BE+BF+V+E++, where V, E and F - switching vertex, edges and face snap type.

Another thing is: if we could toggle on/off basepoint transformation would be great. If I could toggle it on, I would use almost every time grab with 1 basepoint.

That will be not possible, if to bring alignation extention, but it will available with "repeat last transformation setup" function.

A third thing that should be considered in the “precision modelling” is the ability to toggle on/off orthogonal only transformations. It would work just like ORTHO on AutoCAD. For me, I need to hit X, Y or Z all the time when I’m moving an object.

Sounds interesting.
Anyway, GX is the most clean an simple syntax, that's, actually, good, need to think about it.

Also, main tread about basepoint alignation extention is located here:
https://developer.blender.org/T66424

A third thing that should be considered in the “precision modelling” is the ability to toggle on/off orthogonal only transformations.

I second that. Although MMB in the general direction of wanted axis does this pretty good at this moment. It is one of the most efficient Blender's modeling features.

EDIT: i removed the suggestion for the otho snapping, it is not usable in this case, sorry