3
$\begingroup$

I have this weird problem where I zoom in a lot and the vertices don't line up perfectly. Each edge goes to "on its own floor" and when I return to the file after saving, they often have moved. I know it's all microscopic and no one can see it, but it bothers me when I'm dealing with many objects facing side-by-side. Why is it like that? How hard would it be to keep everything perfectly straight?

enter image description here enter image description here enter image description here

$\endgroup$
1
  • 1
    $\begingroup$ Hello and welcome to BSE. It's difficult to tell what exactly the problem is because we don't know how you modeled this. Maybe you can create a simple example demonstrating how you place a simple set of lines that reporduces this issue? Also it's important to note that Blender is not a CAD software. Have you tried selecting all with A and press M > Merge By Distance? $\endgroup$
    – Harry McKenzie
    Commented Jun 14 at 14:24

1 Answer 1

3
$\begingroup$

I can't be sure this is the reason, but I'll post this as an answer as this is one possible reason.

TLDR: DON'T rotate geometry in Edit Mode

Take a point like $<a, 0>$ and rotate it by $90°$ (pivot point at origin). Now the point is at $<0, a>$, the $y$ coordinate became the $x$ coordinate. For example, $<1, 0>$ rotated by $90°$ becomes $<0, 1>$:

In this case, when the components of the coordinate just swap places, there is no data loss, but more generally, any point $<a, 0>$, rotated by $θ$ becomes $<\sin(θ)a, \cos(θ)a>$ and this already introduces a problem, because if you look into a simple trigonometric table:

then you can see the trig functions sometimes produce irrational numbers, but this is not even your problem. Instead let's just look at the $\sin(30°) = {1 \over 2}$ - this is already a problem. Each coordinate component (e.g. $x$ coordinate) is stored in memory using float32 format, which has exactly 24 binary significant digits of precision. To make it simpler, I'll explain the problem in principle, using a hypothetical format, that stores a number in decimal, and has a limit of 5 decimal digits of precision.

So imagine you have two points:

  • $<0.001, 0>$
  • $<0.0001, 0>$

They are clearly aligned, both sitting at $y = 0$. Now rotate them by $30°$:

  • $<0.001\sin(30°), 0.001\cos(30°)>$
  • $<0.0001\sin(30°), 0.0001\cos(30°)>$

Now, let's only calculate the $x$ components:

  • $<0.001 {1 \over 2} = 0.0005, 0.001\cos(30°)>$
  • $<0.0001 {1 \over 2} = 0.00005, 0.0001\cos(30°)>$

The 2nd point exceeded the 5 digits precision, so it must be rounded to the nearest possible value within its format. It's either $0$ or $0.0001$ (no change). Either way, it's incorrect! You just introduced a precision error. The more you modify your geometry, the more errors you will accumulate. Also worth to note, the error here applies just to one point, which means the errors can affect points to various extent misaligning them.

Now when you know the theory, how does it look in practice? Well I simplified and limited the hypothetical format to just digits, in reality it's limited to significant digits. There is also an exponent limitation, so you can go pretty far but not infinitely far to the right of the dot - the smallest non-zero number you can store in a float32 is 0.000000000000000000000000000000000000000000001.... However, force all zeroes to become significant digits by putting $1$ in front, and now the smallest such non-one number becomes 1.0000001..., which is way shorter, just 8 digits! In general, float32 is said to be able to store between 6 and 9 significant decimal digits.

Test it out yourself: in Edit mode, in N Numbers Panel, set a vertex coordinate to $<1000 m, 0, 0>$, then zoom in on it as much as possible, duplicate it a few times and rotate the group:

You can see the vertices move smoothly on $y$ axis, because that coordinate component is close to $0$, and they are snappy on $x$ axis, because on that axis it's $1000$ (meters) away from origin, stealing 7 significant digits from their precision (the height of the zoomed area is only maybe $0.0004$ m)

The solution: try to define your vertices as close to origin as possible, and avoid repeatedly scaling, rotating, moving (translating) your geometry in Edit Mode. For example if you want to see how your door looks like at different angles, position the origin at the center of the hinge and rotate the door in Object Mode.

$\endgroup$
2
  • $\begingroup$ Thank you for the answer. I reinstalled blender and the vertices behave less chaotically now (I don't know why). I also noticed that there is almost no snapping in World Origin, and as you move up the Z axis, the snapping becomes more and more wider (minimum cap between vertices). Why is it like that? $\endgroup$
    – virxest
    Commented Jun 17 at 9:44
  • $\begingroup$ @virxest maybe for the same reason x and y behave diffetently on my gif $\endgroup$ Commented Jun 17 at 9:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .