The pain with models far away from the origin

Hi everyone,

Rhino looses precision when the model is modeled far away from the global origin. (Due to calculation tolerances, I believe)

In architectural projects, it often happens that the origin of a building model is far away from global (0,0,0). When exchanging models with other project parties it is essential to have the same reference origin and unit system. So we are not “free” to define the origin of our model.

Currently we are using the approach to transform all necessary model objects and reassign them to a different location in our model to work on them. Later we transform everything back to the original position to exchange data.
In theory this works fine, but in real life, it is really a pain.

  • As soon as additional external objects need to be updated or added to the model, everything needs to be be transformed after import.

  • Large Models take a lot of time to be transformed.

  • When exporting data 2 times out of 10 I forget to orient before export …resulting in annoyed porject partners.

  • I tend to forget to transform objects that are hidden or on turned off layers.

Generally this seems just like an unnessesary step. My life would be much easier if Rhino could just work with large coordinate systems.

So here is my WISH:

  • Could Rhino somehow handle this internally??? (Maybe using an internal transformation matrix)
  • Alternatively, could you integrate an internal transformation to be saved for the Rhino Document.
  • Could you add a command to transform “EVERYTHING” (Objects, Locked Objects, Hidden Objects, etc.)

Let me know what you think?


1 Like

Did you read this one?

Hi Martin,

I really think a strategy involving named construction planes is best for this. I’ve used it in the past, and this is akin to how applications such as Revit handle this (referred to as shared coordinates).

I would really recommend keeping the model close to rhino origin, I’ve seen Grasshopper performance suffer (and also Rhino) when objects are remote.

The practical logistics of this might be more challenging. Certainly I could enable this in my IFC importer/exporter, but if you’re using CAD file formats this would require scripting or options to be enabled by RMA or others.

Interested to discuss further,


Hi Martin,

The short story is that a double precision number has around 16 significant digits and if the “important detail size” is dwarfed by a relatively huge translation, then some calculations suffer and a “global translation” may not help much. The fact that you appear to be successful when applying a transformation, doing your modeling, and then “transforming back” leads me to speculate that the scales and coordinates you’re working with have an adequate amount of information in the model definition to perform geometric calculations and something in display or user interface is giving you grief.

In order to help you beyond the vague babble above, I need to understand more details about what problems you’re having when you say Rhino looses precision for objects that are far from the origin.

QUESTION 1: What are typical bounding boxes of the entire model ans what is the smallest meaningful distance in your model? Are you modeling small, tight tolerance, mechanical equipment in a building, or walls doors and windows? I also need to understand if the model is huge and surrounds the origin or the the diameter of the model is something like 10,000 units or less, but is located far from the origin, like 100,000,000 units away from (0,0,0).

QUESTION 2: Can you provide more details about what types of problems are you having?

  • Shaded display looks ragged?
  • Curves and surfaces in shaded display don’t match up as expected?
  • Snapping is unpredictable or point locations are not accurate to 14 significant digits?
  • Operations like intersections don’t work as well as they do if the model is “translated to the origin”.
  • Evaluation operations (points, mass properties, …) are producing results that are significantly less accurate when “far from origin”.
  • Other?

QUESTION 3: If the answers to question 2 include issues with geometric calculations (as opposed to display, snapping, …, issues), are the results you’re getting both not accurate and not precise? For example, if evaluation operations are giving you trouble, are the results “biased in some direction” but tightly clustered, smeared all over the place or …?

– Dale Lear

Well, I’m working ALWAYS in mm, with a quite tight tolerance (Usually 0,001 mm)
since we are building CNC parts, that are placed inside a building. If we work in Meters, the tolerances are higher - resulting a high tolerance in mm as well.

Usually a building site is located far away from the origin,but the main information is locally bound. They are build on the location of the cadastral plan - which usually has it’s origin far (several km) away (in the city center). The building lot is usually smaller.
Sometimes the Origin is marked with a point or a circle. (Which is always a lot of fun, if you click the “ZoomAll” button)

However, large construction sites can have around 500m in diameter (buildings are usually not as high though). Which in mm is around 500.000 Units. 100.000 Units is nothing unusual

Usually I have trouble snapping objects. - which is really a pain. Once this Problem occurs, I transform the geometry. (It’s impossible to work with it) So I can’Ts really give you feedback on results of evaluations.

I noticed that “SelDup” doesn’t work correctly. I had a point cloud (not a point cloud object, but a lot of points), which I wanted to transfer into a mesh. It found duplicates where there weren’t any.
Also the mesh output was not correct.


