Thank you for the information, looking forward to seeing it!
I’m talking about document tolerances, which is the reason for the different templates in Rhino.
The grid you have shown is great! The other stuff they are hiding successfully 
1 Like
Oh no, don’t get me wrong, I fight with DS R&D all the time. it’s my job 
Make the Cloud account into a sharing channel for various settings and files, like Templates, Display Modes, Plug-ins etc. Send (share) to other accounts via their registered email.
Make it possible to create “Target Groups” in the Cloud account. Not collaboration groups, but target groups for mass distribution of certain items (companies and courses etc).
Rhino.CadHub
// Rolf
1 Like
that’s how I sync my settings across devices.
Custom template files only need to be copied into the directory location which the New command references, and can be deployed separtely from Rhino installation. No changes to Windows registry, etc required.
Custom template files can include title boxes, logos, borders, and any other desired content. Also the template file can be customized for the DocumentProperties settings: DocumentProperties | Rhino 3-D modeling
Is everyone aware that users can change the size of the grid at any time and are not restricted to the grid size in the template file selected when the project is started? And is everyone also aware that changing the gtrid size has absolutely no effect on geometry. And unlike changing the absolute tolerance during a project which can cause problems with the Join command and similar the grid size is not involved with any commands. (Grid spacing does affect snap to grid but the extent of the grid does not affect snap to grid.)
@wim Is Angle tolerance on the list of potential changes to the template files in V7? I believe the default used in the templates should be on the order of 0.1 degree rather than the 1.0 degree in the current templates.
What are the disadvantages (if any) of setting the grid size to the current maximum of 100,000 lines each of the origin? Could the maximum number of lines be increased, say to 100,000,000? Is the grid an object which is calculated once and saved in Rhino, or is it calculated on the fly as needed for display purposes?
Been asking for that since, like, V2…
I think that’s it, it puts a big load on the display as it is currently implemented…?
David, Mitch, yes, angle tolerance is also on that list.
As for a larger amount of grid lines, yes, as Mitch says, on some systems this would significantly reduce performance. The number of systems where a large number of grid lines leads to problems has probably decreased over the years but increasing the amount a few orders of magnitude would likely have more systems seeing that again. Then again - I should probably let someone who knows what they are talking about answer that… @jeff or @stevebaer?
-wim
1 Like
Rhino still performs quite a few calculations to draw the grid and this does get slower as the number of lines increases. This is something we can improve on in the future; it just hasn’t been as big of a priority for optimization as actual geometry.
1 Like
Well, why do we actually need a larger amount of grid lines? If the grid is larger, the line spacing can be larger too. Does anyone really use it for measuring? Mostly it’s there as a visual indicator of where your CPlane is. (not talking about grid snaps here)
For that purpose, if you have a 100mm grid, a 1mm spacing makes sense. If you have a 1000mm grid, a 10mm spacing makes sense. If you have a 10m grid, a 10cm spacing makes sense…
that depends on the product you’re modeling.
e.g. 300+ meter cruise ship: you want to do some precise work on the bridge. The grid should be huge to get to 200k mm off origin point but you need mm, or at least a decimeter snapping, and if there’s snapping you need a grid so that snap doesn’t happen in empty field.
just tested this:
- 350 000 major lines (1 meter apart) and 10 mm minor lines - rotating an empty viewport = 35 fps
- 1000 major lines (100 meter apart) and 1 mm minor lines = 450 fps
measurement is based on the NVidia overlay dislpaying FPS on all OpenGL and DX applications. I get one fps counter for each viewport displayed on screen.
Read my post - not talking about snapping… are you going to count the grid lines?
I know, but snapping without grid is…unpleasant. 
Anyways, I also believe it isn’t…
for me at least. I’m used to not using this grid or snapping for that matter.