Your CAD data is stuck in engineering - how to free it

Your company owns thousands of accurate 3D models. Almost nobody outside engineering can use one. The instinct is to fix the authoring tool: a friendlier seat, a lighter viewer, a tidier vault. None of those will work, because the tool is not what is broken. The handoff is. This guide explains why the obvious fixes fail, what actually replaces them, and how to tell whether your current process is good enough.

You already know the symptoms

You do not need convincing that this is a problem. You need to know what to do about it. So here are the symptoms in one pass, then we move on.

Marketing asks for a product render and waits three weeks. Training builds a module from a screenshot because nobody could export a usable model. The shop floor works from a printed PDF that was current two revisions ago. A sales engineer keeps a personal folder of hand-simplified CAD exports, because requesting a fresh one takes longer than reusing a stale one. Somebody rebuilds a part from scratch that already exists three directories away.

Every one of those is the same event. A file that lives inside engineering has to reach somebody who does not work in engineering, and the only mechanism available is a person doing manual work. That mechanism does not scale, and it produces copies that are correct exactly once.

The pattern holds across industries. It holds whether your source is CATIA, NX, SolidWorks, Revit, or a mix of all of them. And it persists in organizations that have already bought good tools, which is the first clue that buying a better tool is not the answer.

Why the three obvious fixes do not work

There are three reasonable things to try first. Each of them is a genuine product category with real customers and real value. Each of them fails at this specific job, and they fail for three different reasons. Separating those reasons is the fastest way to work out what you actually need.

More CAD seats

The logic is that if the problem is access to CAD, buy more access to CAD. This fails on the demand side, not the cost side. The marketer waiting on an asset does not want to author geometry. Neither does the trainer, the field technician, or the procurement analyst. CAD is difficult to learn because parametric modeling is a genuine discipline, not because the license is expensive. Handing a non-engineer a seat converts a three-week wait into a three-month training program, and the deliverable at the end is still a CAD file that the next team cannot use either.

A CAD viewer

A viewer is a real improvement and a real category. It solves visibility. Somebody outside engineering can open the model, spin it, measure it, and comment on it. That is worth having, and lightweight viewers have earned their place in design review and supplier communication.

Then it stops. Visibility is not usability. A viewer produces no downstream asset. You cannot take its output and drop it into an interactive training module, a web product configurator, an HMI, or a sales tool. The moment somebody needs to build something, they are back to asking engineering for an export. Notably, this is also the answer the CAD incumbents themselves tend to reach for, which is why the category has stalled where it has.

A PDM system or vault

This is the most credible of the three, and the one most often confused with the actual fix. Product data management is valuable and you probably should have it. Autodesk Vault, Teamcenter, and their peers do a specific job well: they establish which file is current, who changed it, and what it depends on.

That is a system of record. It answers "which version is true?" It does not answer "can a non-engineer use this?" A vault will hand the marketing team the correct, authoritative, 400-megabyte native assembly they still cannot open. Governance and usability are different problems, and solving the first does not touch the second.

The problem is the handoff, not the tool

Every tool in that chain does its job. What was never built is the thing between them.

A CAD file is not a deliverable. It is a source. It carries precision your downstream teams do not need, in a format they cannot read, at a weight they cannot ship. Turning it into something usable means a real transformation, and in most organizations that transformation is performed by a person, by hand, one request at a time.

That is where the cost sits, and it is measurable. Across a survey of more than 128,000 engineers and designers, 83% reported recreating parts that were already available, and 48% work in a multi-CAD environment. Those two figures explain each other. When data will not travel between formats, recreating it is often the rational local choice, even though it is the expensive global one.

The organization pays twice for every hand-made copy. Once for the labor, and again when the source changes and the copy silently becomes wrong. Manual handoffs do not just cost time. They manufacture drift.

What actually fixes it

The fix is to stop treating 3D as a file that somebody hands over and start treating it as data that moves through a repeatable process. That process has five stages, and none of them is exotic.

Ingest. Accept source models in whatever format they arrive, including native CAD and BIM, plus neutral exchange formats such as STEP, JT, and IFC. A pipeline that only accepts one format simply relocates the handoff problem.

Convert. Convert precise geometry into something light enough to run interactively. This means tessellation, mesh optimization, and level-of-detail generation. It is the stage most often done manually, and it is the stage most worth automating, because the rules are consistent and the work is repetitive.

Access. Store prepared assets with metadata, versioning, and permissions so people can find the right one and only the right one. Keep prepared assets tied to their source, so a change upstream propagates instead of orphaning every copy downstream. This is the difference between a pipeline and a one-time conversion project.

Render. Serve platform-optimized assets to wherever the work happens: real-time engine, web-based editor, etc.

Deploy. Deliver the final product to the end-user in the format(s) they require: web, desktop, mobile, and immersive devices, without rebuilding the asset for each destination.

Run those five stages as a system and the handoff stops being an event that requires a human. That is what it means to democratize CAD data. Not giving everyone a CAD seat, and not giving everyone a viewer, but making the underlying 3D available as an input to whatever they need to build.

