Wish: far from origin


A wish for Rhino 6 is that the ‘far from origin’ problems be solved.
there is a process here that describes a workaround: http://wiki.mcneel.com/rhino/farfromorigin but it really is still very cumbersome and not ideal if you are working with architectural projects that have a lot of seperate drawings (xref) that need to be inserted and updated on a regular basis.

Hope to see this solved in Rhino 6 or Rhino 5SR


Great that you bring this up again.
I presume a dynamic Origin for the displayengine should solve this. It could recalculate everything based on the cameratarget whenever the target is moved x units from previous calculation, or just use the boundingbox center of all visible objects. If moving the objects solves the issue then moving the origin would too. Subtracting say 20.000.0000 units from X and 30.000.000 from Y can be done on the fly, for any calculation, without messing with the floating numbers, so it should be solvable quite easily. The job would be to find the solution that requires the least reprogramming of other tools. With so many architects using Rhino I strongly recommend you solve this as soon as you start working on V6.

And then add a dynamic grid and you have solved two decade old wishes in one go :smile:


Agree 150% must have solution if you are in architecture.
Perhaps something like project origin can be created, were everything can be calculated
from that origin (just a suggestion, not the expert) :smile: smile: .

1 Like

Yeah, we have Cplanes so some kind of Corigin makes sens.

1 Like

I discovered a new thing about this topic that is surprising.
When objects are far from world 0,0,0 the mesh becomes fussy and the model is very hard to work with unless in wire frame mode.
However it seems that blocks don’t suffer from this problem.

So this proves that Rhino is able to display meshes precisely even though they are far from world 0,0,0.
Hope this could be a clue to dev. team on fixing this issue.

1 Like

Is there anybody from McNeel who can comment on this?


@stevebaer - Steve, do you have an idea about this?


Have you tried the V6 WIP? The mesh drawing code has been rewritten and there should in general be better support for far from origin objects. When the mesh itself is located very far from the origin, there is a possibility that the internal values used to represent locations of vertices has lost precision.

1 Like

Hi Steve,

I could not get V6 to open the file. Still buggy I guess.

However I found an workaroundin V5. By ticking ‘custom mesh’ (and un-ticking it again) it seems to refresh the mesh and show it correctly in the view port.
Only problem with this is that the mesh, when rendered, does not render correctly.
Is there a workaround for the render problem? If so I think I’m home safe.

How does that render in the Rhino Renderer? I would think this is a problem with Vray not updating the mesh…
Work-around - when the display mesh is fine, extract the render mesh and hide the NURBS. Render the mesh.

You couldn’t get the file to open at all? Could you please verify this as we would consider this a very high priority bug that would need to be fixed immediately.