Thanks for the clarifications. This is a common issue.

My speculation is the snapping issues you are seeing result because there is a large translation component in the view projection matrices. If you can share a model were the issue is particularly troubling, it should be easy to debug our code and see where the snapping calculation starts to fail. The good news is sloppy snapping bugs are often caused by sloppy coding practices when dealing with view transformations and we can probably fix it.

If your example model is huge or proprietary, perhaps you can send a few of the objects where snapping does not work and replace the the other objects with boxes created with the Rhino BoundingBox command? You can email it to and be assured it will be used only for development and testing purposes. Any bug reports containing your file will not be able to be viewed by the public.

Given the model size, tolerance and offsets you mentioned,

Machine diameter ~ 10^4 (10000 mm = 10 meters my guess)
Building diameter < 10^6 (1,000,000 mm) (< 1000 meters)
Tolerance = 10-3 (0.001 mm)
Offset from origin ~ 10^7 mm (~10km)

The solution you initially posed is a reasonable thing for us to consider. I understand the pain you experience with having to set up, apply and remember to use a “repositioning transformation” every time you import/export geometry from your model.

We’ve dealt with similar issues for decades. The US “state plane coordinates” divide the US into 124 coordinate systems and sometimes it is necessary to model or reference building sized or smaller objects in these coordinate systems.

For some limited mapping applications we added an “EarthAnchorPoint” to address issues like you described in your initial post, but that never got very far and it does not help solve your problem.

My guess is that something along the lines of being able to mark a model as having coordinates translated relative to some other coordinate system and providing some reasonably obvious user interface so when you import/export would be a minimum starting point.

The hard part is deciding when such a transformation should be applied and what you want to see in the user interface for point locations (we already have CPlane, World). My guess is the coordinate systems would need a name to appear in the UI.

For example, suppose we have files with relative position information that looks like:

Model coordinate system name = "Building 46"
Reference coordinate system name="Cadestral 123"
ModelToReferenceCoordinatesTransformation=appropriate matrix.

Model coordinate system name = "Fancy Machine 92"
Reference coordinate system name="Cadestral 123"
ModelToReferenceCoordinatesTransformation=appropriate matrix.

Model coordinate system name = "Building 13"
Reference coordinate system name="Cadestral 987"
ModelToReferenceCoordinatesTransformation=appropriate matrix.

Then appropriate transformations could automatically be applied when moving information between Building46.3dm and FancyMachine92.3dm.

However, if you attempted to import FancyMachine92.3dm into Building13.3dm, you would need to be asked what you want to do.

Once we get here, I can just imagine it won’t be long before there are requests to have multiple transformations per file a la:

Model coordinate system name = "Fancy Machine 92"
Reference coordinate system name="Cadestral 123"
Model To Reference Coordinates Transformation=appropriate matrix.

Model coordinate system name = "Fancy Machine 92"
Reference coordinate system name="Cadestral 987"
Model To Reference Coordinate Transformation=appropriate matrix.

And a few minutes later, requests reference some master coordinate system information (file/ database/magic “cloud” GIS query/…) with information like:

reference system name="ApplePie"
coordinate system A name="Cadestral 123"
coordinate system B name="Cadestral 987"
coordinate system C name=“Cadestral 456”

coordinate system Z name="Cadestral XYZ"
Ref to A Coordinate Transformation=appropriate matrix.
Ref to B Coordinate Transformation=appropriate matrix.
Ref to C Coordinate Transformation=appropriate matrix.

Ref to Z Coordinate Transformation=appropriate matrix.

If we do something like you suggested, we need to carefully think through the workflows and processes people use to create and manage this kind of information so we can get it right.

There is also a component to make sure worksession reference files, linked instance definitions, procedural materials with location based reflections, …, are properly handled.

Another issue to consider is that if people see this feature, they would want to use it to manage information in different state plane or cadestral coordinate systems where the curvature of the Earth’s surface starts to matter. (Large transportation system projects for example.) We would either have to do it right or make it clear to the users that what we provide is not appropriate if the Earth’s curvature needs to be taken into account.


As someone for whom this is never a problem, this sounds to me like a great start to a great solution. As someone who has always thought of Rhino as a well thought-out system (despite a few features to the contrary), I think the overall “do it right” approach should be used. The whole thing sounds like enough thought will be required that the increment to account for curvature wouldn’t be large percentage-wise. Then you wouldn’t need to revisit it a year later. I mean, you do have AU’s in your available units, after all. :wink:


14 posts were split to a new topic: Far from origin