Snapping & precision modeling improvements #66337

Closed
opened 2019-07-02 13:32:55 +02:00 by Germano Cavalcante · 75 comments

Order of importance:

  • {icon circle color=red} Very Important - These we should handle before the next release.
  • {icon circle color=yellow} Somewhat Important - These issues would be nice to do as soon as possible
  • {icon circle color=green} Less Important - Extra polish, nice to have
  • ? Incomplete - Tasks needing more details before implementing.

Projects

  • {icon circle color=red} #66420 (Snap Options: Midpoints and Perpendicular)

  • {icon circle color=red} #66422 (Transform: Snap to the intersection geometry with the axis constraint)

  • {icon circle color=yellow} #66423 (Edit Mesh: Improve 'AutoMerge')

  • {icon circle color=yellow} #73591 (Transform: Snap to the visualized cage of the edited mesh)

  • {icon circle color=yellow} #66424 (Transform Tools: Perform on a base point)

  • {icon circle color=yellow} #66425 (Tools suport for extended modes: Knife and Bisect)

  • {icon circle color=yellow} #66426 (Edge and Vertex sliding: snapping improvements)

  • {icon circle color=yellow} #69342 (Snapping: Make 'Absolute Grid Snapping' a new Snap Mode)

  • {icon circle color=yellow} D2624: Allow navigating while transforming

  • {icon circle color=green} #66427 (Snap to Grid in Perspective View performed only at ground level)

  • {icon circle color=green} D5242: Rename Snapping menu

  • {icon circle color=green} #70865 (Support for snapping to Lattice objects)

  • {icon circle color=green} #69209 (Snap does not work properly with "Surface" object)

  • {icon circle color=green} #73031 (snap cursor to selected ignores geometry position with modifiers)

  • ? Hot mode switch: Ability to switch snap type during using tools via hotkeys

  • ? Change the current behavior of the incremental snap (Snapping according to the distance to the snapping point and not to the grid)

  • ? New 'Snap With': Cursor

  • ? Improve look of the 'Snap With' Closest (drawing boundbox ends)

  • ? New tool for "drawing" edges on a specific offset

  • ? Support for snapping to Lattice objects

Order of importance: - {icon circle color=red} **Very Important** - *These we should handle before the next release.* - {icon circle color=yellow} **Somewhat Important** - *These issues would be nice to do as soon as possible* - {icon circle color=green} **Less Important** - *Extra polish, nice to have* - `?` **Incomplete** - *Tasks needing more details before implementing.* # Projects - {icon circle color=red} #66420 (Snap Options: Midpoints and Perpendicular) - {icon circle color=red} #66422 (Transform: Snap to the intersection geometry with the axis constraint) - {icon circle color=yellow} #66423 (Edit Mesh: Improve 'AutoMerge') - {icon circle color=yellow} #73591 (Transform: Snap to the visualized cage of the edited mesh) - {icon circle color=yellow} #66424 (Transform Tools: Perform on a base point) - {icon circle color=yellow} #66425 (Tools suport for extended modes: Knife and Bisect) - {icon circle color=yellow} #66426 (Edge and Vertex sliding: snapping improvements) - {icon circle color=yellow} #69342 (Snapping: Make 'Absolute Grid Snapping' a new Snap Mode) - {icon circle color=yellow} [D2624: Allow navigating while transforming](https://archive.blender.org/developer/D2624) - {icon circle color=green} #66427 (Snap to Grid in Perspective View performed only at ground level) - {icon circle color=green} [D5242: Rename Snapping menu](https://archive.blender.org/developer/D5242) - {icon circle color=green} #70865 (Support for snapping to Lattice objects) - {icon circle color=green} #69209 (Snap does not work properly with "Surface" object) - {icon circle color=green} #73031 (snap cursor to selected ignores geometry position with modifiers) - `?` **Hot mode switch: Ability to switch snap type during using tools via hotkeys** - `?` **Change the current behavior of the incremental snap (Snapping according to the distance to the snapping point and not to the grid)** - `?` **New 'Snap With': Cursor** - `?` **Improve look of the 'Snap With' Closest (drawing boundbox ends)** - `?` **New tool for "drawing" edges on a specific offset** - `?` **Support for snapping to Lattice objects**
Author
Member

Added subscriber: @mano-wii

Added subscriber: @mano-wii

