Jan Sutter, Kristian Sons, Philipp Slusallek

| Factor | Approach |
|---|---|
| Network Bandwidth | Reduce Size (Compression) |
| Network Latency | Reduce N° of Requests |
| Decoding Time | Parallelize |
| User Experience | Early Results |
* Dozens of approaches in literature * Good compressors use domain-specific knowledge * Mesh compression looks different from mesh animation compression * Often restricted to one specific characteristics (e.g. manifold meshes) * Best solution depends on application, network and device
* Never trust a paper with Stanford Buddha * It is a single mesh!
* One request per mesh: 468 requests * Browsers spawn 6-8 requests in parallel
* One request per mesh * JSON * OpenCTM * Multiple requests * JSON with binary buffer URLs * X3D BinaryGeometry [Behr et al. 2012] * SIG [Behr et al. 2012] * POP [Limper et al. 2013]
* XML * Addressing: id / fragment * Compression: gzip * Slow to parse, hard to stream * Binary XML formats not suitable for Web * glTF * Scene structure: JSON * Buffers: Binary container * Addressing: URL / Offset / Size * Compression: Registry * Streaming?
* We require a format that is: * Generic * 3D data is heterogeneous * Structured * 3D data is and structured * Single request per mesh does not scale * Streamable * Need early results * Supports arbitrary compression * Compression is domain-specific
* JSON as basis * Plus support for Typed Arrays * Plus addressing schema * Sender * Applies encoder compression * Encodes used encoder as URL * Flattens and chunks the result * Receiver * Can request decoder on demand * Is able to reconstruct JS object
[{ path: '/mesh/16', offset: 0, size: 12345, decodingSpecification: 'http://blast-format.com/decoders/open3dgc' }, { path: '/textures/fabric', offset: 12345, size: 12345, decodingSpecification: 'http://blast-format.com/decoders/png' }]
1. Grab binary blob 2. Decode blob 3. Attach result to JS object based on path 4. Result may also be a structured JS object
* Designed but not limited to 3D data * Blast is typeless by design, it only knows about binary blobs * Container format for binary transmission of key-value structures (JSON-like) * Only information necessary for reconstruction is transported
* Each value in a key-value data structure is uniquely identifiable by its path * Blast uses this path to address individual sub-resources inside a transmission * Slash-separated property path similar to XPath
* Each chunk is self-contained * It contains all information necessary to decode the transported data * Can be processed in parallel * Can be cached and reordered on the server * Multiple blobs can be sent together in a single chunk * Each blob can be processed independently * A blob is never split across multiple chunks
* No encoding defined in Blast * Each value inside the key-value structure can be encoded differently * Each encoding is uniquely identified by a URL * Clients can request a decoding implementation on demand (Code on Demand) * Different implementation can be provided (content-negotiation) * Clients can use the URL to identify and map to existing high performance implementations (RiverTrail, WebCL, ...)
* A single request per resource * Multiple or all resources in a single request * Streaming all resources in chunks
* Minimal overhead * Leverage existing codecs * OpenCTM * Open3DGC * Overcome their limitations * Predefined schema * Structureless
* Client only interested in the data not the en/decoding * Blast handles the decoding * Code on Demand * Structured * However: * URL is unique identification * Short circuit possible * Client always in full control
* No API for streamed binary XHR * Firefox: ``moz-chunked-arraybuffer`` * [Streams API](http://www.w3.org/TR/streams-api/) to come? * Can be used with WebSocket API
| Factor | Approach | Blast |
|---|---|---|
| Network Bandwidth | Reduce Size (Compression) | Arbitrary Compression |
| Network Latency | Reduce N° of Requests | Structured |
| Decoding Time | Parallelize | Self-contained Chunks / Blobs |
| User Experience | Early Results | Streamable |
* Intel Visual Computing Institute * EU Future Internet PPP: * FI-CONTENT, FI-WARE/FI-Core, FITMAN * EU FP7 project: VERVE