I’m Gerhard from viSales (Bochum, Germany). Honest intro first: I sit mostly on the visual / sales-communication side of OpenUSD, not the engineering side and my colleague Thomas Kumlehn is the one who joins the USDWG calls every two weeks. That slightly-outside angle is exactly what led to the little tool I’d like to share and get your feedback on.
The problem that started it. We use USDZ a lot in B2B sales, means product models travelling from engineering to an agency, to a trade fair, to a customer. The same question kept coming up internally, almost always from marketing or sales people rather than developers: “What’s actually inside this USDZ? Will it even show up in AR Quick Look? Where did these textures come from?” There was no simple way for a non-developer to just look inside the file and answer that.
The origin. It literally started one evening during XR Expo in Stuttgart. I sat down and — with heavy AI assistance (Claude), since I’m not a USD engineer — built a first version of a browser tool that opens a USDZ and shows what’s in it. It grew from there.
What it is. A single HTML file that runs entirely in your browser: no upload, no backend, no account, works offline / air-gapped. Apache-2.0. It’s deliberately built for the people receiving a USDZ, not for engineers:
What’s inside: geometry, textures (resolution / format), materials, documented sources — and, just as important, what’s missing and needs clarification before release.
An AR Quick Look readiness check: 21 rules across 7 categories (structure / defaultPrim, scale & axes, textures, external references, manifest, animation, performance), color-coded error / warn / info.
For files signed with our USDseal layer: issuer, timestamp, version trace, and a per-component hash / tamper check. That part is optional — Inspector reads any plain, unsigned USDZ too.
Where I’d genuinely love feedback — and where I know it’s still rough:
The AR Quick Look checks are experimental. I encoded Apple’s documented (and partly undocumented) requirements as best I could. If you know these constraints better than me, I’d really value corrections — which rules are wrong, too strict, or missing.
The built-in 3D viewer is experimental too. When I find the time I want to improve it using Apple’s native <model>rendering. Ideas welcome.
And generally: is this useful to anyone beyond our own workflow? What would make it more useful to you?
Thanks for taking a look — and thanks to this community, I’ve learned a lot just reading along here. Happy to answer anything.
Gerhard
(To be save: USD is a trademark of Pixar Animation Studios. USDseal is an independent tool by viSales and is not affiliated with or endorsed by Pixar.)
Hi Gerhard, the scheme looks interesting in principle and bears resemblance to other proposals such as C2PA which has its own proposal for how to embed provenance tracking within a USDZ archive. I might suggest joining the ongoing discussion at the usd-proposals site. I tried a sample USDZ file on your demo, and I do appreciate the utility of an online authenticator/validator, that is a nice prototype of what such as system could potentially be.
I encoded Apple’s documented (and partly undocumented) requirements as best I could. If you know these constraints better than me, I’d really value corrections — which rules are wrong, too strict, or missing.