Added subscriber: @MeshVoid

Added subscriber: @MeshVoid
Member

Added subscriber: @jendrzych

Added subscriber: @jendrzych

Added subscriber: @FrancescF

Added subscriber: @FrancescF

Added subscriber: @nokipaike

Added subscriber: @nokipaike

Removed subscriber: @FrancescF

Removed subscriber: @FrancescF

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos
Member

Added subscriber: @HooglyBoogly

Added subscriber: @HooglyBoogly

Added subscriber: @filibis

Added subscriber: @filibis

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc

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
XY_ALIGN.gif

Also, some feedback on proposal.
A bit obsolete, but still active.
SNAP+CAD PROPOSALS_01-02-2019.pdf

Such a nice theme! It was was waited for a very long time) I am maintainer of [1D_Scripts ](https://blenderartists.org/t/1d-scripts-bargool-1d-tools-main-thread/668937) - 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 ![XY_ALIGN.gif](https://archive.blender.org/developer/F7603575/XY_ALIGN.gif) Also, some feedback on proposal. A bit obsolete, but still active. [SNAP+CAD PROPOSALS_01-02-2019.pdf](https://archive.blender.org/developer/F7603514/SNAP_CAD__PROPOSALS_01-02-2019.pdf)
Author
Member

@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 ;)

@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)

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?

SNAP_PROBLEMS_OVERVIEW.png

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? ![SNAP_PROBLEMS_OVERVIEW.png](https://archive.blender.org/developer/F7613623/SNAP_PROBLEMS_OVERVIEW.png)
Author
Member

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".

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 #66337#724459, @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

> In #66337#724459, @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 ](https://youtu.be/gfnX5MYXNfk?t=53)

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.

1A.gif

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

2B.gif

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

3C.gif

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:
DD.gif
So we all have fingers crossed =)

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.

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. ![1A.gif](https://archive.blender.org/developer/F7613931/1A.gif) 2 - point alignation (A B - A`B`) allows 2D alignation (which is so useful in architecture). ![2B.gif](https://archive.blender.org/developer/F7613938/2B.gif) 3 - point alignation (A B C - A`B`C`) allows complete 3D alignation ![3C.gif](https://archive.blender.org/developer/F7613940/3C.gif) 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: ![DD.gif](https://archive.blender.org/developer/F7614019/DD.gif) So we all have fingers crossed =) 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.

Added subscriber: @NikitaAkimov

Added subscriber: @NikitaAkimov

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

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)

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:

SNAPS_B.A.S.E. proposal.png
SNAPS_B.A.S.E. proposal.pdf

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?

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: ![SNAPS_B.A.S.E. proposal.png](https://archive.blender.org/developer/F7622550/SNAPS_B.A.S.E._proposal.png) [SNAPS_B.A.S.E. proposal.pdf](https://archive.blender.org/developer/F7622552/SNAPS_B.A.S.E._proposal.pdf) 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?

Added subscriber: @Voronium

Added subscriber: @Voronium

@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

@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 #66337#730138, @DuarteRamos wrote:
@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 #66337#730138, @DuarteRamos wrote: > @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 #66337#730538, @1D_Inc wrote:

In #66337#730138, @DuarteRamos wrote:
@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.

> In #66337#730538, @1D_Inc wrote: >> In #66337#730138, @DuarteRamos wrote: >> @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.

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.

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)

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.

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

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

Added subscriber: @candreacchio

Added subscriber: @candreacchio

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.

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.
Author
Member

In #66337#736695, @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 #66337#736695, @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 #66337#736709, @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 #66337#736709, @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.

Added subscriber: @dgsantana

Added subscriber: @dgsantana
Member

Added subscriber: @nBurn

Added subscriber: @nBurn
Member

In #66337#736721, @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).

> In #66337#736721, @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](https://github.com/n-Burn/Blender-Py-Examples/blob/master/digits_of_pi_float_test.py)" 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.

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.
Member

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.

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.

Added subscriber: @ugosantana

Added subscriber: @ugosantana

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.

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 #66337#739928, @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

> In #66337#739928, @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

Added subscriber: @Okavango

Added subscriber: @Okavango

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

> 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

Added subscriber: @xdanic

Added subscriber: @xdanic
Member

Added subscriber: @ermo

Added subscriber: @ermo

Added subscriber: @justastatue

