Shade Display Problem - persistent misalignment between shade surface and wire surface outline (far from origin)

In shaded viewport I am getting a persistent misalignment between shade surface representation and wire outlines of those same surfaces. Also surfaces are showing through each other. I have tried “testZbiasfactor” with no success. I have NVIDIA Quadro K2000M, 64 bit, 16GB RAM, i7 processor, on Dell Precision M4700. I have not had the problem before. Please see image. Any help would be great. Thanks.

Are the objects very far from the world origin?

Yes - you hit it on the nail - I just figured out that I was way far from
the origin which was causing the problem. Thanks very much for responding.

Matthew Winkelstein AIA, LEED AP
Design Director - West Coast Studio

William McDonough + Partners
177 Post Street, Suite 920
San Francisco, CA 94108

C: +1(415) 690-5315

Is there any way to get the shaded view to display correctly and work with large coordinates? I work with laser scan data that is often surveyed in state plane coordinate systems that are far away from 0,0,0 and run into this problem frequently. I’ve also noticed that once you draw an object in a large coordinate system if you move the objects back to 0,0,0 they remain broken. Is there anyway to fix the affected objects once you move them closer to the world origin?

Try the command RefreshShade, which will force the display meshes to be re-created on the selected objects. If you want to do this for a whole file, you can also use ClearAllMeshes, then select a shaded mode and all the display meshes of visible objects in the file will be recreated.

HTH, --Mitch

If it’s purely a display issue, you could try to switch to the RH6 WIP.
Also, what do you have your units set to and what is the smallest meaningful distance you typically use in your files?

If the model is very far from the world origin, the way the display is drawn both in terms of wireframe and render meshes gets effected. I don’t know of any way to prevent this and the reason when explained is highly technical. There are a couple forum threads where this is discussed…


@dalelear comments on the second thread being the most important as he would be the one to change they way this works if possible.

To regenerate render meshes after moving a model closer to 0, use the techniques Mitch talks about above.

@BrianJ After reading the replies I believe this to be a display issue as wireframe displays just fine and I don’t appear to have any issues with object snapping. Please let me know if I misinterpreted something and it is more than a mesh display issue.

@wim I can try the WIP but will likely have to remain in RH5 due the the point cloud plugin I use. Is my understanding correct the RH5 displays meshes in single precision where RH6 will display them in double? My units are set to Meters and never get to the millions place (typically 500000 by 250000) with the smallest meaningful distance being one tenth of a millimeter. (500000.0001) If my understanding is correct this should be well within the capability of RH5, unless I’m missing something. Are there any guidelines letting you know what accuracy you can achieve at a specific distance away from the world origin?

@Helvetosaur Thanks, This solves the display after moving the model to a lower coordinate system.

I don’t see any specific files or screenshots from you in this thread so I’m guessing the problem you see often is just the one reported and shown at the top of this thread. If that’s the case, I think it’s a render mesh display precision issue. The other conversations I referenced touch on some other associated problems that can be caused by models very far from the world origin as well as the render mesh one. If you have a file that you can send in to , I can file it as a confidential bug report too.

In the binary32 format (“single precision”), any integer with 6 or fewer significant decimal digits can be stored without loss of precision. Additionally, some integers with 9 significant decimal digits can be stored without loss of precision. You are looking at 10 significant decimal digits.

And yes, your understanding that RH6 uses the binary64 format to store mesh vertices is correct.