The Grid. The most kicked about lost child of Rhino

Hi,
The Grid. The most kicked about lost child of Rhino can and should be made better. It’s current implementation has not changed much since v1 and really is suffering.
I wrote many wishes for the grid but they just fly over McNeel, many times I use different kinds of grids created from geometry under what I am building. Maybe to an average programmer they do not understand, but for a designer of any involved object/s grids and geometrical structures are always used. One only has to look at the literature on the subject:
Classical architecture The poetics of order to see how grids can be used also any books on design be they modern or antique from prehistory to now all show the controlling factors and uses of the grid. Rhino needs to get up to snuff on it’s grids.

We should have:
1.Other grid types that we can define other than current subdivisions,
2.Circular triangular and other geometric types of grids and other types in this vain. Or is this a test command you guys are hiding?
3.Define girds more easily per view and ability to store per named cplane not in options.
4.(Why if I type “Do away” after four it puts a hyper link to yahoo automatically argh) anyway Do away with the grid controls in options and allow per cplane freedom, association naming and objectivity.
5.Allow more decoration of grids in color, line type and labeling.
6.Ability to set where the lines are drawn i.e. if I only use one quadrant of the grid then the grid should reflect that. I usually don’t need the left hand side of the grid I orientate with sections to the object I m working on, locating the cplane origin on the lower left side of the object or it’s first 0,0,0 coordinate therefore I don’t need to see all the other useless lines in the negative quadrant.
7.Symmetry option for modeling needs to get better and be combined with the grid why are we still using archaic methods when all other programs have good symmetry by now.
8.Other users have suggested many other things I wish would make it into grids as well and should be looked at.

RM

4 Likes

Many good suggestions. These and many more have, as you point out, been made over the decades that Rhino has existed. It’s obvious that the people at McNeel have no interest in grids and really never have, given the feeble token effort the current grid system represents and their persistent ignoring of user pleas.

I believe those of us who can envision a truly useful grid system and would delight in using it if it existed apparently have no recourse except an armed invasion of McNeel HQ and all satellite locations with a non-negotiable demand for all other work to cease until a surprising and delightful grid system comes into existence.

I think it should be possible to write custom grids with RhinoCommon.

@stevebaer @dale how would that look with python or c#?

How do you think a custom grid would be defined?
Are they always planar?

customly? :smiley:
i´ve seen grids only with points at the intersections without lines, that looked useful.
maybe this along with the ability to make the main lines thinner.

sounds like a 3d grid? would be useful i believe with points which significantly in- or decrease their size depending on their relative distance to the camera including a perspective shading for example.

maybe also polar grids?

not sure anymore about the windows version but the mac version has the option to color the grid accordingly.

You might want to check out Grasshopper:

image

Come for the grids, stay for the poetics of order :wink:

1 Like

The grid

  1. is a visual reference (lines, points…)
  2. has coordinates to snap to (function or list)
  3. has a “geometrical shape” like plane, sphere, cylinder, torus, spiral, helix…
  4. may have multiple (ortho) directions. For example a hexagonal grid.

For an initial example simply planar would be fine :wink:

Being able to define different grid sizes and snap spacings for X, Y and Z would be very useful.

1 Like

And certainly join us for Grasshopper 2 for zoom-aware dynamic grids: https://youtu.be/4fuskXq-_AU?t=25s

4 Likes

Are the desired grid options for illustrative purposes or to assist in modeling?

Some of the suggestions for grid options such as non-planar grids and hexagonal grids would break the association between the grid and the viewport C-plane coordinate system. Also making the grid non-planar would move the grid off of the CPlane.

An important question, as these are two pretty distinct purposes each requiring their own unique feature set.

I can see that for illustration or display purposes that an almost limitless number of features could be suggested.

For modeling purposes I think the most important features are:

A) the ability to place the grid anywhere in the modeling space through custom setting the edge locations, which includes

B) more control over the line styles and colors

C) the ability to easily toggle the grid on and off per viewport.

For me, this is very important, It could be implemented by another button next to the viewport title. or another approach could be to make grid visibility a display mode property so that the user could create a grid off and grid on version of certain modes.

That’s what it is all about. Why not having a cylindrical or spherical grid with platonic snaps? Would be a pleasure for SDS modeling. But there are also technical modeling challenges where more fancy shapes would be very useful.
Project might work towards the grid shape’s normal or closest point.

Another useful thing would be to be able to specify the grid sizes in a dynamic way using a set of commands:
SetGridSizeX, SetGridSizeY, SetGridSizeZ, and then input a number or a dimension using the mouse.
I also find useful to scale the grid up and down. I have a script assigned to Ctrl+2 to double the current grid size, and Ctrl+1 to divide the current grid size.

Funny to see different wishes and modeling styles. Since over 15 years i always turn off the grid.

I only use it to quickly locate the origin.

Given how small or far away the grid can be from whatever location I’m looking at, I find that the easiest way to find the origin is to run the Line command, click in the middle of the viewport and then type 0 Enter.

4 Likes

Oh, I meant visually if I’m modelling close to origin.
For quickly zooming to the origin I have an alias with a macro:
_Rectangle 0,0 100 100 _Sellast _ZoomSelected _Delete

1 Like

Hi,
I want to thank those who replied.

RM

Funny… same here!

me too, only I type 0 and then just hoover the mouse and or zoom and hit esc when satisfied.

1 Like