Draft changes for Shapes and Bounding Volumes in glTF 2.1

[weegeekps]

This PR contains the draft changes for Shapes and Bounding Volumes in glTF 2.1. This PR currently points towards the draft-2.1 branch and should be safe to merge to that branch.

These changes were authored by @lilleyse.

Relevant Issues:

• [glTF 2.1] Shapes #2588
• [glTF 2.1] Bounding Volumes #2587

Summary from Copilot:

Major Additions:

1. Bounding Volumes for Nodes

• Added the boundingVolume property to the node schema, allowing nodes to specify a local-space bounding volume for culling, loading, or other spatial operations. The bounding volume references a shape and can be transformed relative to the node. (F06053e9R1, specification/2.1/schema/boundingVolume.schema.jsonR1-R47)
• Documented how bounding volumes are defined, how they are used in hierarchies (BVH), and best practices for asset authors.

2. Shape Definitions and Registry

• Introduced a new top-level shapes array in the glTF schema, enabling authors to define reusable shape objects.
• Documented the available built-in shape types (box, sphere, capsule, cylinder, plane), their parameters, and requirements for validity.

3. Shape and Bounding Volume Schemas

• Added a general shape.schema.json describing the structure of a shape, including type and type-specific parameters.
• Added individual schemas for each built-in shape type: box, sphere, capsule, cylinder, and plane, each with their own required parameters and validation rules. [1] [2] [3] [4] [5]
• Added a boundingVolume.schema.json describing how a bounding volume references a shape and specifies its transform.

Summary of Most Important Changes:

Bounding Volumes

• Added boundingVolume property to nodes, referencing a shape and specifying transform (rotation, scale, translation). (F06053e9R1, specification/2.1/schema/boundingVolume.schema.jsonR1-R47)
• Documented the usage, best practices, and implementation notes for bounding volumes and bounding volume hierarchies in the glTF spec.

Shape System

• Introduced a top-level shapes array in glTF, allowing reusable, parameterized shape definitions.
• Documented built-in shape types and their parameters, including validation requirements and extension mechanisms.

Schema Additions

• Added shape.schema.json and individual schemas for each built-in shape type (box, sphere, capsule, cylinder, plane) to validate shape definitions. [1] [2] [3] [4] [5] [6]
• Added boundingVolume.schema.json to validate bounding volume definitions and their relationship to shapes.

[EricGriffith]

Do we want to include mesh shape before we publish or do we want to incrementally publish?

[bjornblissing]

Duplicating my comment from the issue:

Could the specification clarify how a node's transform applies to its boundingVolume?

My understanding is that the shape is defined in canonical local space, then the optional boundingVolume scale / rotation / translation are applied relative to the node's local coordinate system, and finally the node's own matrix or TRS transform (plus ancestor transforms) places the volume in world space.

In other words, is the intended relationship:
shape local space → bounding-volume transform → node transform → parent transforms

If so, it may be helpful to state this explicitly.

[EricGriffith]

Duplicating my comment from the issue:

Could the specification clarify how a node's transform applies to its boundingVolume?

My understanding is that the shape is defined in canonical local space, then the optional boundingVolume scale / rotation / translation are applied relative to the node's local coordinate system, and finally the node's own matrix or TRS transform (plus ancestor transforms) places the volume in world space.

In other words, is the intended relationship: shape local space → bounding-volume transform → node transform → parent transforms

If so, it may be helpful to state this explicitly.

I agree with this, but we'll discuss in the DTSG.