Rhino can't handle world coordinates sometimes

This is a major problem that I run into from time to time. When importing something that has large coordinates, rhino really can’t handle it at all. look at this mess:

That is a road model, and is supposed to look like this:

For some reason that I don’t understand, it does’nt happen all the time. But even in times when things look 100% right, you can see that there is a problem by deriving an outline from a mesh, and see that they dont match up at all. For a cad program, this is a major issue in my opinion, and I don’t think it’s been fixed in the 7 wips I’ve tried…

Hei Gudmund,
Could you post an example of a file that you are importing? It’s hard to tell from those images what is going on and we can only fix things if we can reproduce them.

If your file is confidential, you can upload it here - https://www.rhino3d.com/upload.
Make sure to put the link to this thread in the comments field if you upload it from that page.

It is confidential. uploaded the dwg that was imported to make sure you can start from scratch, in case I imported it using the wrong settings

This is a common problem of too big numbers. There are only so many digits one can use in a float, computer number. In civil engineering this can easily become a problem when the coordinates can be in the millions. Someone better versed can correct me and explain it more accurately.

One workaround is to use a local coordinate system. Which means picking consistent point near te stuff you work with, and then systematically moving that geometry near 0,0,0 and then back again, when you need to export it. Otherwise there will be problems sooner or later.

The problem is not in anyway unique to rhino, for example here’s a blog post describing the same thing with autocad from 2006

Although I am open to hearing if there is a better(=easier) solution in the pipeline

edit: disclaimer, the above problem can be something else too, but I am almost willing ot bet that moving all the stuff nearer to 0,0,0 will make all magically better =)

Hello - please try EvaluatePt and snap to a vertex - most like the the numbers will be very large.


I’m used to this kind of problem in programs like 3ds max, sketchup etc. But I took it for granted that in cad software this was not an issue. I’ve never seen this happen in Microstation, and I’m certain that Autocad will display it fine (maybe it was a problem in 2006, but not now)
So I am surprised that this is an issue in Rhino. today we work with world coordinates for all disciplines, and we work in a program that syncs, so everyone knows they work on the same model…So if you need to change something, you export it, fix it, and reimport it. Working in a local coordinate system is simply not an option anymore for the way we work in my company. I can use microstation, but I really prefer Rhino, so this was bad news for me :frowning:

1 Like

You can tackle this issue either by the Wiki instructions or using CPlanes.

  1. Create a global origo point as CPlane (point near your geometries in absolute coordinates
  2. Save that CPlane in Named CPlanes
  3. Import CAD data
  4. Change CPlane to your global origi
  5. Use RemapCPlane and choose Top as target CPlane
  6. When exporting choose Top as active and remap to your global origo
  7. Create macros from these or scripts and create aliases from them to have a single command

This seems to be a limit of graphic cards, they use floating point numbers for coordinates so
With huge numbers points get collapsed onscreen.

This problem just gets weirder. I was showing someone the model, and this time it looks fine

My trick to see if the model has coordinates that are too high is to derive an outline from it. But that also looks fine. But if I take the lines and triangulate them, the world coordinates problem comes back.

I have no idea why it behaves like this, I am 100% sure I used the same settings and the file is the same

Hei Gudmund -
it looks like nobody picked up the file that you uploaded earlier. Sorry about that!
I looked at that now and it looks “fine” in Rhino 7 here. I say “fine” because it’s a rather messy file with lots of different meshes that are almost in the same place.

(this image is from the North-East end of the road).

Using Rhino triangulation tools (I’m not sure which one you used) on a polyline that was created from the edge of a complex mesh will not recreate the original mesh. Getting mesh faces that connect across like what is shown in that image is expected behavior.

I did’nt expect it to recreate the original mesh, but I did expect it to have it’s vertices line up with the ones used in the triangulation, and that does not happen. There is about 15 cm offset between the line used, and the mesh.

(I used the “mesh patch” function) But that is’nt the main problem, the big problem is that Rhino sometimes imports meshes like this like it did in the first image in this post, and now I can’t reproduce the error, so I have no idea when it kicks in, and what to do to prevent it. The mesh is supposed to have all the overlapping meshes, it’s the different layers of a road model.
And the mesh in my previous post have all the signs of large coordinates problems. If I export the mesh to 3ds or another format that can’t use world coordinates, that is exactly the kind of rounding error gridding I would expect to see

Hei igjen, Gudmund -

That’s possible but perhaps it could be a way to figure out what is happening.
But I can’t reproduce this one either.
The steps that I took in a current Rhino 7 beta:

  • Started a new file from the factory-default “Small Objects - Meters.3dm” template
  • Imported the dwg file with the following settings:
  • Selected a mesh on the Asphalt and T_Asphalt02 layer
  • Ran DupBorder to create a polyline
  • Ran MeshPatch to create a mesh from this line (AngleTolerance was set at 15)

This resulted in the following:

and that looks correct to me.

I’m not going to claim that there aren’t any remaining far-from-origin issues in Rhino 7 but as long as you are using double-precision meshes and stay more or less in the region that you are working in, I don’t think you should be running into problems here. So if you can help me reproduce something, we can possibly get to the bottom of this.

I tried it in Rhino 6 using the exact same settings, and got this:

But I downloaded the latest 7 wip, and got this:

So it seems like the issue is fixed in 7 :slight_smile:
I can’t check if the main issue is fixed, since I can’t reproduce it. But if it happens again I can save the 3dm file and share here

Takker for det, Gudmund.

did you import with double precision or single precision? There are tons of issues related to far from origin but you are right. This things dont happen in microstation for example so shouldnot happen in rhino either.

I usually have it set to automatic, but I can’t reproduce the error even if I force it to use single precision now. And forcing it to double will still give the error when triangulating in 6