Stop rebuilding the wheel: How to scale your CAD-to-3D pipeline

Many engineering teams hit the same wall. CAD files pile up. Reviews slow down. The people who need to see a model can’t open it, and the people who can open it don’t have time to convert it for everyone else.

This guide is for anyone who owns that problem: 3D engineers, designers, developers, and the IT staff who support them. It breaks down what a scalable CAD-to-real-time-3D pipeline requires, why ad-hoc scripts and one-off conversions stop working at scale, with examples of companies that have solved the problem in production.

This is a working framework you can use to evaluate your own pipeline, whatever tools you end up choosing.

Who this guide is for

3D engineer, designer, or developer: this is a technical breakdown of what a pipeline needs to do.

IT director or a director of data engineering: this covers the governance, cost, and scale questions that matter to you.

Both groups have a shared objective: getting complex 3D data out of silos and into the hands of the people who need it, reliably and repeatedly.

Chapter 1: The reality gap - why CAD data gets stuck in silos

Seeing is believing. When a team can actually see what it's building, in three dimensions and in real time, they make better decisions. It catches design flaws earlier. It brings products to market faster.

Most organizations don’t work this way. Designers and engineers build tomorrow’s products in specialized CAD tools. Everyone else on the team, from product marketers to plant managers, review flat drawings and static slides. Unity calls this disconnect the reality gap: the person who understands the model best is often the only person who can open it.

There are three specific bottlenecks that create the reality gap:

• Tooling. CAD, PLM, and real-time engines rarely speak the same language out of the box. Every handoff between them risks lost data or a manual rebuild.
• Time. Converting and optimizing a single complex assembly by hand can take days. Multiply that by hundreds of assemblies and dozens of product lines, and the backlog can be significant.
• Expertise. The people who know how to move data between these tools are often a handful of specialists. When they’re busy, or when they leave, the pipeline stalls with them.

None of these problems are new. What’s changed is the cost of ignoring them. Products are more complex. Review cycles are more distributed, often across time zones and disciplines. And the expectation, increasingly, is that a 3D model should update as fast as the source file it came from.

A pipeline built to close the reality gap doesn’t just convert a file once. It has to work for every iteration, at whatever volume the organization produces new assemblies, without requiring a specialist to monitor it. That’s the difference between a one-off conversion and a scalable pipeline, and it’s the subject of the rest of this guide.

Chapter 2: What scalable means for a 3D pipeline

It’s easy to call any CAD-to-3D workflow a pipeline. It’s harder to make one that scales. The difference comes down to five stages, each of which has to work without a person re-doing it by hand every time.

1. Ingest. The pipeline has to accept whatever format the design team actually uses, whether that’s a mechanical CAD tool, a BIM package, a point cloud scan, or a mesh exported from another engine.

2. Convert. CAD data, which are parametric, and real-time 3D data, which are polygonal, are not the same thing, and no amount of manual cleanup changes that at scale. (Chapter 3 covers why.) The pipeline has to do this translation automatically.

3. Optimize. A raw CAD import is usually too heavy to run in real time. The pipeline needs to optimize files (eg: simplify geometry, generate relevant levels of detail) without a person opening every file.

4. Centralize and govern. Once a model is converted, someone has to be able to find it, know which version is current, and control who can see or change it.

5. Distribute. The finished asset has to reach whatever application or device the end user is on, and it must update when the source file changes.

A workflow that handles one of these stages well but not the others isn’t a pipeline. It’s a bottleneck with fewer steps. The next chapter looks at what happens technically at each of these stages, and Chapter 5 turns this list into a checklist you can use to evaluate any pipeline, including your own.

Chapter 3: Anatomy of a CAD-to-real-time-3D pipeline

Start with a question: why can’t a 3D engine open a CAD file directly?

The answer is geometry. CAD tools describe shapes with exact parametric surfaces, sometimes called BRep or NURBS. That precision is exactly what a mechanical engineer needs to design a part to the micron. But 3D engines don’t render parametric surfaces. They render meshes: collections of flat triangles that approximate a shape closely enough to look right at speed. Turning one into the other is not optional. Optimizing complex data for use in a 3D engine is the first job any CAD-to-3D pipeline has to do.

