concinnity-core

Runtime vocabulary for the Concinnity engine: GPU layouts, ECS components, registry, CPU kernels.

This is the crate every other Concinnity crate agrees on and none of them owns: the backend-agnostic GPU data layouts the CPU and the shaders both name, the transform and skeleton math those layouts are expressed in, the ECS storage plus the component definitions and the registry built from them, the behavior virtual machine that evaluates declarative logic, and the .cnb blob container format a cooked world travels in. Above that vocabulary sit the kernels that belong to no single consumer: skinning and pose blending, IK, LOD decimation, rasterization, IBL convolution, procedural geometry, and the payload codecs.

Constraints

• no_std: the crate builds without the standard library, so the headless core runs anywhere. Math goes through libm, not std's inherent float methods.
• No build-side edge: the asset compile pipeline lives in concinnity-cook, which depends on this crate; this crate never depends on it. A shipped game links core without any importers or compilers.

Terminology

• Component: one typed entry in a world; both the authored schema (what a world.jsonl declares) and the runtime data it bakes into.
• Bake: turning authored data into the runtime form; the decoders and shared payload types live here under bake/decode.
• Blob (.cnb): the compiled binary container the runtime loads.

Most users want the concinnity facade crate rather than this one.