Hi,
A wish for Rhino 6 is that the ‘far from origin’ problems be solved.
there is a process here that describes a workaround: Objects Too Far From the World Origin [McNeel Wiki] 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 
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: .
Yeah, we have Cplanes so some kind of Corigin makes sens.
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.
Is there anybody from McNeel who can comment on this?
Thanks.
@stevebaer - Steve, do you have an idea about this?
-Pascal
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.
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.
Bump to bring this back to McNeel attention. At my firm our engineers work in state plane cs, where cad linework can be millions of feet from the origin. It can be a major hassle to convert back and forth between a local coordinate system we make near the origin and state plane cs. Is there any new info about a fix for this issue?
Yes. Totally agree with you
For most AEC work this would be a major issue and everyone is having to do work-arounds that increase the risk of errors and make workflows a hassle.
I hope McNeel will address this issue soon.
I think the Export with Origin command should be improved with an option to add a vector for orientation. Most times I import geometry or plans from an architect, I will move the geometry to an origin that makes sense for my work. Mostly if not always, this also includes orienting the geometry to a coordinate axis.
This is a major issue/fault in Rhino.
The problem has actually gotten worse with Rhino inside Revit which was suppose to offer easier integration between the two apps.
However, Rhino geometry can not be brought into Revit when the geometry is far from Rhino world coordinates 0,0,0.
This should be a top priority to fix for McNeel!
This post was recently revived after four years. Many far from origin display issues have been fixed in Rhino over the years so I need help with understanding the cases where you are still having problems.
How about the options to export with origin and orientation?
Let’s say my model is oriented close to the origin and I want to export to another coordinate system, in my case Swiss Coordinates in LV95 format.
LV95 origin in meters: 2600000 / 1200000
This is my geo-location on sea-level:
Coordinates in WGS84 format:
And that’s my model with my custom orientation
Maybe the location settings could be improved so they can accept more precise coordinates
Maybe a command like export with location?
I can send you a file with geometry in absolute coordinates (real-life coordinates).
There are several problems with this. In rhino, the problem is that lines and geometry start to flicker and become inaccurate and difficult to work with.
And when you export to Revit using Rhino inside Revit the geometry can not come into Revit at the absolute coordinates. There could of course also be Revit limitations…
revit cant work far from origin
At my firm we are trying to push towards one cohesive workflow with designers and engineers collaborating in Rhino.inside Revit. Super concerning that both of these programs cant handle large distances.
I am currently working on a bridge that is 13 miles long, even if we set the origin to be in the middle we run into render mesh issues. Converting CAD is a nightmare as well with how rhino handles zooming over large distances.
@stevebaer @wim Is this an issue that is being worked on? It would make rhino a much better program for bridge design.