Added subscriber: @justastatue

Added subscriber: @PiotrKudzin

Added subscriber: @PiotrKudzin

Added subscriber: @cedriclepiller

Added subscriber: @cedriclepiller

No snapping at the center at the face?

No snapping at the center at the face?

Added subscriber: @EjnarBrendsdal

Added subscriber: @EjnarBrendsdal

This is very exciting.
Remember that rotating and moving the viewport when transforming is essential for this to be a succes.
It's simply an impossible workflow if you can't zoom in to precisely pick a point to move from and then zoom
out too where you want to place it...

This is very exciting. Remember that rotating and moving the viewport when transforming is essential for this to be a succes. It's simply an impossible workflow if you can't zoom in to precisely pick a point to move from and then zoom out too where you want to place it...

In #66337#766578, @EjnarBrendsdal wrote:
This is very exciting.
Remember that rotating and moving the viewport when transforming is essential for this to be a succes.
It's simply an impossible workflow if you can't zoom in to precisely pick a point to move from and then zoom
out too where you want to place it...

Exactly my thoughts.

> In #66337#766578, @EjnarBrendsdal wrote: > This is very exciting. > Remember that rotating and moving the viewport when transforming is essential for this to be a succes. > It's simply an impossible workflow if you can't zoom in to precisely pick a point to move from and then zoom > out too where you want to place it... Exactly my thoughts.

Added subscriber: @Dimitar

Added subscriber: @Dimitar

In #66337#766578, @EjnarBrendsdal wrote:
This is very exciting.
Remember that rotating and moving the viewport when transforming is essential for this to be a succes.
It's simply an impossible workflow if you can't zoom in to precisely pick a point to move from and then zoom
out too where you want to place it...

I would also like to to mention how exciting this work is. And also how important to enable moving aroun the viewport while doing transformations is to a typical cad workflow.

> In #66337#766578, @EjnarBrendsdal wrote: > This is very exciting. > Remember that rotating and moving the viewport when transforming is essential for this to be a succes. > It's simply an impossible workflow if you can't zoom in to precisely pick a point to move from and then zoom > out too where you want to place it... I would also like to to mention how exciting this work is. And also how important to enable moving aroun the viewport while doing transformations is to a typical cad workflow.

Speaking of viewport navigation, we have RMB for pan from professional modeling layout.
This brings one of the most often used function ever (viewport pan) to one button from two, and also brings entire viewport navigation to one hand with mouse.
Hope this will also be taken into account.

Speaking of viewport navigation, we have RMB for pan from professional modeling layout. This brings one of the most often used function ever (viewport pan) to one button from two, and also brings entire viewport navigation to one hand with mouse. Hope this will also be taken into account.

Added subscriber: @Jaydead

Added subscriber: @Jaydead

Added subscriber: @Russ1642

Added subscriber: @Russ1642

Added subscriber: @Schiette

Added subscriber: @Schiette

Added subscriber: @yebyte

Added subscriber: @yebyte

Added subscriber: @ReinhardK

Added subscriber: @ReinhardK

Added subscriber: @jc4d

Added subscriber: @jc4d

Added subscriber: @Zeirus

Added subscriber: @Zeirus
Author
Member

Closed as duplicate of #73993

Closed as duplicate of #73993

Added subscriber: @Nominous

Added subscriber: @Nominous

Added subscriber: @Qwerkie

Added subscriber: @Qwerkie

Added subscriber: @Moult

Added subscriber: @Moult

Added subscriber: @mudino

Added subscriber: @mudino

Added subscriber: @IihT2cWA9xiP30BsYphz3EiEISNoScoe

Added subscriber: @IihT2cWA9xiP30BsYphz3EiEISNoScoe
Member

Added subscriber: @kursadk

Added subscriber: @kursadk
Member

https://developer.blender.org/T73031 should have higher priority in my view, it just looks and feels like it is broken.

https://developer.blender.org/T73031 should have higher priority in my view, it just looks and feels like it is broken.

Added subscriber: @VupliDerts-2

Added subscriber: @VupliDerts-2

Added subscriber: @Michael-Drake

Added subscriber: @Michael-Drake

Added subscriber: @apprenti90

Added subscriber: @apprenti90

Added subscriber: @Yuro

Added subscriber: @Yuro
Sign in to join this conversation.
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
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
40 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#66337
No description provided.