XO3D
The product asset and the visual layer
The accurate build made from your CAD, the materials, the colour values, the creative direction, and every rendered or real-time derivative produced from it. This is the layer everything else displays.
XO3D Studio · Delivery and integration
Where the work
goes live.
XO3D delivers three things into your environment: the final files, a production-ready 3D model, and where the brief calls for it, a built interactive or AR experience. How that reaches a live site varies by project. Sometimes our in-house developers build and embed it. Sometimes your team implements from what we deliver. What stays with you, by design, is the commerce platform, CPQ, CRM and analytics, because a studio should not sit in the middle of a system it does not operate.
This page covers how XO3D visuals and experiences are handed to your own website, shop or agency. It does not describe a connection to any particular shop platform, accounting package or CPQ system.
A bounded example
On the Rollink Flex 360 project, XO3D made the product CGI and the colourway imagery of each finish. Rollink’s own team built the colour selector on its website from that imagery. So the images were XO3D’s work, and the selector, its hosting and its upkeep were Rollink’s. XO3D did not build, host or integrate that selector, and does not maintain it. That split is the kind of boundary this page is about. Read the Rollink Flex 360 case study.
Four honest routes
Who does what,
and when.
There is no single correct answer here, and a studio claiming otherwise is selling rather than advising. This is how the four routes actually compare.
Our developers build it.
The experience itself is the deliverable, or your front-end team has no capacity for it.
XO3D has in-house web development. We build and run our own estate, including the Labs tool platform, its embeddable widgets and its account layer. Where a brief needs the interactive built rather than just the asset supplied, that work can sit with us.
Your developers implement it.
You own the platform and the design system, and the 3D asset is what you actually need.
XO3D delivers the model and agreed outputs to your specification and your team takes it from there. This is the cleanest boundary and it is the right answer more often than studios like to admit.
Your platform vendor handles it.
A configurator or product module already exists and needs assets to a defined spec.
XO3D produces to the spec their platform requires. The vendor keeps the integration they built and support, and nobody ends up maintaining a system they do not operate.
Your agency runs the build.
The CGI is one part of a wider campaign or site build somebody else is leading.
We work to the creative direction and the delivery schedule already agreed, with the handoff and approval owners defined before production starts.
Ownership map: five layers, agreed per project
| Layer | Who can own it | When it is agreed |
|---|---|---|
| Visual asset and creative direction | Usually XO3D | At brief stage, with the approved product source and the outputs each channel needs. |
| Experience and configuration | XO3D, your developers, a platform vendor or your agency | Before production, once it is clear who builds the interface and the option rules. |
| Hosting and delivery | Your infrastructure, a platform, or XO3D where scoped | Before build, including who keeps it running and what happens when hosting ends. |
| Commerce, product data and CPQ | Your systems and whoever implements them | Outside the visual scope. SKU mapping, pricing and baskets stay with that system. |
| Measurement | Your analytics and the data owner | Before launch: what to measure, the baseline, and who reads the results. |
The owner of each layer is agreed for each project. XO3D can build the experience where that is scoped; on other projects your platform, its vendor or your developers own the implementation. Commerce systems and measurement stay with you either way.
Choose the handoff route
These are routes to discuss, not automatic recommendations. Each one matches a route described above.
- If your front-end team owns the site
- Discuss an asset handoff: formats, sizes, naming and who receives the files.
- If you already use a configurator platform
- Get the platform’s asset specification and agree with its vendor who does what.
- If an agency is leading the build
- Agree its design and delivery requirements, and the approval owners, before production.
- If the experience itself needs building
- Scope the experience and where it will be hosted before any work starts.
The boundary
What stays
yours.
XO3D takes the 3D, the interactive and getting it live, including web build where that is the right route. Three things stay on your side, and not because we cannot reach them.
- Commerce platform, PIM and DAM
- Your product data and asset management stay yours. We deliver to the specification your systems require, which is a specification met rather than a pipe connected.
- CPQ and CRM
- Quoting and customer records are operational systems tied to your pricing, your rules and your sales process. A visual studio has no business inside them.
- Analytics, testing and attribution
- Measurement belongs where the data lives. We can tell you what to measure and what good looks like, and the reporting stays in your stack.
A stated edge is worth more than an open offer. It means the scope you agree is the scope that gets delivered, and nothing important is left sitting between two suppliers who each thought the other had it.
On the measurement side of that boundary, what to measure and who owns it sets out the primary measure worth agreeing for each kind of commission, and what a studio can and cannot see.
The stack around the asset
Who owns which layer.
A 3D commerce programme is rarely one supplier. It is a stack, and most of the argument about who does what is really an argument about which layer somebody is standing on. This is where we stand, and where we do not.
A platform, or your developers
Configurator and product experience
Variant logic, rules, pricing display and the interface a buyer actually uses. We produce assets to the specification that layer requires rather than rebuilding it.
Threekit, 3D Cloud by Marxent, Cylindo, Emersya, Expivi and Vectary all operate in this category.
A platform, or your stack
Viewing, hosting and asset delivery
Where a model or a spin is stored, optimised and served to a browser at the size and speed a page can carry.
Sketchfab and Sirv operate here. Matterport sits adjacent, capturing spaces rather than products.
Your systems
Commerce, product data and CPQ
Quoting, pricing rules, product records and the commerce platform itself. These are operational systems tied to your business, and a visual studio has no business inside them.
Your stack
Measurement and attribution
What the work is judged on, and the data that judges it. We can say what to measure and what good looks like. The reporting stays where the data lives.
Those platforms are named so you can place the work, not because XO3D has a relationship with any of them. We are not a partner, a reseller or an accredited implementer of any platform, and we do not claim to be. Where your brief needs one of those layers built rather than supplied to, the honest answer is usually that the layer's own vendor or your developers should own it, and we should own the asset inside it. How that split works in practice is on product interactives, and the wider supplier-model comparison is in choosing a 3D content partner.
- Visual asset
- Experience or platform
- Your commercial system
Most projects
The handoff,
in detail.
On the majority of briefs, integration means a delivery your team can use immediately. That is a specification question, and it gets settled at brief stage.
- Formats
- Stills as PNG or JPEG, with TIFF and layered PSD on request; motion as ProRes or H.264; 3D as GLB, GLTF, USDZ, FBX or OBJ. Confirmed against your requirement before delivery, not after.
- Colour and resolution
- sRGB for digital, Adobe RGB for print, at the resolutions each channel actually needs.
- Naming
- An agreed naming convention across the whole delivery, so the files arrive usable rather than needing renaming.
- Review
- Structured review through Frame.io for video or an equivalent for stills, with links scoped to named people on your side.
Handoff checklist
Six questions to settle with the person receiving the work. They are questions to answer for your project, not standard guarantees, and no asset is assumed to meet your requirements until it has been checked against them.
| Item | Question to answer |
|---|---|
| Technical contact | Who is the named technical contact, and who receives the delivery on your side? |
| Destination | Which site, page or app is it for, and is there a test environment? |
| Product source | Which CAD or reference is the approved revision? |
| Files | Which formats, dimensions and naming convention, and which visual references show what the result should look like? |
| Restrictions | Which devices must it work on, and are there performance limits or content security policy rules? |
| Acceptance and support | Who checks it before launch, and who supports it afterwards? |
Review production specifications, or prepare a CGI brief with these answers in it.
Meeting a retailer or marketplace specification is part of the deliverable, not a separate project. See CGI for ecommerce for how hero, silo, lifestyle and detail imagery is built for product detail pages and retailer listings.
Interactive and AR
Where it
actually runs.
A viewer, configurator or AR model has to run somewhere, load fast enough on your worst-case device, and survive your site's content security policy. Those are the questions that decide feasibility, and they are worth asking before anyone builds anything.
XO3D builds and runs embeddable experiences on its own platform, so the delivery route is not theoretical: the Labs tool platform includes a published embed system and widgets designed to sit on third-party sites. On client work the route varies, and hosting on our side can be arranged where it is genuinely the better option.
Before the experience goes live
- Confirm the supported devices and browsers, the approved product revision, the file budget, any content security policy rules and who deploys it.
- Agree what visitors see if the experience cannot run, such as a still, a video or a plain product image.
- Record who tests it in the real destination and who approves it.
These are sensible questions to settle, not a promise that an experience will be fast, secure, accessible or compatible everywhere. Platform behaviour, commerce rules and reporting stay with whoever owns those systems.
For what each interactive format supports and when it is worth doing at all, start with when do you need interactive 3D, then Product Interactives and Product AR.
Choose the right route
Where to
go next.
SpecificationsSource material, accuracy, production methods and delivery windows.3D ModellingThe production-ready asset everything else is built from.Product InteractivesTurntables, configurators and explainers for your site.CGI for EcommerceImagery engineered for product pages and retailer listings.
Before you brief
A few technical
answers.
Who builds the interactive or configurator, XO3D or our developers?
It varies by project and it is agreed before production. XO3D has in-house web development and can build and embed the experience. Equally, if your team owns the platform and the design system, we deliver the 3D asset and outputs to your specification and your developers implement. What decides it is usually who owns the surface it runs on and what front-end capacity you have.
Can XO3D deliver assets straight into our PIM, DAM or commerce platform?
Delivery is a file handoff or a built and embedded experience, produced to whatever specification your systems require. XO3D does not write into your product data or asset management systems, and would not recommend a supplier who offered to. Meeting a retailer or marketplace specification, including specific requirements from retailers such as John Lewis, AO.com or Currys, is a standard deliverable requirement rather than a separate integration project.
Does XO3D provide analytics, A/B testing or conversion reporting?
No, and that is deliberate. Measurement belongs where your data already lives, in your analytics, your commerce platform and your CRM. We can advise on what to measure for a launch and what a reasonable result looks like, and the reporting stays yours. A studio that owned your measurement would be reporting on its own work.
Can XO3D host the experience for us?
Where hosting on our side is genuinely the right route it can be arranged and has been done. More often the better answer is that the experience lives on your infrastructure, because that is where your uptime, your security review and your support arrangements already are. Worth deciding at brief stage rather than at delivery.
What do you need from our team to get an interactive live?
A named technical contact, the platform and page it needs to run on, any performance or file-size limits your site enforces, your supported browsers and devices, and who signs off the implementation. Where an embed is the route, we also need to know any content security policy restrictions that would block it. Resolving those before production is faster than discovering them at launch.
Start with the setup
What does it
have to plug into?
Tell us the platform, who owns the front end, and what the experience needs to do.
Talk through your setupYour next project
Define the handover before the build.
A successful integration needs a host platform, supported devices, asset requirements and a named implementation owner. The product film below is a visual reference, not proof of a particular software integration.
A route to consider
Product interactives
A product experience scoped around a useful interaction, supported devices, model performance and a clear fallback.
Bring these three things.
- What platform will host the work?
- Who owns implementation?
- What device and performance criteria apply?
Start with an outline. We review the product, intended outputs and timing before agreeing the production scope.