0
$\begingroup$

I've modeled objects that I wanted to adjust some vertices for so that way the edges would have an even measurement. (I use the Measure it tool to determine the distance between vertices.) However, I found that when I would use Absolute Grid snap to snap the vertices to the grid it wouldn't always give me a precise measurement despite the fact that I would have set the units I wanted (my units are set to centimeters). For some reason the measurements work much better with meters, but for centimeters specifically, it seems like there's a slight margin of error. I'll show what I mean. The first 2 images are the same picture. One is just zoomed in a little more. As you can see both decimal points are on the squares of the grid and I made sure it was snapped to them.For some reason though the units aren't exact. It seemed a lot more exact with Meter measurements, but no so much with centimeter measurements. I then went back in and checked with the measure tool and snapped it to the 2 vertices shown on the picture and got similar results. I don't know why it's like this. Perhaps it's just something about Blender measuring the centimeters after you've transformed an object a certain amount of times. That's why I was wondering if there was a solution or work around to this. enter image description here

enter image description here enter image description here

Improve this question
$\endgroup$
7
  • 4
    $\begingroup$ Can you include a screenshot? It isn't entirely clear to me what you mean. Bear in mind that snap to grid uses the grid based on how far you are zoomed in, so if you are zoomed closer it will start to use sub-grids (1/10 the size of the larger grid). $\endgroup$
    – edna
    Commented Jun 21, 2019 at 5:00
  • 1
    $\begingroup$ The question is not logical, because snapping to grid is reliable: imgur.com/a/4KEl2XX. You should form a question around the issue you are experiencing not around your expectations of how some functionality should work with some specific, possibly wrong way you are using it. There are other ways to make sure the distances between some vertices are even as well. I am sure you could get very good in depth answers about solving your problem if you just asked about it specifically and provided all the context, for example you should post pictures and describe what you do in more detail. $\endgroup$
    – Martynas Žiemys
    Commented Jun 21, 2019 at 7:05
  • $\begingroup$ maybe you need to switch to snap to Absolute Grid so that it snaps to the actual grid of the 3D scene $\endgroup$
    – moonboots
    Commented Jun 21, 2019 at 7:59
  • $\begingroup$ One thing to consider about precise values - values in Blender are 32 bit floats. They are not infinitely precise and errors occur because of decimal and binary number conversions as well. If you for example create a cube at the scene's center and move it 0.1units in x direction and then type bpy.context.object.location.x to the Python Console you may get 0.10000000149011612 . $\endgroup$
    – Martynas Žiemys
    Commented Jun 21, 2019 at 9:22
  • 1
    $\begingroup$ It seems you are looking at 8 digits in a number. That's too much to be stored as 32 bit float precisely in all possible instances. See en.wikipedia.org/wiki/Single-precision_floating-point_format There is no problem with snapping or measuring, the issue is with the actual stored values of vertex positions. That should not be a huge issue in CG in most cases. $\endgroup$
    – Martynas Žiemys
    Commented Jun 21, 2019 at 12:45

2 Answers 2

Reset to default
3
$\begingroup$

A few things to note about 'Snap to Increment'

  • In Object Mode, it snaps the mean position of the pivot points of selected object(s), in Edit Mode, the mean position of directly or implicitly selected vertices.
  • It snaps to the grid increments you can see. (If you're zoomed in, the increments may be subdivisions of the increments when zoomed out)
  • If Absolute Grid Alignment is switched off, you are constrained to move elements by units of the smallest increment you can see. If switched on, you are constrained to move elements to the nearest grid point. (In the first case, elements won't necessarily wind up on a grid point)
  • Whatever your view, the snap is to an orthogonal projection down onto the grid you can see. If you're viewing at an angle, or in perspective, the snapped element won't necessarily appear to coincide with the grid you can see, until you adopt an orthogonal view straight down onto it.
  • If using in an orthogonal view, it will also snap in the dimension you can't see. (So for example, you're looking straight down Z, snapping in XY, starting off-grid in Z, there may be some unwanted movement to the nearest Z grid-point, unless you constrain the movement. (GShiftZ)

A few of these things might give you the impression the increment snapping 'isn't reliable', and can make it counter-intuitive to begin with . But it works as expected.

EDIT: This answer doesn't really answer the question, since it has become one about precision.. but I'll leave it up..

Improve this answer
$\endgroup$
2
  • $\begingroup$ I've been using snap to grid every time I tried to even things out. So does that mean there isn't an easier way to get precise values when I use the grid? Or does that mean that I would be restricted to not zooming in or zooming out? $\endgroup$
    – Big Mike
    Commented Jun 21, 2019 at 8:43
  • $\begingroup$ Holding down shift while moving will divide the visible increment by 10... but if I know I'm going to have a lot of movements by X, or rotations by Y, I usually make myself a jig.. an object such as a grid, or divided circle, which exists only for its vertices to be used as snap targets. $\endgroup$
    – Robin Betts ♦
    Commented Jun 21, 2019 at 9:06
0
$\begingroup$

I've found the solution to my problem, through some more trouble shooting. The problem was that although the vertices were snapped to the grid in top view, in side view it was not completely perfect, which created a slight discrepancy when it came to having zero's behind it. I didn't think this was even a possibility so I had ignored it. To clarify why this didn't seem so obvious is mainly because I have at times tried getting both the decimal points as even as possible in both top and side view, and the measuring line (from the measure it tool and the regular measuring tool) would look straight, yet still could be just a smidgen off and would still need fine tuning. For example if there's 2 points on a line, and 1 point is slightly higher than the other, even if it's just slight, it does add to the length of the line, (at least in Blender). I'm just glad I can finally put this problem to rest.

Improve this answer
$\endgroup$

You must log in to answer this question.

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