Skip to main content

Crate concinnity_core

Crate concinnity_core 

Source
Expand description

concinnity-core: the engine’s RUNTIME vocabulary and the CPU compute over it. The types the renderer, the cook pipeline, the subsystem crates, and the editor all have to agree 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 mechanism plus the component definitions and the registry built from them, the post-process / quality setting structs, the behavior virtual machine that evaluates declarative logic, and the .cnb blob container format the cooked world travels in.

Above that vocabulary, the kernels that compute over it and belong to no single consumer: skinning and pose blending, IK, LOD decimation, rasterisation, IBL convolution, the procedural geometry generators, and the payload codecs (build, decode). Each asset’s AUTHORED schema (what a world.jsonl declares) sits in components beside the runtime half it bakes into; the build-only assets, which never reach a running world, live with their registry group in concinnity-world. The asset COMPILE pipeline is concinnity-cook, which this crate has no edge into.

Modules§

behavior
The behavior virtual machine: an authored Behavior compiled to slot-resolved form, and the evaluator that runs it.
blob
The .cnb blob container format.
build
Asset payload format helpers + the shared build-time types. The asset COMPILE pipeline (importers, encoders, image/glTF decoders, source-image format decoders, shader compilation, the world expansion + check front-half, and blob writing) lives in the concinnity-cook crate; this module keeps only what a running engine needs: the pre-compiled payload deserialise family plus the payload-format types and consts. Submodules stay pub so both the client runtime and the build crate can reach them across the workspace split.
components
Every component type the runtime can store: the ones an authored world declares and the ones only the runtime mints, plus the resources the cook compiles into the blob’s resource stream.
decode
Bounds-checked primitives for reading bytes the process did not produce: compiled payloads loaded off disk, and the artist-supplied image files the cook pipeline imports. Both are external input, so a truncated, corrupt, or hostile buffer has to surface as an error rather than a panic.
ecs
The renderer-free half of the engine’s ECS: the storage mechanism, the per-tick context systems see, and the asset identity + registry layer the build / validate pipeline and the client runtime share.
geometry
The runtime geometry the engine builds on the fly: voxel-chunk streaming (build_chunk_mesh / build_chunk_impostor_mesh regenerate a chunk’s mesh as it streams in), the glass/water quad generators the GPU backends call, and the shared low-level mesh math (per-vertex tangents, face normals, the vertex tuple type) that both this runtime path and the cook compile path use.
gfx
The GPU-facing half of the runtime vocabulary and the CPU compute over it: the #[repr(C)] structs the CPU and the shaders both name (render_types), the transform and skeleton types animation is expressed in, the culling and LOD primitives the backends test against, the screen-overlay and chunk-grid coordinate spaces, the post-process / quality setting structs, and the render-prep kernels that feed them: skinning and pose blending, IK, LOD decimation, software rasterisation, payload decoding, line expansion.
math
The scalar, vector and rotation primitives the rest of the vocabulary is built from: the f32 transcendentals core leaves to a math library, the 3-component vector ops every layout and transform reaches for, and the quaternion / Euler convention rotations are authored and stepped in.
memory
The engine’s allocation layer: what the process is holding, who is holding it, and the allocators that hand memory out in bulk instead of one block at a time.
physics
The rigid-body simulation, and the driver that runs it over a world.
platform
The shader Platform selector: which shader source language the running backend consumes. Pure (no I/O, cfg-resolved), so it sits in the runtime foundation rather than the build module – the engine picks a Shader stage’s current-platform source at runtime, and the build pipeline reuses the same selection at compile time.
render
The backend-agnostic, GPU-free render-prep layer: the RenderBackend/SceneControl trait seam the device backends implement, plus the record builders, render graph, and CPU-side math that turn components into GPU-ready data.
resource
Runtime resource tables: per-kind, handle-indexed views of a compiled blob’s resource stream. A resource (an audio clip, a texture, a mesh, a material, …) is compiled by cook and addressed at runtime by its dense per-kind handle. The owning system reads the table by that handle instead of querying an ECS column or scanning names, so a resource lives in a table it owns rather than as a component. Renderer-free (the tables are plain handle-indexed data), so they live here where the physics / audio subsystem crates can reach them; the client re-exports them under crate::resource::*, alongside the engine-side install_resource_tables that inserts them as World resources.
result
The engine’s flat result code, shared by every crate that reports a recoverable failure across an API or FFI seam.
spawn
Runtime entity churn: instantiating a copy of an authored placement, and the two clocks that drive it.

Macros§

define_component_storage
Generate a component storage for a fixed set of component types: one Column<T> per type, the entity allocator, the shared change tick, the join index, and the slot access trait that resolves a type to its column at compile time.
define_components
Generate the runtime component registry from the engine’s component list: the ComponentTag discriminants, the ComponentAsset value enum, and the ComponentStorage / ComponentSlot pair the ECS stores rows in.
for_each_component
The one component list. $cb is a macro that receives the Variant => Type entries and expands to whatever registry it builds from them. Type paths are absolute so the list resolves from any crate that consumes it.
install_global_allocator
Install TrackingAlloc over the system allocator as this program’s #[global_allocator].

Structs§

App
A world and the headless loop that runs it.

Constants§

SCHEMA_VERSION
The version of everything a cooked blob’s bytes depend on: the postcard-visible component schema, the blob container’s record shapes, and the payload formats in build. Stamped into every blob header and folded into the cook’s payload cache key.