AI·October 2025·10 min read

Generative AI for 3D Product Modeling: Revolutionizing Design

Generative AI helps you produce and vary 3D product assets faster. It does not replace the delivery pipeline: glTF/GLB for web viewers, USDZ for iOS AR Quick Look, and a QA pass on every mesh before it reaches a product page. Teams that skip the pipeline ship broken AR experiences no matter how good the model looked in the generation tool.

Most "generative AI for 3D" pitches conflate two separate problems. The first is asset creation: turning a sketch, a photo, or a text prompt into a 3D mesh. The second is asset delivery: getting that mesh to render correctly, quickly, and in AR, on a phone a customer is holding in a store aisle or a living room.

Generative AI is genuinely moving the needle on the first problem. It has made almost no difference to the second.

The delivery pipeline is a solved, standardized problem with specs from Khronos and Apple that predate the current wave of generative 3D tools by years. If you're evaluating a 3D-for-commerce initiative, treat these as two separate work streams with two separate owners.

What generative AI actually does well right now

Generative 3D tools (text-to-3D, image-to-3D, and NeRF-style capture-to-mesh pipelines) are useful for three specific tasks in a commerce catalog:

Rapid variant generation — given a base mesh, generating color, material, or minor geometry variants for a product line without re-authoring each SKU from scratch.
Texture and material synthesis — generating PBR texture maps (albedo, roughness, normal) from reference photos instead of hand-painting them.
Draft mesh generation from 2D references — producing a rough mesh from product photography that a 3D artist then cleans up, rather than starting from a blank scene.

None of these outputs are commerce-ready on their own. Every generative 3D output still needs a retopology and cleanup pass before it can be compressed and shipped, for the same reason AI-generated code still needs a code review: the tool optimizes for a plausible result, not for the constraints of your specific runtime.

The delivery pipeline: two formats, two audiences

Once you have a clean mesh, delivery to a product page runs through two mature, unrelated formats. Confusing them is the single most common mistake in a 3D rollout.

glTF/GLB for web viewers

glTF 2.0 is a Khronos Group specification designed specifically for runtime delivery, not authoring. Khronos describes it as "the JPEG of 3D." It packages a JSON scene graph (nodes, materials, cameras) alongside binary buffers for geometry and animation data, with native support for physically based rendering (PBR) materials. glTF 2.0 became an ISO/IEC international standard (ISO/IEC 12113:2022) in 2022, which is why it's the format nearly every web 3D viewer — including Google's <model-viewer> web component and Shopify's theme-level 3D support — standardizes on.

GLB is the binary container form of glTF: one file, geometry plus textures plus materials, instead of a JSON file with loose references. That single-file packaging is why it's the format platforms accept for upload.

USDZ for iOS AR Quick Look

USDZ is Apple's zero-compression-archive variant of Pixar's Universal Scene Description, and it's required for native AR Quick Look on iPhone and iPad. Built-in apps — Safari, Messages, Mail, Notes — use Quick Look to render USDZ objects in the user's physical space, with support for embedded audio and predefined animations. Apple's guidance is explicit that USDZ file size is a first-order concern for AR Quick Look: a smaller file means a shorter download before the AR session can start, and Apple provides tooling to attach lighting-environment metadata so the object doesn't look flatly lit against a real room.

Android's equivalent path is Scene Viewer, which consumes glTF/GLB directly rather than requiring a second format.

Practical rule: author one clean mesh, then export twice. GLB for the web viewer and Android Scene Viewer, USDZ for iOS AR Quick Look. Platforms like Shopify serve the correct one automatically based on the visiting device — you don't build that branching logic yourself.

How this looks in a real commerce stack

Shopify's product media system is a reasonable reference implementation because it's public and well-documented. Its Admin API treats 3D models as first-class media: you upload a GLB or USDZ through fileCreate (for a publicly hosted file) or stagedUploadsCreate (for direct upload, with an explicit fileSize parameter), and reference the resulting file ID from a product, a specific variant, or a collection.

On the storefront, themes render the GLB through the model_viewer_tag Liquid filter, wrapped in an aspect-ratio container since 3D models don't carry a predefined aspect ratio the way images do. AR launch on supported devices runs through the Shopify-XR library, which filters product media for the model media type and registers it for AR Quick Look (iOS) or Scene Viewer (Android) via a JavaScript call, not a native app.

The pattern generalizes: one canonical mesh, two export targets, a device-detection layer that's usually handled by the platform, and a viewer component that's usually someone else's open-source project (Google's model-viewer) rather than something you build in-house.

Compression is not optional

Uncompressed GLB files from most generative and CAD-export pipelines are too large for mobile-first product pages. Draco, Google's open-source mesh compression library, is the standard answer — it's natively supported for decoding in Google's model-viewer and in Shopify's web-based model viewer, so encoding on your end doesn't require a custom runtime.

Compression is a geometry-fidelity trade-off, not a free win. Draco is lossy on vertex positions and normals by design; the failure mode is visible banding or faceting on curved surfaces if you compress too aggressively for a hero product shot. Test the compressed output on the smallest supported device before shipping, not just on a design workstation with a discrete GPU.

Where this breaks in production

Every 3D catalog rollout I've reviewed hits the same handful of failure modes, and none of them are AI-generation problems — they're QA gaps.

