Grid is far away in Big drawings

On the process of Architectural big building drawing, I need to see the grid with axes. But as the drawing is a big one - grid is always far away … What should I do in order to be able to see it close to the place where I work? It is very confusing to work without it…

This is a side effect of using a tool designed for Industrial design for Architecture.
Product design and styling is all centered around the coordinate origin for machining, STL printing, and other manufacturing tasks.

Architecture is a design world with unique needs that are at odds with Industrial design.

It is unclear to me how to easily and seamlessly accommodate both.

Have you tried changing the size of the grid? To do so you can use the DocumentProperties command or Properties tab and go the Grid, or use the Grid command.

Thank you , Yes, I have tried to change the size. It doesn’t help… Still far away

If you absolutely need to have a grid in place where you work, you can always place a custom CPlane at any location, in any orientation.

Note that if you are modelling far from the world origin (and a custom CPlane does not change that), you might run into display problems. Read here for an example and some info on that:

Thank you very much !!! 1- I have tried again to change the size of , this time to a bigger one, and it’s great !!
2- C-planes id good as well 3- In the link that you sent there was a problem of jagged geometry because of being far away from origin. I have same problem… so now I have the answer for this subject as well :blush:
4- I LOVE THIS FORUM , thank you all

Somehow we need to. Architecture is one of the driving forces behind Rhino sales at the moment, if that can’t be accommodated, we can all go home…


1 Like

Please don’t bog down Rhino with more drafting tools!!! Could it be accomplished along the lines of T-Splines as a well-matched plug-in only for those who really need it?


A major market segment of Rhino is architectural and interior design. That market segment needs reliable layout and printing tools. They do not have to be as extensive and messy as AutoCAD - hopefully not! - but basic layouts and page setup for printing are still essential for construction-site humans to be able to read drawings - up until such time as we are able to manufacture buildings 100% robotically.

If you want a gauge of how important this is to people, check out the Mac Rhino section of the forum. Mac Rhino doesn’t have even the current layout functionality of Windows Rhino yet (it’s coming). Have a quick count as to how many people have asked about layouts recently…

Oh, and what this thread was actually started about has nothing to do with drafting tools…

1 Like

Two words: Feature bloat.

There’s not a perfectly clean way currently, but there are two options that come to mind.

Since Rhino was intended to be used with the World 0,0 origin near the center of your work, the Grid is centered around 0,0. You can change the Grid settings to be much larger so it extends far enough out from World 0,0 to include your working coordinates area.

The other is to shift the Viewport Construction Plane origin to be closer to your model.
Use the CPlane command with the Option origin. By default this will shift only the CPlane origin of the current viewport. If you go into Options > Modeling Aids, and switch your Construction planes to Universal construction planes, then changing the CPlane origin in one viewport will shift the origin in all the viewports.
By default the coordinate display in the Status bar is set to report CPlane coordinates. If you want to see the unshifted coordinates displayed, click the CPlane label in the lower left corner of the Status bar so it will display World coordinates instead.

In either case, avoid using State Plane coordinates or you will run out of decimal place accuracy and see a lot of confusing problems. It’s better to shift your project coordinates to be closer to World 0,0.

Two letters: BS


Yes, it is troubling me that I have now seen a couple of occasions where @John_Brock seems to essentially be saying that Architectural design doesn’t matter because rhino is an industrial / product design tool. That may have been the case originally, and I don’t know what the relative market sizes are, but Rhino is one of the big modelling tools used in architecture.

I think there is a big argument to say that the market is who buys it, not what the makers say it is.

As the company making it, and as a representative of that company, it is very worrying to hear that the market I am in appears to not be valued as much as others. Rhino has become a vital tool for us but if new tools directed towards our market are considered important then eventually something else will come along that does.

The above is a general concern.

Specifically relating to this post, most modelling tools work better when the geometry is close to the origin. It I know it applies to Revit and Microstation. I suspect that it applies in 3DS Max and Maya etc too.

You’ve mischaracterized my reply.
When we designed Rhino, we chose the much smaller industrial design market segment because as a small company with limited resources, it was a size we could deal with without being steam rollered by it. Also, it was poorly supported by software tools available at the time.
We intentionally avoided architecture because of it’s huge size and because it was well supported by many successful applications.

That was a while ago. Rhino is no longer a little start up application. The developers are still a small, privately held company, but our reach is much wider with the help of our users.

Grasshopper has made Rhino attractive to architects.
I think it would be a mistake to abandon our industrial design focus and shift to architecture. At it’s core, NURBS surface modeling is better suited to industrial design and product styling.

So I repeat: Architecture is a design world with unique needs that are at odds with Industrial design.

It is unclear to me how to easily and seamlessly accommodate both.

That doesn’t mean we won’t try and hopefully eventually be successful, but I don’t know how we will do that.

Oh come on! That’s just rude. Feature bloat is known phenomenon that has brought originally well drawn programs to their knees (see Photoshop). I was merely expressing my concern that Rhino not fall victim to that dreaded malady.

I was just saying how it comes across. The other thread where you more forceful, it really did come over as rhino was and will always be focused on product design. Like it or lump it.

If the market segments size disparity is as you say, then ignoring the needs of architects would seem rather silly. Dare I say it, meeting the needs of architects should probably be prioritised even if it is to the detriment of product designers. I say that, but I would be very interested to know what things are so conflicting?

The boundaries between the two are, I would believe, often not so clear. I think those who want rhino to be a fully fledged BIM / Drafting tool are looking in the wrong place. It just isn’t what rhino is for.

Many needs of the architecture world would surely also be positive for product designers. The main problem I have is dealing with a 500mb file, that rhino really struggles where other programs seem to handle it better. That’s both manipulating the geometry and, in all honesty, just navigating around the model.

Back on topic, the issue of working far away from the origin, which can also create a lot of visual artefacts. If using rhino for architecture, you normally start a model from 2D line drawing, whether a site plan or another drawing. The best thing I have found is to create a line that describes the translation from the coordinates where the (usually) DWG file imports to the rhino origin. Save this line on a locked layer. You can then use this translation (snap to each end) when importing and exporting geomtry.

[quote=“dmoyes, post:15, topic:26869”]
Oh come on! That’s just rude.

[/quote]No, not rude, just factual. “Feature bloat” is just a general term used by people to describe anything that they don’t think they personally need in a program. What is a “feature” and what is “bloat” is in the eye of the beholder.



Rest assured in the knowledge that I have little or no say in the direction Rhino development takes.
I do testing and tech support. I act as a user advocate when working through problems and issues.

When I hear complaints about why Rhino does or doesn’t do something in a way that isn’t useful for the focus of a specific user’s needs, like this grid question, I try to explain the background so what is there now and how it works will make more sense in the context of who the tool was designed for in the first place.

It’s intended to further the discussion, not to end it.

1 Like

That’s true except when all the added features that you don’t want suddenly
interfere with the use of the features that you DO want. Or when those added
features work badly as happened when AutoCAD tried to become a 3D modeler
and turned into a kludgy, slow-moving ogre of a 3D package. As I said in
response to another thread, perhaps the additional drafting features could
be a well-matched plug-in like T-Splines. Then those of us who draft
elsewhere (or not at all) won’t be burdened with features we don’t need.
Trying to be all things to all customers can rapidly lead to being mediocre
to all.

A dynamic screenspace grid can not be very difficult to program, it has been on the wishlist since V1 and your very own David even made a plugin for this many years ago.

Also the templates for big objects mm (etc) has very small grids as default.

So I vote for this too! (again ;))