That step has to preserve more than raw shape. A useful pipeline retains:

• Hierarchy, so an assembly of a thousand parts stays organized as a thousand parts.
• Materials and colors, so the model still looks like what it’s supposed to be.
• Metadata, so downstream teams can search, filter, and report on the model.

Format coverage matters here. Unity Asset Transformer supports more than 70 CAD, BIM, mesh, and point cloud formats, including AutoCAD, CATIA, STEP, IFC, Revit, and glTF files, because engineering teams rarely use just one tool. If a pipeline only handles the formats your CAD team happens to use today, it will fall behind if another team, another supplier, or another acquisition, brings in something different.

Once geometry is converted, it usually needs to be lighter before it’s ready for real-time use. Typical optimization techniques include:

• Decimation, which reduces the number of triangles.
• Retopology, which rebuilds a simplified mesh from a complex one.
• Level-of-detail (LOD) generation, so distant objects render at lower fidelity automatically.

Finally, the pipeline has to move the finished asset somewhere useful, whether that’s streamed into a web viewer, downloaded into a 3D engine project, or pushed to an XR headset. If the source CAD file changes, a truly scalable pipeline re-runs this whole sequence automatically and notifies the people using the model that a new version is ready.

Every stage in this chapter can be done manually, and for a single model, it often is. The problem is repetition at scale, which is exactly what Chapter 4 covers.

Chapter 4: Build vs. Buy - Why good enough pipelines break at scale

Most CAD-to-3D pipelines don’t start as pipelines. They start as a script. An engineer needed one model converted for one presentation, wrote a one-off export, and it worked. Six months later, that script is running every week, nobody remembers all its edge cases, and it breaks when a new CAD tool enters the mix.

This is the build-vs-buy question every technical decision-maker eventually faces, and it’s worth being honest about what build really costs at scale:

• Brittleness. Hand-rolled scripts are usually written against the CAD files the author had on hand. New geometry, new formats, or unusual hierarchy structures tend to break them in ways that are hard to debug after the fact.
• Key-person risk. The knowledge of how the pipeline works often lives in one or two people’s heads. When they’re not available, the pipeline stops.
• Hidden maintenance cost. Every new CAD version, every new file format, and every new downstream target (eg: web, XR headset, mobile) is another thing the script has to be updated to support. That’s engineering time that doesn’t show up as a line item until it’s overdue.
• No single source of truth. Without centralized asset management, different teams end up with different, slightly out-of-sync copies of the same model.

None of this means building your own is always wrong. For a narrow, stable use case, a script might be exactly the right amount of engineering. The risk shows up specifically when volume grows: more product lines, more formats, more teams needing access, more frequent design changes.

At that point, the real competitor to a purpose-built pipeline is the temptation to keep patching what already exists rather than stepping back and asking whether the underlying architecture can actually scale. The evaluation criteria in the next chapter are designed to help make that call objectively, whether you’re assessing a vendor, a homegrown system, or some mix of both.

Chapter 5: An evaluation checklist for technical decision makers

Whatever pipeline you’re evaluating, whether it’s built in-house or bought from a vendor, the same questions apply. Use this checklist to compare options on equal footing.

Format coverage

• How many CAD, BIM, mesh, and point cloud formats does it support natively?
• Does it preserve hierarchy, materials, metadata, and animation on import, or just raw geometry?

Automation depth

• Can it batch-process hundreds of files without a person opening each one?
• Does it expose an API or SDK so your team can script and extend it, rather than being limited to a fixed set of manual steps?
• Can it detect and re-run automatically when a source file changes?

Governance and access control

• Does it support role-based access control, so contributors, reviewers, and viewers each see and do only what they should?
• Can it enforce a single version of the truth across teams, rather than letting duplicate copies drift apart?

Deployment flexibility

• Can it run in a standard multi-tenant cloud, and separately, can it deploy to a virtual private cloud or on-premises environment for teams that need to keep data inside their own infrastructure?
• Does it integrate with the identity and access management systems your IT team already uses?

