Why Revit Kept Losing Precision Until We Fixed This One Setting

Revit models kept getting flaky on us. Not crashing exactly, just small things drifting — walls that wouldn't snap cleanly, dimensions that looked slightly off in ways nobody could quite explain. It took embarrassingly long to figure out the actual cause: Revit is built to handle geometry within roughly a 20-mile radius of its internal origin, and our Civil 3D files, mapped to Singapore's SVY21 geodetic coordinate system, were placing everything millions of millimeters away from that baseline. We spent almost two weeks blaming our graphics cards before someone finally traced it back to the coordinate setup.

This isn't the same coordinate mistake I've written about before, where a whole tunnel section ended up two kilometers off course from a bad import. This one's subtler and honestly more annoying, because the model doesn't fail loudly. It just gets slowly, quietly unstable the further your actual site sits from Revit's comfortable working radius, and by the time you notice, it's already baked into weeks of work.

Why Revit Starts Acting Strange Far From Origin

Once you understand what's actually happening, the instability makes sense. Revit was never really designed with true geodetic coordinates in mind. It expects geometry clustered near its internal zero point, and when your real-world SVY21 coordinates place your project far outside that comfortable radius, floating-point rounding errors start creeping into everything — snapping gets imprecise, dimension checks get flaky, elements that should align perfectly develop tiny, maddening discrepancies.

The fix isn't complicated once you know what you're looking for, but it does require discipline nobody wants to enforce mid-deadline. You need a rock-solid shared coordinate system anchored to a dedicated survey point, established early, not patched in after the fact once someone notices the model's behaving oddly. We ended up rebuilding our coordinate reference from scratch on that project, which was tedious but at least fixed the root problem instead of just papering over the symptoms one glitch at a time.

The Data Conversion Trap Nobody Warns You About

Getting coordinates right solves one problem. Getting the actual data conversion right solves another one that's just as easy to get wrong.

Converting Civil 3D alignments and digital terrain models into clean Revit topography frequently balloons file sizes if you're not careful about the conversion path. We made the mistake early on of linking raw DWG layers directly instead of going through a proper LandXML conversion, and it destroyed our cloud sync speeds almost immediately — every save turned into a multi-minute wait while everyone on the team sat there staring at a progress bar, coffee going cold. Switching to clean LandXML exports fixed that specific bottleneck within a day of implementing it properly, and it's genuinely one of those fixes that feels almost too simple in hindsight given how much time the wrong approach cost us.

How We Actually Fixed the Workflow

Two changes made the biggest difference once we actually diagnosed what was going wrong.

First, we stopped manually sharing files between the civil and structural teams entirely. Publishing Civil 3D surfaces directly as a cloud-linked topology layer inside Revit, through Autodesk Construction Cloud, kept a live connection to the source data instead of relying on someone remembering to export and re-import an updated file every time something changed. That alone saved hours of chasing outdated links across the team every week, and it removed the recurring argument about whose file was actually the current one.

Second, we built a proper internal QA checklist before anything went into the shared common data environment, cross-checking against the same LTA-aligned standards I've written about managing more broadly. It's a small extra step, but it catches coordinate drift before it becomes someone else's problem three weeks down the line, usually right before a submission deadline when nobody has the spare time to untangle it properly.

What I'd Tell Anyone Starting This Kind of Project

None of this is intuitive the first time you run into it, and I don't think that's a personal failing so much as a gap in how these tools were originally designed. Revit and Civil 3D were built by different teams, for different scales of geometry, and Singapore's SVY21 system sits right at the seam between the two in a way that exposes every weak spot in how they're supposed to talk to each other. Most tutorials assume you're working somewhere close to a project's local origin by default, and nobody really writes the version of the guide for someone whose entire site sits a continent away from wherever these tools were designed with in mind.

If you're setting up a similar workflow, don't wait until the model starts behaving strangely to establish your shared coordinates properly. Build the survey point reference first, verify it against the actual site markers, and only then start letting the structural team build on top of it. It's a lot less painful than untangling instability after months of work are already sitting inside a model that's quietly drifting further from where it should be.

Looking back, the two weeks we lost chasing a graphics card problem that didn't exist still bothers me a little. Not because the eventual fix was hard — it wasn't, really — but because the actual cause was sitting in plain sight the whole time, buried under an assumption nobody thought to question until things got bad enough to force the issue.

Related reading:
The Coordinate Mistake That Sent Our Tunnel Two Kilometers Off Course
The Three Things That Decide Whether Your BIM Model Passes Review in Singapore