Non-manifold geometry. Meshes with holes, flipped normals, or self-intersecting faces render fine in a desktop 3D authoring tool and then fail or glitch in AR Quick Look, which expects watertight geometry for its physics and occlusion handling.
Wrong scale or up-axis. A mesh authored at the wrong real-world scale, or with Y-up instead of the format's expected axis convention, either floats above the floor or renders embedded in it during an AR session.
Texture bloat. 4K textures on every material slot of a small accessory model, shipped without mipmap generation, tank load time on mid-range Android devices — the majority of a global mobile audience.
No fallback image. If the 3D viewer fails to load — slow network, unsupported browser, WebGL disabled — the product page needs a static image fallback, not a blank box.

A pre-publish checklist catches essentially all of these before they reach a live product page:

Validate the mesh is manifold and normals are consistently oriented (most DCC tools have a built-in check).
Confirm real-world scale and axis orientation against the format's convention.
Run Draco compression, then visually diff the compressed model against source on a mid-tier phone.
Confirm both GLB and USDZ exports were generated from the same source mesh, not two independently exported versions that can drift.
Set a static image as the media fallback for unsupported browsers.
Load-test the product page with the 3D model on a throttled mobile connection profile, not just Wi-Fi.

Choosing where to invest

Approach	Authoring effort per SKU	Device/AR support	Best fit
Traditional photography	Low, mature workflow	Universal, no AR	High-SKU-count catalogs where visual differentiation between SKUs is limited
CAD-to-glTF/USDZ (manual pipeline)	High, needs a 3D artist per asset	Full AR support on iOS/Android	Hero SKUs, configurable products (furniture, hardware) where fit and scale matter
Generative AI-assisted (draft mesh/texture, human cleanup)	Medium — AI drafts, artist finishes	Full AR support once cleaned up	Product lines with many close variants of one base mesh (color, material, trim)
Fully automated generative (no human pass)	Low, but unreliable	Inconsistent — frequent manifold/scale failures	Internal prototyping only; not production-ready for customer-facing AR today

Team and ops implications

3D product media isn't a one-time content project — it's a recurring pipeline with its own ownership question. Decide early who signs off on a mesh before it ships: a merchandising ops team validating brand fidelity, or an engineering team validating file size and render performance. Both checks are necessary and neither substitutes for the other.

Track the same signals you'd track for any media asset that affects Core Web Vitals: does the model viewer delay Largest Contentful Paint on the product page, and does it need to be lazy-loaded below the fold. A 3D model that loads eagerly on every product page visit — most of which never trigger an AR launch — is a self-inflicted performance regression.

Picking an authoring path per SKU tier

Not every SKU deserves the same authoring investment, and treating the whole catalog uniformly is how 3D initiatives blow their timeline. A workable tiering:

Hero/flagship SKUs — full CAD-to-glTF/USDZ pipeline with a dedicated 3D artist pass. Worth the manual effort because these pages carry disproportionate traffic.
Line extensions of an existing hero SKU (new colorway, new trim) — generative variant/texture tools against the already-cleaned base mesh, since the geometry is already validated.
Long-tail SKUs — photography only, until traffic data justifies the 3D investment. There's no defensible reason to spend artist hours on a mesh for a product that gets negligible product-page traffic.

This tiering also determines where generative AI actually pays for itself: it's most useful in the middle tier, generating plausible variants off a mesh a human already validated, not at either extreme.

The mesh is the expensive, reusable asset. The export format is cheap and mechanical. Spend review time on geometry and scale correctness — the GLB/USDZ export step should be a build-pipeline afterthought, not a manual task repeated per SKU.

FAQ

Do I need both GLB and USDZ, or can I pick one?

You need both if you want AR Quick Look on iOS. Android's Scene Viewer and desktop web viewers consume GLB directly; iOS Safari and native apps require USDZ specifically for AR Quick Look. Platforms that support 3D media, like Shopify, expect you to upload both and handle device-based serving for you.

Can generative AI produce an AR-ready model with no human review?

Not reliably today. Generative outputs commonly need retopology, scale correction, and manifold-geometry fixes before they're safe to compress and ship. Treat the AI output as a draft, the same way you'd treat AI-generated code as a draft pending review.

How much does Draco compression actually save?

It varies by mesh complexity and texture count, so don't take a single vendor's number as universal. Test your own assets: compress, then compare file size and visual fidelity on the actual device tier your customers use, not just on a workstation.

Does 3D/AR product media help conversion?

We don't have a defensible, sourced industry-wide number to cite here, and you shouldn't trust one that isn't linked to primary data. Measure it directly: instrument AR launch rate, model-viewer engagement time, and conversion rate for SKUs with and without 3D media on your own traffic.

What breaks first when a 3D rollout scales past a handful of SKUs?

QA throughput. Manual mesh review doesn't scale linearly with catalog size, so the checklist above needs to become an automated validation step (manifold check, scale check, file-size budget) in your asset pipeline, not a manual gate per SKU.

Is glTF replacing USDZ, or vice versa?

Neither. They serve different runtimes — glTF for cross-platform web/Android delivery, USDZ for Apple's AR Quick Look — and the standards bodies behind them (Khronos and Apple/Pixar) have no stated plan to converge. Budget for maintaining both exports.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.