3
$\begingroup$

Is there any option or an addon that would disable auto grid subdivision when zooming in viewport?

Basically I just want the grid to always behave the same as it does in orhtographic view - stay to the specified scale, never subdivide on its own and ideally offer a couple of hotkeys to alter the grid scale quickly.

I found the "Minimum Grid Spacing" parameter in the options, but it seems to have no effect no matter how high or low I set it.

$\endgroup$
2
$\begingroup$

Subdivisions option in the Display rollout controls how the grid subdivides while zooming in the preset orthographic view:

Subdivisions
Controls the number of sub-lines that appear in each cell of the grid. In aligned orthographic views the level of subdivision depends on the zoom.

To stop the grid from subdividing at all set amount of subdivisions to 1. You might want to adjust Scale option to make the grid less big:

GIF ortho views preventing grid from subdiving

Note that this won't work in any other unit system except for the None which is by default, because both Metric and Imperial already have predefined spacing between grid cells so they aren't adjustable.

$\endgroup$
  • $\begingroup$ Thanks, apparently I didn't fully understand how this parameter works. It pretty much answers my question, but introduces a different problem. What I'm trying to achieve is to tweak the grid to make it easier to work with hammer units, so I set grid subdivisions to 1 and scale to 128. Everything works perfect, except for the length display: for some reason with such a big grid scale, blender decides that 128 is too big of a dimenstion and displays it in power of ten format (1.3+002) which is completely unreadable. I wonder if there is a way to disable that now. $\endgroup$ – OddlyVivid Dec 28 '16 at 15:46
  • $\begingroup$ As I checked it seems to be caused by Scale in the Display panel increased. Once it's more than 10, the values of the displayed length which is more than 100 will be converted into ..e+.., (more than that, it does that for every step of the floating point, scale of 0.1, 1, 10 etc). I can't tell if that's a bug because as scale changes so does the precision. $\endgroup$ – WKG Dec 28 '16 at 19:21
  • $\begingroup$ yeah, checked myself, that's exactly how it behaves. Seems like a bug to me - It should probably be the other way around. $\endgroup$ – OddlyVivid Dec 28 '16 at 19:43

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.