Rapier-Weltlebenszyklus

Rapier — world lifecycle

Use when creating Rapier worlds, wrappers, colliders, rigid bodies or teardown paths.

Version and project gate

Inspect Rust crate features or JS/WASM package and version, 2D/3D choice, framework wrapper version, units, solver settings, timestep ownership, body/collider handles and render synchronization. Determinism depends on binding, version, initialization and operation order. Never turn a task into an engine upgrade without the user’s intent. Read the version-matching official reference when an API decision depends on it.

Work

Record the exact binding and wrapper before choosing APIs. Establish one owner for world stepping and body/collider creation/removal. Map stable game identifiers to handles without persisting raw handles across world reconstruction. Define cascading removal and snapshot ownership.

Deliver

A physics ownership/handle map and a complete spawn-to-removal integration. Keep the change in the existing project structure; separate actual observations from the proposed acceptance scenario below.

Failure to prevent

A removed or restored-world handle may no longer identify the same object; wrappers can own their own lifecycle.

Acceptance scenario

Destroy a body with colliders and joints, reuse a game entity ID and rebuild the world without stale handle access. Follow the project’s execution and verification permissions. If execution or a target device is unavailable, provide the reproduction steps and name the remaining uncertainty; do not mark it passed.

Scope and sources

This skill belongs to Vector. Agent selection is restricted by Orqestria’s assigned-agent policy, including forced skill selection; instruction text alone is not an access control. These are original task workflows researched from official documentation, not a copied or endorsed vendor skill.

• https://rapier.rs/docs/
• https://www.rapier.rs/docs/user_guides/javascript/determinism/
• https://rapier.rs/docs/user_guides/javascript/character_controller/