The destination matters here. Most attempts at this problem end at a picture: a render, a viewer, an image in a digital asset library. Interactive real-time 3D is a different destination, because the output is something a person can use rather than only look at. A configurator, a training simulation, a design review anyone can join, an operator interface. That is why the preparation stage is non-negotiable. Interactivity has a performance budget that raw CAD geometry will always exceed.

This guide stays at the level of the argument. For the architecture underneath it, including governance, automation, and how this fits an enterprise data estate, see our guide to 3D data infrastructure. Automated preparation of this kind is what Unity Asset Transformer does, across more than 70 source formats.

What changes, team by team

Abstractions are easy to agree with and easy to ignore. Here is what changes concretely.

Engineering stops being a file conversion service desk. This is the largest and least discussed benefit. Engineers currently spend 19% of their time, roughly one day a week, on non-value-added data management, including finding information, working with the wrong data, recreating data, and translating formats. An independent study of 250 respondents at manufacturers with more than 1,000 employees, all of whom already ran PDM or PLM, put non-value-added engineering work at 23%. Two studies, different sponsors, same range. That is a fifth of your most expensive technical capacity.

Marketing and sales get current assets without a queue. Prepared assets sit in a 3D asset management system with permissions and version history, so a request becomes a search.

Training builds from the real model. Not an approximation drawn from a screenshot, and not a version that was accurate at the last product launch.

The shop floor sees the current revision. When the prepared asset stays connected to its source, a released engineering change reaches the floor instead of stopping at a printer.

Procurement and service get structured data, not a picture. Assembly structure, part identity, and metadata survive the trip, which is what makes downstream lookup possible at all.

Improved CAD collaboration is a side effect of this rather than the goal. Once the underlying data moves reliably, teams outside engineering can also start assembling their own experiences through no-code 3D creation, which is where the request queue actually disappears.

The same problem in AEC

Everything above applies to architecture, engineering, and construction. Only the vocabulary changes. The source is BIM rather than mechanical CAD. The formats are IFC, RVT, and NWD rather than CATPart and JT. The recipient is an owner-operator rather than a product marketing team. The handoff moment is project handover rather than product launch.

The structural failure is identical, and owner-side research shows how deep it runs. Only 18% of AEC owners typically receive digital documents and model data files that meet their data requirements, and only 38% have well-defined digital delivery requirements. That is not a tooling preference. The same survey found owner adoption of CAD at 85% and BIM at 62%, so this is not an adoption gap either. The models exist. They arrive in a state the recipient cannot use.

The cost follows. In construction, teams work on non-optimal activities, and rework is directly caused by inaccurate, inaccessible, or incompatible project data.

Two industries, different acronyms, one broken handoff.

What it costs to leave it alone

The real competitor to fixing this is not another vendor. It is doing nothing, because the cost is distributed and nobody owns the line item.

The US government sized this problem before most current CAD systems existed. Imperfect interoperability costs the US automotive supply chain at least $1 billion a year, and the majority of that is attributable to the time and resources spent correcting and recreating data files that are not usable by those receiving them. The capital facilities equivalent is $15.8 billion a year, two thirds of it borne by owners and operators, driven by manual reentry of data, duplication of business functions, and continued reliance on paper-based information management.

Those studies are old. Treat them as conservative rather than outdated. The format count, the number of downstream destinations, and the number of teams who need 3D have all grown since. The mechanism they identified has not changed at all.

At your scale the number looks smaller and hurts more. An engineer-day per asset request. A three-week wait that pushes a launch. A training program certifying operators on a superseded revision. A supplier quoting from geometry that moved last month.

The compounding cost is not the conversion labor. It is the drift. Every manual copy is a fork, and forks do not get maintained. Six months of them leaves you unable to answer a simple question: which of the eleven versions of this product in circulation is right?

It helps to look at the opposite case. Wren Kitchens connects CAD-driven business logic to a real-time 3D and VR view, so a customer can walk through a kitchen that does not exist yet. The retailer also rebuilt how it produces photoreal product imagery, which it calls Wrenders. It replaced a V-Ray, Blender, and EC2 cloud rendering stack with a path tracer running inside that same pipeline. Average render times fell from roughly 10 minutes to roughly 30 seconds. Build times fell from three hours to three minutes. Cloud rendering costs fell.

How to tell whether you need this

Answer these in a minute. They are more diagnostic than any vendor assessment.

• How many people outside engineering requested a 3D asset last quarter?
• How long did the average request take, from ask to usable file?
• How many hand-made copies of your flagship product exist right now, and can you list where they are?
• If a released revision never reached the training team, who would notice, and when?
• Can you name every system your current 3D assets live in?
• Does anyone in engineering have "export models for other teams" as an unofficial part of their job?
• When a downstream team needs a format you do not support, what happens?

If your answers are low numbers and short waits, your current process is fine. Some organizations genuinely do not need a pipeline. If you produce a handful of products, ship a handful of assets a year, and one person can hold the whole picture in their head, adding infrastructure will cost more than it returns. Revisit it when the request volume grows or the product line does.

If you could not answer questions 3 or 5, that is the finding. You have an unmanaged parallel copy of your product data and no owner for it. For more on scoping this internally, see our answers to common industrial 3D visualization questions.