TL;DR: The 3D models your team already has, the CAD assemblies, the BIM model, the marketing renders, are almost never the models that will run inside a headset or a phone. They describe an object precisely; an XR app has to draw it twice per eye, dozens of times a second, on a battery-powered chip. Getting from one to the other is a real workstream with its own cost, its own specialists and its own maintenance bill, and it is the line most XR proposals underestimate. Here's what actually happens to a 3D model on the way into an XR app, where content comes from, what makes it expensive, and how to scope the content side before you commission the build.
Several of the XR articles on this site say some version of the same thing: the hard part is never the 3D model. In location-based AR the hard part is positioning. In mixed-reality collaboration it is keeping every headset agreed on where the object is. In enterprise AR training it is registration that stays glued to real equipment.
This is the article about the exception. There is a class of XR project where the content genuinely is the project, and buyers walk into it holding a folder of CAD files and a reasonable assumption that the hard part is already done.
It usually starts with a sentence in a kickoff call: "we already have all the 3D models, so that part should be quick." Almost everything that follows in the budget conversation depends on how honestly that sentence gets handled.
Why "we already have the models" is not the answer it sounds like
A CAD file and an XR asset are two different things that happen to describe the same object.
CAD exists to define an object precisely enough to manufacture it. It stores exact mathematical surfaces, every internal fastener, every fillet, every part that will never be visible, and often the whole supply chain's worth of sub-assemblies. Its job is accuracy, and it is very good at it.
An XR asset exists to be drawn. It is a mesh of triangles with textures wrapped onto it, built so a graphics processor can push it through the pipeline fast enough that the image never stutters. Its job is to look right at speed. Nobody optimized your CAD model for that, because that was not what it was for.
The same gap shows up with every other source. A marketing render is built for one camera angle with lighting baked into the image. A BIM model is built for coordination and documentation, so it carries every duct and pipe in a building whether or not a user will ever see them. A photogrammetry scan is built from photographs and arrives as an enormous, messy, single lump of geometry with the lighting of the day it was captured burned into it.
All of them are useful starting points. None of them is a deliverable.
The frame budget is the constraint everything else bends around
To understand why the conversion work is not optional, it helps to know what a headset is doing while someone wears it.
It renders the scene separately for each eye, and it does that on a strict clock, commonly seventy-two to ninety times a second on current standalone hardware. Missing that clock is not a cosmetic issue the way a dropped frame in a video game on a monitor is. In a headset, when the image stops keeping up with the head, people feel it in their stomach. Comfort is a hard requirement, so the frame budget is a hard requirement, and everything in the scene competes for it.
That budget is not the same everywhere, which is why device choice and content cost are the same conversation:
- A standalone headset is a mobile chip in a plastic shell that also has to manage heat and battery. It is the most common target and the tightest realistic budget for a rich scene.
- A tethered, PC-driven headset borrows a workstation's graphics card and relaxes the budget substantially, which is exactly why it stays the right answer for large CAD and simulation datasets. We go through that trade in choosing an XR headset.
- Phone and tablet AR shares the mobile constraint and adds thermal throttling on a device the user is holding.
- Web AR is the tightest of all, because every asset has to download over a phone connection before anything appears, as we covered in web AR without an app.
So "can you use our models" has a technical answer that depends entirely on which of those you are shipping to, and a good vendor will ask about the device before they answer.
Where 3D content comes from, and what each source really costs
There are four sources, and they have very different economics.
Existing CAD or BIM
The best case, because the geometry is accurate and free. The work is subtraction: strip internal parts nobody will see, simplify the geometry to a mesh that renders fast while keeping the silhouette and the details that matter, rebuild the surfaces for texturing, and apply materials that respond to light instead of the flat colors CAD uses for parts. On a big assembly this is skilled, iterative work, and it is repeated for every asset in the app.
Scanning and photogrammetry
Right when the thing already exists in the world and matters more as a real place or object than as an engineering drawing: a building interior, a site, a machine nobody has a model of. You get realism cheaply, and you pay in cleanup. Raw scans are heavy, hole-ridden and lit by whatever the sun was doing that morning, and turning that into a usable asset is its own craft.
Built by an artist from reference
The most expensive per asset and the most controllable. Right for anything that has to be stylized, anything that does not exist yet, environments, characters, and any case where the source data is unusable. This is where an XR budget starts to resemble a game budget, because it is the same work.
Bought from a library
Genuinely useful, and undersold. Generic props, background objects, environment pieces and vegetation do not need to be authored from scratch, and buying them is often the difference between an affordable scene and an unaffordable one. Check the license before you build a commercial product on top of it, and expect to still spend time optimizing what you buy.
Most real projects mix all four. A good scoping conversation goes asset by asset about which bucket each one falls into, rather than treating "3D content" as one number.
What actually happens on the way in
The pipeline is roughly the same regardless of source, and it is worth knowing the shape of it so you can read a proposal.
Cleanup and reconstruction. Remove what is invisible or irrelevant, repair broken geometry, and rebuild dense or messy surfaces into an efficient mesh that holds the shape. This is where the biggest reductions happen.
Texturing and materials. The mesh gets a coordinate layout so images can be wrapped onto it, then materials that describe how each surface behaves in light: metal, painted steel, rubber, glass. Detail that used to be geometry is often moved into textures instead, which is how an asset can look intricate and still be cheap to draw.
Lighting decisions. Lighting that is calculated live is expensive; lighting that is calculated once and baked into the scene is nearly free but fixed. Which of the two you choose changes both the look and the budget, and it needs to be decided early rather than discovered at the end.
Level of detail and scene budgeting. Objects get multiple versions at different complexities so distant items cost less to draw, and the whole scene gets a budget rather than each asset being judged alone. A single asset is never the problem. Forty of them in one room is.
The parts that are not geometry. An industrial asset usually needs to carry data with it: part numbers, states, links into a maintenance system, sometimes live values. Planes XR, which we built for ARCortex, runs real plane simulations in the real world driven by live OpenSky data, and that pairing of visual asset with live feed is a different workstream from making the model look right. ERIS XR, our emergency-response platform for firefighters, depends on real building information rather than decorative environments. When the content is data-backed, the pipeline includes a data pipeline.
Interaction rigging. A model you look at and a model you use are not the same asset. If a user has to open a panel, remove a component, grab a handle or watch a mechanism move, the asset needs separated parts, pivots, animation, collision and grab points authored into it. On MR Camera, our multiplayer mixed-reality environment where several users place and interact with 3D models in shared space, that interactivity is the entire point of the content. Ask any vendor which of your assets are viewable and which are operable, because the second kind can cost several times the first.
The maintenance bill nobody puts in the proposal
Products change. Buildings get refitted. A revised part number means the training content is now teaching the wrong component.
If every asset update requires a specialist and a rebuild, your XR app has a slow expiry date, which is the same failure mode that kills AR training programs when nobody can author a step. Before signing, settle three things: you receive the source files and not just the compiled app, the conversion steps are documented and repeatable rather than living in one artist's memory, and there is an agreed path for how a changed part becomes an updated asset.
The counterexample is worth keeping in mind too. Not every XR project is content-heavy. Nystag, our clinical VR eye-tracking build on the Vive Focus 3, lives or dies on measurement precision, and its visual content is deliberately minimal. If your value is in accuracy, sensing or data, do not let anyone sell you an art budget you do not need.
What to ask before you commission the build
- What device are we targeting, and what does that do to the content budget?
- Which assets are viewable, and which have to be taken apart or operated?
- What state are our source files in, and has anyone technical actually opened them?
- Which assets can be bought rather than built?
- How many assets does version one truly need, and which are decoration?
- Who updates an asset when the real product changes, and with which files?
- Is any of this content data-backed, and if so, where does the data come from?
Those seven questions move an XR quote from a guess to a scope. The full price picture, including the engineering side, is in what an XR app costs and how it's scoped, and the discipline of proving the hardest part first is the same one behind how we ship in days rather than months: convert one representative asset, put it on the target device, and look at it before anyone commits to a catalogue.
The bottom line
3D content is not the free part of an XR project just because the models already exist somewhere. CAD, BIM, scans and renders each describe an object for a purpose that is not real-time rendering, and the work of getting from those to assets that hold a frame rate, respond to light, come apart in a user's hands and stay current when the product changes is a workstream with real cost. Scope it as one, ask which assets are operable rather than merely visible, insist on owning the source files, and the content side of XR stops being the surprise that eats the budget in month three.
Have 3D data and an XR idea, and want to know what turning one into the other actually takes? Book a demo and we'll scope the content workstream honestly, including telling you when your project needs less art than you think. See our XR work: ERIS XR and Planes XR for ARCortex, Nystag clinical VR eye-tracking on the Vive Focus 3, and MR Camera shared mixed reality.