Skip to content
Cyberplanetary

Cyberplanetary standards · CP 0004

CP 0004 v0.2.0 Static GLB Scene profile

Released 2026-10-04T11:01:58Z by Cyberplanetary. Status: current. Change class: initial development.

Summary of changes: Restructure published 0.1.0 provisions as a numbered standard; correct informative demonstration names where applicable.

Digest: 4884c77715b3d68ac3f83ad860ba5cb93c2e2268bb76e0bbe23f743554885379

Files

The canonical file is the authoritative text; it never changes.

FileRoleSHA-256
cp-0004-0.2.0.mdcanonical1cbd55d07d92411d9bf0579992bea9017606b84c70c9c982bfbe308b7818c0bb

Static GLB Scene profile

CP 0004 v0.2.0 (2026-10-04T11:01:58Z)

  • Publisher: Cyberplanetary
  • Kind: profile
  • Version: initial development (major version 0): any change may break
  • Cite as: CP 0004 v0.2.0 (this version); CP 0004 (always the latest stable version)

Summary of changes: Restructure published 0.1.0 provisions as a numbered standard; correct informative demonstration names where applicable.

The status of a version (current, superseded, withdrawn) is not part of this text, because it changes after release. See https://cyberplanetary.org/standards/cp-0004/.

Cyberplanetary standard. Distributed with the project under AGPL-3.0-only; see the canonical repository LICENSE. Standard status is recorded in the series catalogue.

Contents

Introduction

Profile identifier: https://cyberplanetary.org/profiles/gltf-scene/0.1.0/

The preceding text was dated 2 October 2026 and is preserved at its original version URL. Its verified source is the Cyberplanetary protocol repository, commit eae66fe9ca90f5b0398e16377a0e4cb8a4cb4da7. This standard’s document version is distinct from the unchanged wire-format strings and exact profile claim identifiers.

1 Function and bases

This profile permits a small, self-contained static three-dimensional scene to be published and read consistently. It profiles Linked Resources 0.1.0 and Khronos glTF 2.0's binary container and static mesh model. The constraints below select a deliberately small valid subset; they do not rename a proprietary scene format glTF. This is not a general game engine, avatar protocol, physical simulation, or promise to render every glTF feature.

2 Publisher requirements

G-CLAIM. The publisher advertises both this profile and Linked Resources for the same world target. This profile's parameters.scene names a resource id in that world's resource manifest. The selected resource MUST have role:"scene" and mediaType:"model/gltf-binary". Its size and hash follow the Linked Resources profile.

G-SUBSET. The scene MUST be a valid glTF 2.0 GLB with one JSON chunk and one embedded binary chunk. The JSON chunk is at most 1 MiB and the complete GLB at most 32 MiB. There is one scene, designated by scene:0 or the glTF default selection used by this profile. It contains at most 10,000 flat root nodes with no children; every node occurs exactly once as a root. Every node references a mesh and uses only translation, normalized quaternion rotation and strictly positive scale, with glTF defaults when absent. Node matrices, cameras, skins, animation, morph targets and glTF extensions are excluded.

Mesh primitives use TRIANGLES, POSITION and NORMAL, and an explicitly referenced opaque material. Positions and normals are tightly packed FLOAT VEC3 accessors with equal counts, no sparse or normalized accessors, finite values, and valid buffer bounds. Positions include min/max bounds agreeing with decoded data within 1e-5 * max(1, abs(bound)) per component. Normals have length within 1e-4 of 1. Optional indices are tightly packed unsigned byte or unsigned short SCALAR accessors in range; a primitive's effective vertex/index count is divisible by three. Buffer views have no byteStride, and there is one embedded buffer with no URI.

Materials use pbrMetallicRoughness with explicit metallicFactor:0 and roughnessFactor:1, an opaque base color factor with alpha 1, and no texture, emissive contribution, image, skin or extension dependency. A publisher may mark a material double-sided. The resource requires no remote assets.

These limitations make this initial profile cheap to implement and unambiguous for its demonstrated function. Worlds requiring other features can use another independently specified profile or simply offer their resources without claiming this profile. Geometry remains absent from the core.

3 Reader requirements and limits

G-READ. A reader first performs the selected Linked Resources checks. It MUST report unsupported features rather than silently treat an out-of-subset asset as conforming. A rendering implementation follows glTF's coordinate, triangle and node-transform conventions. The profile does not prescribe camera controls, lighting style, exposure, shadows or pixel-identical rendering. Static mesh rendering is separate from authorization to edit or execute a world.

The reference includes an original mesh generator, a native WebGL view, and a bounded structural subset checker. The mesh generator is not a universal world authoring tool. A labelled Canvas software preview is supplied when WebGL is unavailable; its painter-order occlusion is approximate and is not advertised as a full depth-buffer rendering implementation. The supplied view is intended for the generated subset; the separate checker is the reference's explicit profile-validation path. Its tests do not claim exhaustive validation of all legal/illegal glTF documents, independent certification, or cross-vendor rendering equivalence. Source and committed bytes are downloadable so another renderer can test the same asset.

4 Why a separate profile

Journal Vaults uses the shared Linked Resources profile without this one and has no geometry. Cipherlot adds this agreement only for the named scene. Core listing, signature verification and profile-claim retention work in both cases. This is selective interoperability, not an inference that every indexed world has a coordinate system.