How to force geometry Z values to exactly 0 without moving objects?

Rhino Rhino for Windows
1

Hello,

I’m looking for a precise way to set object Z values to exactly 0.0 in Rhino, without relying on moving or translating the objects.

What I want to achieve:

  • Do NOT move objects along Z using translation

  • Do NOT rely on bounding box or -z_min logic

  • Instead, directly set all geometry points’ Z coordinate to 0.0

  • Keep X and Y coordinates unchanged

  • Ensure the result is mathematically exact (no floating values like 1e-15)

What I have tried:

  • Moving objects by -z_min → results in very small residual values

  • Using bounding box calculations → still not exact

  • Using control points (grips) → seems closer, but I want to confirm best practice

My concern:

Even extremely small deviations from zero cause issues in my workflow, so I need a method that guarantees true zero at geometry level, not just visually or approximately.

2

SetPt

ProjectToCPlane should also work

3

Is there a script to set objects to Z=0 using SetPt?

I want to move the selected objects to Z=0 without changing their X and Y coordinates, without flattening them, and without altering their orientation. I want them to remain exactly as they are, just positioned at Z=0 (Translate ChatGPT)

4

In that case all you can do is move the objects from their bounding box lower value to W0. I don’t know why you are getting any kind of significant inaccuracy from this procedure.

5

In CNC CAM programming, even very small differences in Z are interpreted as a WorkPlane. Drawings coming from AutoCAD do not cause any issues, but drawings from Rhino tend to be converted into spline-type curves. The reason is that they are not perfectly on the ground plane in the Z axis.

6

Such values don’t actually exist, they are just artifacts of floating-point math on a digital computer, you are chasing ghosts. Note all other software does this too, they just hard-code hiding it from you. What is the actual problem you are trying to solve?

7

Well, there is actually a small problem. For example, in the file below, there is a sphere with a vertical axis at an arbitrary point in space.

ArbitrarySphere.3dm (4.8 MB)

Running the following script -

import rhinoscriptsyntax as rs
import Rhino

obj_id=rs.GetObject()
if obj_id:
    obj=rs.coercegeometry(obj_id)

    obj_bb=obj.GetBoundingBox(True) #True argument for 'accurate' bounding box
    #print the Z value of the bottom of the bounding box to max precision
    print(format(obj_bb.Min.Z,'.16g'))

It prints following value for the bottom of the bounding box:
71.0025405883789

If I set the max display precision possible in Rhino and run Analyze>Point on the lower pole of the sphere I get this value:
71.00254213

There is a difference of
0.0000015416211

Certainly microscopic… but:

I usually ‘drop’ my objects to the 0 plane using some variation of the following script:

AlignBottomToWorldZero-New.py (2.7 KB)

If I select the sphere in this case and run the script, then again with the display precision maxed, I get a value for the lower pole of the sphere that is not 0 but rather that number rounded to 8 digits past the decimal:

0.00000154

The same thing happens if I just run Align>Bottom and type 0 from the Front or Right views.

Paradoxically, if I run the actual Rhino BoundingBox command after the move with Align or the script, I get the bottom of the box at 0.00000000

I can’t explain the discrepancy, but it must have to do with the accuracy of how the bounding box is calculated.

8

It sounds like you are having problems with curves that you expect to be exactly on the Z=0 plane somehow end up not where they should be.

SetPt to Z=0 will fix this for curves., but a better approach is to figure out what is causing the problem in the first place. Rhino is a minefield and to be successful at not having problems like you have one needs to learn to avoid the things that can cause inaccuracies and errors.

The best way to arrive at a useful solution to the problem is to post some examples of curves made in Rhino that are causing the failures you are experiencing. Posting examples with an explanation of how the curves were created will probably lead to someone being able to provide help.

9

Inaccuracy of Align and BoundingBox have been discussed previously. The algorithms are based on the single precision meshes. Apparently the cause of errors is some combination of mesh refinement settings and the use of single precision meshes. These errors can be on the order of 1.e-08 or larger and can be significant.

Two relevant YT’s

Additionally discrepancies in the 14th to 16th decimal digit can result from the limitations of double precision floating point arithmetic. It is very unlikely that errors of this magnitude will have any real world significance for applications using Rhino. These discrepancies can cause problems when code uses an exact test for “zero” and similar.

10

Yes, I remember having discussed this stuff in the past… I thought it might have been improved.