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

$\endgroup$
  • 3
    $\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 Jun 21 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 Jun 21 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 Jun 21 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 Jun 21 at 9:22
  • $\begingroup$ Apparently I had jumped the gun. When I measured in Blender before the units were set to meters, but when I changed them to centimeters, I encountered the same problem that I edited into my question above. There's screenshots this time so that way there's more context. $\endgroup$ – Big Mike Jun 21 at 10:33
2
$\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..

$\endgroup$
  • $\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 Jun 21 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 Jun 21 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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.