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.
Follow-up after actually reading PR #107 — apologies, my first reply came too quickly.
I’ve now gone through the proposal carefully. The four-concern framing is very useful — it separates things that usually get tangled in one conversation. Two observations from our B2B manufacturing use cases that might be worth adding to the open questions:
1. The receiver side. The proposal focuses (understandably) on asset creators and pipeline engineers. In our workflows, the person who needs to verify provenance is usually not an engineer > it’s marketing or procurement, someone who received a USDZ from an agency or supplier and needs to answer: “Was this changed? Where did these textures come from? Does this even run in AR Quick Look?” That’s the reason the Inspector exists: make Concern 4 verification accessible without a terminal, Python, or USD knowledge. The “what requires external systems” column in the proposal might benefit from a line about non-technical recipient tooling.
2. The return path. PR #107 frames tiered delivery (Concern 1) as one-directional > you export a curated sub-asset, done. In practice, the sub-asset often comes back: an agency delivers a textured version, a customer adds annotations, a supplier adjusts geometry. My USDseal’s merge command handles controlled re-integration > it brings the child asset back into the master with provenance continuity, so the lineage of what changed is preserved. This feels different from the “recombination problem” described in the proposal (unsanctioned reassembly from unrelated components). This is sanctioned round-trip delivery > and as far as I can tell, neither #107, #105, nor #106 address it. Worth an open question?
Happy to contribute use cases from the manufacturing/B2B-sales side if useful for the proposal.
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.