# LAVS-001 — comparison with Rive, glTF, USDZ, FBX | | | |---|---| | **Status** | Positioning document (informational) | | **Version** | 1.0 | | **Date** | 2026-05-27 | | **License** | CC BY 4.0 | This document is the honest comparison between LAVS-001 and the incumbents an external implementer or evaluator would consider. It exists because the question — "why not just use glTF?" — is the first one an engineer asks, and the answer being absent from the project's own documentation means the comparison happens in someone else's blog post. The comparison is structural, not promotional. LAVS does not do many things the incumbents do, and many of those things are deliberately out of scope. Where the incumbents are better, this document says so. --- ## 1. One-paragraph summary per format **LAVS-001** is a sealed-container format for **numbered, attributed, signed 3D scene editions**. Designed for releases of generative/procedural artworks where edition identity (who made this, what number is this, can the buyer verify it) matters as much as the rendered scene. Small (typically 1 KB to 1 MB), self-contained, version-pinned, refusable by the runtime when feature requirements are not met. Web-first; reference runtime is Three.js. Spec is open (CC BY 4.0). **Rive** is a binary format for **vector animation with state machines**. Designed for UI motion design — the entire stack from authoring tool to web/iOS/Android/Flutter runtimes. Excellent for stateful 2D animations driven by inputs (booleans, triggers, numbers). Spec is partially documented; primary path is the proprietary Rive authoring tool. Runtime is open-source per platform. **glTF 2.0** is the industry-standard format for **3D scene transport between authoring tools and runtimes**. Designed by Khronos for interoperability across game engines, 3D viewers, AR/VR platforms. Huge ecosystem; thousands of importers and exporters. JSON-based with binary `.glb` variant. Spec is open and exhaustively documented. The de facto choice for any 3D scene that doesn't need edition semantics. **USDZ** is Apple's **archive format wrapping Pixar's USD** (Universal Scene Description) for **AR/VR scene distribution**. Designed for ARKit and Apple's Quick Look. Heavyweight; can describe arbitrarily complex scenes including textures, animations, physics. Spec is open (Pixar) but the format is positioned around Apple's ecosystem. Tooling outside Apple is limited. **FBX** is **Autodesk's binary 3D scene format**, originally proprietary, now under restrictive licensing terms. The legacy format for game engine pipelines (Unity, Unreal, Maya, 3ds Max). Massive feature surface (skeletal animation, complex materials, embedded textures). Spec is partial / unofficial; the format is effectively gatekept by Autodesk's SDK. --- ## 2. Side-by-side feature comparison | Capability | LAVS-001 | Rive | glTF 2.0 | USDZ | FBX | |---|---|---|---|---|---| | Open spec | ✓ CC BY 4.0 | partial (binary undocumented in places) | ✓ Khronos open | ✓ Pixar open | partial (Autodesk SDK required for full) | | 3D scenes | ✓ first-class | — (2D vector primarily) | ✓ first-class | ✓ first-class | ✓ first-class | | 2D vector animation | — (out of scope) | ✓ first-class | partial via extensions | partial | — | | State machines | scaffolded in spec, not yet runtime-evaluated | ✓ first-class | — | — | — | | Edition metadata (title, author, edition #) | ✓ first-class in file | — (out of band) | partial via `KHR_xmp_json_ld` extension | partial via metadata layer | — | | Cryptographic signing | ✓ ed25519, first-class | — | — (no native signing) | — (no native signing) | — | | License declaration in file | ✓ first-class | — | partial via `KHR_xmp_json_ld` | partial via metadata | — | | Fast-path metadata read (no full decode) | ✓ ~few hundred bytes | — | full decode required | full decode required | full decode required | | Size for simple scene | ~1 KB (cube) | ~10–50 KB (state machine) | ~5–20 KB (binary glTF cube) | ~20+ KB (USDZ minimum) | ~50+ KB (FBX cube) | | Size for complex scene | ~640 KB (511 branches) | ~100 KB–1 MB | ~1–10 MB (geometry-dependent) | varies (often multi-MB) | varies | | IBL / Environment | ✓ procedural sky (v1.2); HDR deferred to v1.3 | — | ✓ via `KHR_environment_map_specular` extension | ✓ via UsdLuxLight | partial | | Animation evaluation | scaffolded; not runtime-evaluated yet | ✓ first-class with inputs | ✓ first-class (skeletal, morph, keyframe) | ✓ first-class | ✓ first-class | | Material PBR | ✓ MeshStandard + transmission + iridescence + sheen | — | ✓ first-class, very expressive | ✓ first-class | ✓ proprietary material model | | Textures (image) | — (deferred; v1.3+) | ✓ rasterized images | ✓ first-class | ✓ first-class | ✓ first-class | | Skeletal animation | — | — | ✓ first-class | ✓ first-class | ✓ first-class | | Native runtime ecosystem | Three.js reference, Python decoder | Web/iOS/Android/Flutter SDKs | Unity, Unreal, Three.js, every native 3D engine | Apple ARKit + Quick Look + native iOS | Unity, Unreal, Maya, 3ds Max, Blender | | Conformance test suite (operational) | ✓ 18 checks, cross-language validated | — (vendor-specific) | ✓ Khronos validators | partial | — | The pattern is clear: LAVS is **minimalist + edition-aware**; glTF is **expressive + transport-focused**; FBX is **expressive + legacy**; USDZ is **expressive + Apple-focused**; Rive is **2D + UI-motion-focused**. LAVS does not try to be glTF. It will not match glTF on geometric expressiveness, texture support, or skeletal animation. Those are out of scope by design. --- ## 3. When to use LAVS — concrete decision criteria **Use LAVS-001 if:** - Your scene is a **numbered, attributed, signed edition** — you sell individual copies, you care that buyers can verify authorship, you want the license to travel with the file. - The geometry is **procedural or fixed at sealing time** — animations are stylistic, not skeletal; the file is a release, not an authoring intermediate. - You want **fast-path edition badge verification** for marketplace or gallery use cases. - You want a **small, self-contained file** without sibling metadata. - You're building on the **web stack** (Three.js, WebGL) and want a format aligned with that runtime. - You want **forward-compatible versioning** with a clear additive minor / breaking major contract. - You want an **openly-implementable spec** that won't suddenly be paywalled. **Use glTF 2.0 if:** - You need broad ecosystem support — Unity, Unreal, every native 3D engine. - You have textures, complex materials, or skeletal animation. - You're moving a scene between authoring tools and runtimes, not releasing a numbered edition. - File size is not a primary constraint. **Use USDZ if:** - You're targeting Apple ARKit / Quick Look on iOS. - You want Pixar-quality scene description fidelity for AR/VR. **Use FBX if:** - You're in a game engine pipeline that requires FBX (Unity FBX import is most common). - You're working with legacy assets that exist only in FBX. **Use Rive if:** - Your animation is **2D vector with state machine logic** (UI motion, app onboarding, character poses driven by triggers). - You're not doing 3D. --- ## 4. What LAVS deliberately does not do (and why) ### 4.1 No native skeletal animation LAVS-001 has Animation / KeyedObject / KeyedProperty / KeyFrame Core types in the spec, but they are **scaffolded, not yet runtime-evaluated**. Skeletal animation, morph targets, and animation blending are not part of v1.X. Why: the format's target use case is sealed editions of (typically) procedural artworks. The runtime renders the scene; the artist's intent for "what moves and how" is encoded by procedural code at sealing time, not by skeletal rigs evaluated at render time. If your scene needs skeletal animation, glTF is the better fit. ### 4.2 No image textures (yet) LAVS-001 has no texture support in v1.X. Materials are color-only PBR (base color + metallic + roughness + transmission + emissive + iridescence + sheen). Textures are deferred to v1.3 or later. Why: textures inflate file size by 10x to 100x. For procedural-art editions, color-only PBR + procedural-sky IBL covers most aesthetic territory the work targets. Texture support will be added when there is a clear use case that justifies the file-size cost. ### 4.3 No multi-author support LAVS-001 has a single `author` field in the edition block. There is no native concept of collaborative authorship or multiple signers. Why: edition lineage is single-author by convention. Collaborations are encoded as the author field naming both parties (e.g., `"Alice Smith × Bob Jones"`) or as a free-form `provenance` string. Multi-author cryptographic signing is a v2.0 consideration. ### 4.4 No on-chain anchoring LAVS-001 does not anchor signatures to a blockchain. The signing identity is verified against a published HTTPS URL (`/pubkey.pem`), not a blockchain transaction. Why: on-chain anchoring introduces dependency on a specific blockchain, with its own performance and economic characteristics. The HTTPS-based publication model is more portable and does not assume the buyer participates in any specific blockchain ecosystem. Implementers who want on-chain anchoring can layer it on top (e.g., publish the signature hash to a blockchain) without changing the LAVS-001 format. ### 4.5 No native VR/AR runtime LAVS-001's reference runtime is browser-based (Three.js). There is no native VR/AR runtime in the reference implementation. Why: the target use case is web-rendered editions for collectors / galleries / marketplaces. VR/AR is a different runtime profile; a third-party VR implementer could build one from the open spec. The format itself is not inherently VR-incompatible — the runtime is just out of reference scope. --- ## 5. Hybrid / multi-format use cases LAVS-001 is not exclusive. The most likely real-world deployment scenarios combine LAVS with other formats: ### 5.1 LAVS for editions + glTF for export A gallery sells `.lavs` files to collectors. Collectors want to view their owned editions in a glTF-supporting tool (e.g., Three.js viewer that also reads glTF). The runtime can export a LAVS scene to glTF at view-time — the conversion is lossy (no signature, no edition metadata) but the geometric scene transfers cleanly. ### 5.2 LAVS for the signed release + Rive for the UI around it A gallery web app has Rive-driven UI animations for navigation, buttons, transitions, but renders the actual editions via LAVS. The `LavosMotionEngine` (proprietary) is the orchestrator that handles both substrates under one canvas surface. ### 5.3 LAVS as the public release, USDZ for Apple AR An artist releases an edition as `.lavs` and separately exports a USDZ derivative for buyers who want to view the work in AR on iOS. The LAVS is the canonical signed edition; the USDZ is a derivative the artist may license differently. --- ## 6. What incumbents do better This document would not be honest without naming what the other formats do that LAVS does not. - **Tooling ecosystem.** glTF has Blender, Maya, 3ds Max, Cinema 4D, every 3D engine, validators, viewers, marketplaces. LAVS has one reference encoder and a Python decoder. The 10-year tooling gap is real and is not closed by being faster on a few specific use cases. - **Authoring tools.** Rive has a polished visual authoring tool. LAVS authoring is via code (scene description in TypeScript). For artists who don't code, this is a non-starter today. - **Cross-engine portability.** glTF imports into Unity and Unreal trivially. LAVS does not (yet). A LAVS importer for Unity or Unreal would be a significant engineering project. - **Texture and material expressiveness.** glTF / USDZ / FBX have far more expressive material models. LAVS's color-only PBR is sufficient for the target use case but limiting for general 3D use. - **Skeletal animation.** All three (glTF, USDZ, FBX) handle skeletal animation well. LAVS does not. - **Schema validation tooling.** glTF has Khronos's validator, error catalogs, IDE integrations. LAVS has the conformance suite (good) but the surrounding tooling is much thinner. The honest summary: **glTF is the right answer for 95% of "I have a 3D scene to share" use cases.** LAVS is the right answer for the specific case where edition identity, signed authorship, and small self-contained portability are first-class concerns and the geometry/animation needs are bounded. --- ## 7. The category move LAVS is attempting LAVS-001 is not competing with glTF / FBX / USDZ on the transport-format axis. It is attempting to create a separate category: **edition formats**, where the file IS the release, not just the transport. The reference points in this category are: - **Foundation, fxhash, ArtBlocks** — generative art platforms that issue numbered editions, currently via per-platform stacks (URL + Ethereum NFT + off-chain JSON metadata + IPFS-hosted assets). - **Print editions** — physical art that has carried numbering / signing / authentication for centuries. - **Music releases** — albums that carry catalog numbers, artist credits, licensing terms baked into the release format. LAVS-001 is attempting to bring "the file IS the release" semantics to digital 3D editions. The format is small because the use case is portable; it is signed because the use case is verifiable; it has fast-path edition reads because the use case is gallery-scale browsing. If the category move works, the comparison will eventually be "LAVS vs other edition formats" rather than "LAVS vs glTF." Today, the comparison is necessarily against the transport formats because they are the available alternatives. --- ## 8. Decisions deferred for implementer feedback Pillar 2 is the adoption phase. As external implementers engage with LAVS-001, certain comparisons may shift: - **If LAVS gains a Unity importer** (third-party or first-party), the cross-engine portability gap narrows. - **If LAVS adds texture support in v1.3+**, the expressiveness comparison narrows. - **If LAVS gets an authoring tool** (not currently planned), the artist-accessibility gap narrows. This document will be revised as those shifts happen. v1.0 of COMPARISON.md is what's true today; subsequent versions will track the ecosystem's evolution. --- *This document is positioning. It is intentionally honest about LAVS's limitations vs incumbents because the format's credibility depends on the comparison being something a third party can verify, not something that hides the trade-offs. If an external implementer disagrees with any claim here, file an issue at [github.com/guitargnarr/lavs-format/issues](https://github.com/guitargnarr/lavs-format/issues) — the document gets revised when the ecosystem changes.*