Wish: far from origin

Rhino Rhino for Windows
21

I think Rhino initially was designed for product and boat design.
So the problem of size and location was never an issue.

Now that Rhino is one of the most used software within architecture and construction it really doesn’t make sense not to fix the problem.
Everyone has been doing workarounds for years, but workflow wise it is a real ordeal.

I really hope McNeel will address this in a coming service release.

1 Like
22

Can we get some example files from anyone here? Please zip up the combination and then upload it to our transfer site: https://www.rhino3d.com/upload . Email can be tech@mcneel.com.

Only the objects that are involved need to be sent.

We will take a look.

23

i think this is fairly obvious issue and lot has been said about it. my suggestion is that rhino should calculate everything in respect to cplane origin (or set model origin) and only store global coordinates as addition of local coordinates plus global zero and model origin zero. so all the geometry bilions units from origin will be basically close to set model origin but for display purposes global coordinates will be just simple addition of local coordinates and mode origin from global origin difference

1 Like
24

Yes, but we believe we have the display issues taken care of. All things described in this thread before May 2017. So now we can only guess it the significant digit accuracy on small detail close to tolerance, especially on fabrication details. But, that is only a guess.

There are other issues that impact this. For instance the bump in this thread from 9 days ago is the problem that the projects are being set out at state plane coordinates because of an imported survey drawing that the project started from? Of course in 2d with Civil work, tolerances can be much larger. If that is the problem, then setting basepoints (Project points) to bring the important part of the project into the most accurate part of the model.

Once the geometry gets into 3d and accurate NURBS intersections have to be calculated, state plane does not work well.

So like Revit, do we use a Project base point?

25

@scottd I have an impression, and only an impression, that there are few single precision calculations of geometry and/or use of single precision variables used in geometry calculations buried somewhere in the Rhino code associated with a small number of commands and operations. My programmng experience is limited to Fortran over thirty years ago but I remember how difficult it can be to identify and find potential problems where the code usually give corrent results and even the incorrect results seem to be okay.

1 Like
26

Single precision were used in meshes early on. And graphics cards use single precision natively.

But in Rhino, it has more to do with using doubles. Double has 15 decimal digits of precision. Some operations like square root cannit return completely accurate results within 15 digits, so you end up with rounding. Which makes the 15 digits less reliable, say half of them.

So we use tolerance to handle that. And this is where the trouble begins. Set tolerance down to 0.001 inches for NURBS calculations needed for small objects. That leaves only a few significant digits to the left. So if state plane coordinates take up those digits to the left, tolerance limits will fail.

The problem is not doing the civil site calculations at large numbers. Or doing high highly accurate, smaller tolerance calculations in smaller models. It is just doing both in the same model that gets to the edge of possible.

27

Use a basepoint, I’ve posted my ‘workaround’ couple of times on this forum (store namedcplane, use remap to change position when importing and exporting → make a macro) and that’s pretty much the same functionality other softwares use and it works fine.

You could add a UI to create and store basepoints (and set active one) and maybe prompt should the basepoint be used when import/export is done.

1 Like
28

There is a modelbasepoint property: ModelBasepoint | Rhino 3-D modeling

How could that be used in this case?

29

Close but no cigar. What needs to happen when your CAD material is in world coordinates:

  • you set a basepoint for your project in the world coordinates (xxxxxx,yyyyyy,0) next to your project area to simulate the location of 0,0,0 point in your model.
  • when importing material in world coordinates to your rhino model, rhino needs to make a move of (-xxxxxx,-yyyyyy,-0) on the imported material. Also prompt to use basepoint offset or not.
  • exporting would move this material (xxxxxx,yyyyyy,0) before exporting. Also needs to prompt to use basepoint offset or not

It also needs to:

  • support rotational transformations instead of moving according to basepoint —> baseCPlane
  • have a UI to manage multiple baseCPlanes (like NamedCPlane toolbar)(you need this if you combine material from different sources)
  • be applied to all files imported (not just other Rhino files)
1 Like
30

this workaround is workaround. implementing “model origin” as native thing is what we want. and maybe some toggle to display coordinates in reference world or model origin. thats simplest solution and quite robust

31

Agreed, that the Basepoint would need to be consistent thru out the interface. But this type of development of basepoint would start to solve some of these issues. And it would need to work with Rhino.Inside.Revit also?

Actually, moving the geometry before saving can get troublesome. But respecting the basepoint more often can be done.

Now are there specific workflows and example files we can come up with to show how basepoint does not work right at this time? We could use those to continue to implement a project Basepoint. For instance, part of the 9-day bump was working with Revit?

1 Like
32

i have big issues with vray. rhino shows geometry ok far from origin but in render it is totally destroyed definately due to single precision mesh

33

Yep, single precision stuff in renders can be a real issue out at these coordinates. The newer GPUS work single precision super fast, but drag at double precision. So the problem does get more complicated when it comes to rendering.

Although this basepoint implementation might help with some of this problem.

34

Hi Morten -

I see issues with display meshes 2 billion units from the origin (tolerance 0.001) and wrote it up as RH-63872.
You mention lines starting to flicker and becoming inaccurate. At what distance from the origin are you working then? And what is the tolerance set to?
-wim

1 Like
35

@wim I see that you are 2 billion units out. I have run into display issues similar to these as close as 50k units from the origin, usually involving the display meshes of complex nurbs surfaces.

36

definately because renderers would take into account coordinates in reference to model origin not world origin

37

Hi Greg -

Have you supplied a sample that we can look at?
-wim

38

Using larger tolerances can easily allow for billions of units. It is really just matching tolerance to allow the right range of values in the model.

Of course where the trouble starts is a model that needs to be fabricated can be limited on how large tolerance can be based on fabrication requirements.

39

Changing units is also another way to adjust this balance between tolerance and the largest values in the model. Using larger unit types effectively makes the tolerance larger too and the final values will also use less digits.

40

Hi @scottd , can you elaborate on this a bit?
For example:
Using meter instead of milimeter Units, would enable having 3D models much more distant from the world origin. And it would not be a problem that tolerances are ‘0.000001’ (for meters) instead of ‘0.001’ (for milimeters)?

1 Like