Integration with existing tools

• Does it work with the design tools your teams already use, not just CAD packages, but tools like Blender, Maya, or Photoshop for non-CAD content?
• Does it fit into your existing version-control workflow, or does it require abandoning it?

Total cost of ownership

• Is pricing per seat, per use, or a flat platform fee, and how does that scale as your team and asset library grow?
• What’s the real engineering cost of maintaining the pipeline once it’s live, not just the cost of standing it up?

No single tool will score perfectly on every line. The point of this checklist isn’t to find a perfect answer. It’s to make sure the gaps you’re accepting are gaps you chose, not gaps you discovered after the pipeline was already load-bearing for the business.

Chapter 6: Proof from the field

Frameworks are useful, but they’re easier to trust with evidence. Here’s how three organizations, in three different industries, approached the same underlying problem.

Autoliv

Autoliv, the world’s largest automotive safety supplier, needed to showcase complex safety products to customers in a more interactive way than static drawings allowed. Using Unity Asset Transformer to automate CAD data transfer and optimization, Autoliv cut that process from four days down to six hours per product. That’s not a one-time win - it’s a recurring difference on every new product Autoliv brings to market.

BMW Group

BMW Group faced a different version of the same problem at a much larger scale: version control issues, inconsistent file formats, and collaboration friction across a vast, global library of 3D assets. BMW built “3D Mine,” a 3D asset management platform powered by Unity Asset Manager, to standardize how design, engineering, and marketing teams across the company store, find, and collaborate on 3D content.

The details differ, but the shape of each story is the same: a scalable pipeline turned a technical bottleneck into routine, repeatable infrastructure, and each organization measured the difference in hours saved, teams unblocked, or stakeholders included.

Chapter 7: Governance and security at enterprise scale

A pipeline that moves fast but leaks intellectual property isn’t actually solving the problem, it’s just changing which risk you’re carrying. For technical buyers, governance usually matters as much as speed.

Three areas tend to matter most:

Role-based access control. Not everyone touching a 3D asset needs the same level of access. A practical system distinguishes between administrators who manage the whole project, contributors who upload and edit, consumers who use assets in downstream work, and viewers who only need to look. Getting this granularity right, at both the organization and project level, prevents the common failure mode where “easy sharing” becomes “no real access control at all.”

Deployment control. Some organizations are comfortable storing 3D assets in a secure, multi-tenant cloud. Others, particularly in regulated industries or with sensitive IP, need data to stay inside infrastructure they control. A pipeline built for enterprise use should offer both: secure cloud storage as the default, and a virtual private cloud or on-premises option, deployed on infrastructure like AWS or Azure, for teams that need it.

Identity integration. Access control is only as strong as the identity system behind it. Enterprise-grade pipelines should integrate with the identity and access management (IAM) systems your organization already runs, rather than maintaining a separate, parallel set of user accounts and permissions.

This is the groundwork that becomes non-negotiable the moment a pipeline is handling a company’s actual product designs at scale.

Chapter 8: A roadmap for your own pipeline

Unity’s own enterprise guidance describes one way to assemble this architecture: Asset Transformer to handle ingest and optimization, Asset Manager to centralize and govern the resulting assets, and Pipeline Automation to orchestrate the whole sequence at scale, all working together as what Unity refers to as its 3D data engine. That’s one reference architecture, not the only one. The checklist in Chapter 5 will tell you whether it, or any other option, actually fits what your organization needs.

Chapter 9: What to do next

A scalable CAD-to-real-time-3D pipeline isn’t built in a single afternoon, but the first step is small: run your current process against the checklist in Chapter 5 and see where the gaps are.

From there, a few practical next steps:

• Explore the technical documentation for Unity Asset Transformer and Unity Asset Manager to see how the stages in Chapter 3 map to a specific implementation.
• Start a free trial of Unity Industry to test the workflow against your own CAD files.
• Talk to a Unity representative if your organization needs to plan a rollout across multiple teams or a virtual private cloud deployment.

Whatever you choose, the goal stays the same: close the reality gap between the people who build your 3D data and everyone else who needs to see it.