3D Generation and Rive Pipeline
Clay can use generated 3D assets to make the plasticine design language tangible, but the generation service must not become the product surface. Generated 3D owns material mood and artifact creation. Code-native UI owns decisions, consent, accessibility, and opportunity fit.This page documents the product architecture and asset lifecycle. Vendor pricing, plan names, and
per-generation rates are deliberately kept off this public spec — they live in the internal
procurement record maintained by the Engineering/Design platform owner and are reviewed against
each vendor’s official pricing page before purchase or renewal. Reach out to the design platform
owner for the current procurement baseline.
On this page
- Tool roles — Meshy, fal, Tripo, Three.js, Rive
- The end-to-end generation pipeline
- The Rive usage contract
- 3D scene ownership layers and handoff
- Product guardrails for generated assets
- The internal cost baseline is held off this page; see the procurement record
Tool Roles
Each tool in the pipeline owns a specific stage. Tool boundaries keep generated imagery from leaking into product decisions.Meshy — primary generator
Owns the default text/image-to-3D path. Produces candidate
GLB assets, preview thumbnails, and
optional textures. Paid plans unlock commercial-use clarity and API access, so production assets
ship on a clean rights path.fal — premium fallback router
Routes image generation to premium models (for example Hunyuan3D or Rodin) when Meshy quality is
not enough for a hero asset. Selective, not bulk: fal does not become the default generator
because per-generation usage drifts without a budget cap.
Tripo — deferred backup
Held in reserve for faster stylized models, multi-view flows, smart low-poly, or auto-rigging
experiments. No subscription is purchased until Meshy has been proven insufficient for Clay’s
visual style or throughput.
Three.js + R3F — 3D scene renderer
Renders optimized
GLB/glTF assets in landing and product surfaces. Web/mobile product
surfaces never use generated bitmap screenshots where real 3D rendering is the right answer.Rive — stateful 2D motion
Ships
.riv files for state-machine motion: fit chips, readiness meters, consent badges, route
transitions, hover/tap responses, and product micro-interactions. Rive reacts to product state;
it is not the source of truth for user data or opportunity logic.Pipeline
Write the asset brief
Define the Clay primitive being shown: intention, personality, consent, opportunity route,
readiness, or partner fit. Include final surface, dimensions, motion needs, and rights caveats
before generating anything.
Generate candidates
Start with Meshy. Escalate to fal only when the asset is a hero candidate or Meshy fails the
target material, silhouette, or quality bar. Tripo stays out of the loop until Meshy is proven
insufficient.
Review and select
Reject models that make Clay feel like a toy, a mascot-first brand, a generic AI gradient, a
craft table, or a stock scene. Prefer matte plasticine forms on warm paper with crisp product
signals.
Optimize for runtime
Convert and optimize selected assets as
GLB/glTF. Keep mobile budgets conservative: decimate
geometry, compress textures, and avoid shipping oversized hero models unprocessed.Render in the product
Use Three.js or React Three Fiber for real 3D scenes. Provide responsive fallbacks for reduced
motion, low-power devices, and non-WebGL failure cases.
Rive Usage Contract
Use Rive for designer-authored motion that responds to product state. Rive is not the renderer for full 3D scenes and it is not the source of truth for opportunity data.| Use Rive for | Do not use Rive for |
|---|---|
| Animated fit chips, readiness meters, consent badges, and route transitions. | Storing opportunity recommendations, user reflections, or private model state. |
| State-machine reactions to hover, tap, scroll, selection, and visible product state. | Full real-time 3D rendering where Three.js/R3F is the correct renderer. |
| Mobile-friendly motion assets once the Expo app uses a development build. | Expo Go-only flows; the Rive React Native runtime requires native code. |
.riv assets that ship across web and mobile runtimes. | Generated 3D asset creation; Rive is not the primary 3D generation service. |
Rive’s emerging GPU Canvas / 3D direction can be explored in spikes, but Clay should treat it as
experimental until runtime support and editor stability are proven for the exact app surfaces.
3D Scene Ownership
The GLB pipeline has one owner at a time. Handoffs are explicit so generated imagery never silently substitutes for runtime 3D.| Layer | Owner | What ships |
|---|---|---|
| Asset generation | Meshy (default), fal (hero fallback), Tripo (deferred) | Candidate GLB assets, preview thumbnails, optional textures, with provenance metadata. |
| Asset storage | Static files in the web app first; Cloudflare R2 only when volume, review workflow, or dynamic generation requires it. | Optimized GLB/glTF files ready for runtime use. |
| Web runtime | Three.js + React Three Fiber | Real 3D scenes in landing and product surfaces. Added only when a real scene is being implemented. |
| Mobile runtime | Expo development build with Rive React Native | Shipped .riv state-machine assets for fit, consent, readiness, and route transitions. |
| Backend | Not built yet | Manual provider workflow must produce repeatable accepted assets before any 3D generation API is built. |
Product Guardrails
- Generated 3D is supporting material, not core UI text or controls.
- Every generated asset needs a provenance note: prompt, source inputs, provider, model, date, selected/rejected status, and rights caveat.
- Private user reflections, sensitive partner data, and secrets must never be sent to asset generators.
- Public pages should explain benefits first; provider names and runtime details belong in specs, implementation notes, or technical sections.
- Clay-specific signals must remain readable in code-native UI, not baked into generated bitmap text or distorted 3D labels.
- The mascot is always rendered as matte clay or soft ceramic with visible hand-formed surface variation. No glossy plastic, no perfect toy symmetry, no mascot holding phones, laptops, or generic tech props.
- Backgrounds stay off-white (paper) or transparent. Mascot expression comes from posture, shape, color, and accessory — not from glossy facial detail.
- One dominant accent color per scene. No purple-blue orb gradients, neon cyberpunk glows, or bokeh blobs.
Internal Cost Baseline
Vendor pricing, plan names, and per-generation rates are deliberately not included on this public page. They live in the internal procurement record maintained by the Engineering/Design platform owner and are reviewed against each vendor’s official pricing page before purchase or renewal. Reach out to the design platform owner for the current procurement baseline.Acceptance Criteria
- Clay has a paid generation path with commercial-use clarity before production assets ship.
- The first generated assets can be regenerated or audited from their prompts and provider metadata.
- Runtime 3D assets are optimized before landing in
apps/landing. - Rive assets expose explicit state inputs for intent, consent, readiness, and fit.
- The product still feels like an opportunity platform, not a generic 3D showcase.
- The mascot renders matte and tactile in every shipped surface.
Related
Design language
Plasticine metaphor, color tokens, shape language, and asset generation boundaries that the 3D
pipeline must respect.
Mascot
Anatomy, expressions, accessories, animation pacing, and rendering rules for the Clay mascot.
Motion
Motion tokens, easing curves, reduced-motion behavior, and how Rive state machines fit into the
wider motion system.
Themes
How Acid Lime, Editorial, and Dark Plum theme packs change mascot palette and motion pacing
without changing the rendering contract.