@woosh/meep-engine 2.139.0 → 2.140.0

package/src/engine/control/first-person/TODO.md

@@ -1,127 +1,173 @@
-# First-person controller — TODO
-
-Working notes. Things we've identified as worth doing but haven't pulled
-the trigger on yet. Companion to DESIGN.md (base) and DESIGN_EXTENSIONS.md
-(abilities + mastery roadmap).
-
-## Mastery evaluators — additional
-
-We ship StrideTimingJump, FootAsymmetryTurn, BreathRhythm, and
-SlideInitiationTiming today. The remaining ones from the
-DESIGN_EXTENSIONS Phase 10 list, ordered by what would give the most
-texture per unit of work:
-
-### WallRunEntryTimingEvaluator
-Decision point: `WallRunGravity` (currently un-wired — Wall-run reads
-`cfg.wallRun.gravityFactor` straight, no mastery hook). Wire it.
-
-Input: angle-of-attack against the wall at activation. Lower angle of
-attack (entering near-parallel) is the canonical "good" entry — converts
-forward momentum into the run smoothly. High angle of attack (entering
-near-perpendicular) is "bad" — you're crashing into the wall.
-
-Curve shape: peak at small angle (1.0 → 0.8, less effective gravity =
-more hang time); penalty at high angle (1.0 → 1.15, gravity ramped =
-shorter run). Symmetric in behaviour, asymmetric in magnitude.
-
-Estimated effort: 0.5 day. Capture entry angle in WallRun.onActivate,
-stash it on the evaluator's per-instance state OR on a new
-`runtime.wallRunEntryAngle` field. Curve + spec.
-
-### WallRunTakeoffTimingEvaluator
-Decision point: `WallJumpImpulse` (already wired — base WallJump runs
-mastery on it).
-
-Input: how late in the wall-run the wall-jump is fired. Late in the
-run (near the timer expiry) is the "explosive last-second push-off"
-— bonus. Right at activation is "panicked early jump" — penalty.
-
-Curve shape: time-based, normalized to [0, 1] over wall-run duration.
-Peak at 0.6–0.9 (committed but not desperate). Trough near 0.0
-(panicked).
-
-Estimated effort: 0.5 day. WallJump needs to read how long WallRun was
-active when it preempted. Simplest: track `runtime.wallRunElapsedAt
-Takeoff` in WallRun.onDeactivate (or via a signal).
-
-### WallJumpEntryAngleEvaluator
-Decision point: `WallJumpImpulse`.
-
-Input: angle between the player's velocity vector and the wall normal
-at the moment of jump press. A near-perpendicular push-off (velocity
-along normal at impact) converts the most into the impulse — bonus.
-A near-tangent push (sliding along) is "weak push-off" — penalty.
-
-Curve shape: peak at dot(velocity, normal) approaching 1.0 (head-on);
-penalty near 0 (parallel skim).
-
-Composes multiplicatively with the takeoff-timing evaluator above —
-both fire on `WallJumpImpulse`. That's the point of the multiplicative
-composition rule.
-
-Estimated effort: 0.5 day.
-
-### LedgeCatchTimingEvaluator
-Decision point: NEW — would need `LedgeCatchExertionScale` or similar.
-Currently LedgeGrab uses a flat `cfg.ledgeGrab.exertionRiseRate`.
-
-Input: |velocityY| at the moment of catch. A gentle catch (low vy) is
-forgiving — low exertion rise (longer hang). A desperate save (high
-|vy|) is harder — higher exertion rise (shorter hang).
-
-Curve shape: identity 1.0 at low |vy| (≤ 2 m/s), ramping up to ~1.5×
-at high |vy| (≥ 8 m/s).
-
-Estimated effort: 0.5 day, plus adding the new decision point.
-
-### MantleExitSpeedEvaluator
-Decision point: `MantleExitSpeed` (currently un-wired).
-
-Input: stride-phase at the moment of mantle completion. Landing on a
-midstance push-off bonus the exit velocity (player runs off the mantle
-into the next surface); landing on footfall takes a small penalty.
-
-Currently Mantle's exit doesn't set any forward velocity — the player
-lands at rest. To make this evaluator meaningful, we'd also need
-Mantle to apply a small forward push on completion, which the
-evaluator then scales. Two-step change.
-
-Estimated effort: 1 day (more wiring than the others).
-
-## Other open notes
-
-### Refactor `pose.crouchAmount` away
-Now redundant with `pose.postureAmount`. Leave for one or two builds so
-any external consumers can migrate, then delete.
-
-### Stride-mastery score telemetry
-`MasterySet` records EMA scores per decision point. We never surface
-these to the HUD or any feedback system. A simple debug overlay
-showing the running scores (a sparkline per decision point?) would be
-helpful when tuning curves.
-
-### Tune the slide bob fade-out
-`bobIntensityHalfLife` controls how fast the lateral bob fades when
-posture changes to Prone. May be too slow — feels like a brief wobble
-before the slide settles into "pure motion". Worth play-test tuning.
-
-### Posture-aware footstep audio
-Surface tag is on `state.surfaceTag`. The footstep signal carries
-side + speed + surfaceTag, but emission is gated on
-`feetStriking` (Stand or Crouch posture). When other postures want
-audio cues (a slide-along-pavement sound, a hang-grip creak), they
-need their own signal channels — not piggyback on `onFootStep`.
-
-### WallRun direction sense (push-back behaviour)
-Currently WallRun projects velocity onto the wall tangent each tick.
-If the player turns AWAY from the wall mid-run, the wall-tangent
-projection still keeps them pinned. Might want a "lean-away exits the
-run" condition: if `intent.move` rotates more than X degrees from the
-wall tangent, exit the wall-run.
-
-### Animation track for Hang posture
-The eye stays at body height while hanging (we don't drop the eye
-height in Hang because the body root is already below the ledge). But
-the rig should probably show arms reaching up. That's a skeleton
-concern, not a controller one — just flagging that `pose.posture =
-Hang` is the signal the rig should branch on.
+# First-person controller — TODO
+
+Working notes. Things we've identified as worth doing but haven't pulled
+the trigger on yet. Companion to DESIGN.md (base) and DESIGN_EXTENSIONS.md
+(abilities + mastery roadmap).
+
+## Mastery evaluators — additional
+
+We ship StrideTimingJump, FootAsymmetryTurn, BreathRhythm, and
+SlideInitiationTiming today. The remaining ones from the
+DESIGN_EXTENSIONS Phase 10 list, ordered by what would give the most
+texture per unit of work:
+
+### WallRunEntryTimingEvaluator
+Decision point: `WallRunGravity` (currently un-wired — Wall-run reads
+`cfg.wallRun.gravityFactor` straight, no mastery hook). Wire it.
+
+Input: angle-of-attack against the wall at activation. Lower angle of
+attack (entering near-parallel) is the canonical "good" entry — converts
+forward momentum into the run smoothly. High angle of attack (entering
+near-perpendicular) is "bad" — you're crashing into the wall.
+
+Curve shape: peak at small angle (1.0 → 0.8, less effective gravity =
+more hang time); penalty at high angle (1.0 → 1.15, gravity ramped =
+shorter run). Symmetric in behaviour, asymmetric in magnitude.
+
+Estimated effort: 0.5 day. Capture entry angle in WallRun.onActivate,
+stash it on the evaluator's per-instance state OR on a new
+`runtime.wallRunEntryAngle` field. Curve + spec.
+
+### WallRunTakeoffTimingEvaluator
+Decision point: `WallJumpImpulse` (already wired — base WallJump runs
+mastery on it).
+
+Input: how late in the wall-run the wall-jump is fired. Late in the
+run (near the timer expiry) is the "explosive last-second push-off"
+— bonus. Right at activation is "panicked early jump" — penalty.
+
+Curve shape: time-based, normalized to [0, 1] over wall-run duration.
+Peak at 0.6–0.9 (committed but not desperate). Trough near 0.0
+(panicked).
+
+Estimated effort: 0.5 day. WallJump needs to read how long WallRun was
+active when it preempted. Simplest: track `runtime.wallRunElapsedAt
+Takeoff` in WallRun.onDeactivate (or via a signal).
+
+### WallJumpEntryAngleEvaluator
+Decision point: `WallJumpImpulse`.
+
+Input: angle between the player's velocity vector and the wall normal
+at the moment of jump press. A near-perpendicular push-off (velocity
+along normal at impact) converts the most into the impulse — bonus.
+A near-tangent push (sliding along) is "weak push-off" — penalty.
+
+Curve shape: peak at dot(velocity, normal) approaching 1.0 (head-on);
+penalty near 0 (parallel skim).
+
+Composes multiplicatively with the takeoff-timing evaluator above —
+both fire on `WallJumpImpulse`. That's the point of the multiplicative
+composition rule.
+
+Estimated effort: 0.5 day.
+
+### LedgeCatchTimingEvaluator
+Decision point: NEW — would need `LedgeCatchExertionScale` or similar.
+Currently LedgeGrab uses a flat `cfg.ledgeGrab.exertionRiseRate`.
+
+Input: |velocityY| at the moment of catch. A gentle catch (low vy) is
+forgiving — low exertion rise (longer hang). A desperate save (high
+|vy|) is harder — higher exertion rise (shorter hang).
+
+Curve shape: identity 1.0 at low |vy| (≤ 2 m/s), ramping up to ~1.5×
+at high |vy| (≥ 8 m/s).
+
+Estimated effort: 0.5 day, plus adding the new decision point.
+
+### MantleExitSpeedEvaluator
+Decision point: `MantleExitSpeed` (currently un-wired).
+
+Input: stride-phase at the moment of mantle completion. Landing on a
+midstance push-off bonus the exit velocity (player runs off the mantle
+into the next surface); landing on footfall takes a small penalty.
+
+Currently Mantle's exit doesn't set any forward velocity — the player
+lands at rest. To make this evaluator meaningful, we'd also need
+Mantle to apply a small forward push on completion, which the
+evaluator then scales. Two-step change.
+
+Estimated effort: 1 day (more wiring than the others).
+
+## Move-and-slide follow-ups
+
+### Slide along non-axis-aligned walls
+**Landed.** `PhysicsSystem.shapeCast` now writes the true contact
+normal (narrowphase-refined via GJK + EPA at TOI), and `_moveAndSlide`
+uses the canonical iterative slide: stop at first contact, project the
+residual onto the contact tangent, sweep again, repeat up to 4 times.
+Multi-contact corners stop cleanly; diagonal approaches slide along
+both axis-aligned and oblique surfaces.
+
+### Vertical sweep (anti-tunnel for floors and ceilings)
+`_moveAndSlide` is currently called for horizontal motion only. The
+vertical phase still does a direct position add. For fast falls past
+the ground-resolver's 0.1 m raycast lift, the player can sink through
+the floor in one tick; for vertical wall-jumps into a ceiling, no
+contact is detected.
+
+Wiring a vertical sweep into `_integrateVerticalAndResolveGround`
+needs to be coordinated with the SKIN clearance — landing at
+`floor + SKIN` would re-flag the player as airborne by the resolver,
+which would re-apply gravity and bounce. Either drop SKIN on
+floor-normal contacts, or have the resolver use a tolerance instead
+of strict `position.y <= testY`.
+
+### Ability motion routing
+Slide and WallRun integrate position manually (slide friction in the
+ability tick; wall-run reduced-gravity integration). Once the slide-
+along-walls work above lands, threading those through `_moveAndSlide`
+would prevent wall-runners from drifting into the wall and sliders
+from penetrating obstacles in their path. The controller-side change
+is a few lines per ability; the gating issue is having a usable
+surface normal.
+
+## Other open notes
+
+### Horizontal-capsule Prone collider
+The posture → collider sync uses a vertical capsule for Prone, sized
+to `cfg.body.proneHeight`. When that's below `2·radius` (the default)
+the capsule degenerates to a sphere of `radius` — Y extent
+`2·radius ≈ 0.68 m`. That fits "low-profile shape" honestly but it
+doesn't reflect what a sliding body actually looks like: long along
+the direction of travel, narrow in the cross-section. A horizontal
+capsule (Y-axis cylinder rotated 90° around X via TransformedShape3D
+matrix, oriented along body-local +Z) would let the player fit
+under 0.4-m ledges while still occupying the full body length
+horizontally. Tracked because the Prone test currently asserts the
+vertical-capsule extent — see PostureCollider.spec.js geometry note.
+
+### Refactor `pose.crouchAmount` away
+Now redundant with `pose.postureAmount`. Leave for one or two builds so
+any external consumers can migrate, then delete.
+
+### Stride-mastery score telemetry
+`MasterySet` records EMA scores per decision point. We never surface
+these to the HUD or any feedback system. A simple debug overlay
+showing the running scores (a sparkline per decision point?) would be
+helpful when tuning curves.
+
+### Tune the slide bob fade-out
+`bobIntensityHalfLife` controls how fast the lateral bob fades when
+posture changes to Prone. May be too slow — feels like a brief wobble
+before the slide settles into "pure motion". Worth play-test tuning.
+
+### Posture-aware footstep audio
+Surface tag is on `state.surfaceTag`. The footstep signal carries
+side + speed + surfaceTag, but emission is gated on
+`feetStriking` (Stand or Crouch posture). When other postures want
+audio cues (a slide-along-pavement sound, a hang-grip creak), they
+need their own signal channels — not piggyback on `onFootStep`.
+
+### WallRun direction sense (push-back behaviour)
+Currently WallRun projects velocity onto the wall tangent each tick.
+If the player turns AWAY from the wall mid-run, the wall-tangent
+projection still keeps them pinned. Might want a "lean-away exits the
+run" condition: if `intent.move` rotates more than X degrees from the
+wall tangent, exit the wall-run.
+
+### Animation track for Hang posture
+The eye stays at body height while hanging (we don't drop the eye
+height in Hang because the body root is already below the ledge). But
+the rig should probably show arms reaching up. That's a skeleton
+concern, not a controller one — just flagging that `pose.posture =
+Hang` is the signal the rig should branch on.

package/src/engine/control/first-person/abilities/Slide.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"Slide.d.ts","sourceRoot":"","sources":["../../../../../../src/engine/control/first-person/abilities/Slide.js"],"names":[],"mappings":"AAKA;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH;IAOQ,gEAAgE;IAChE,0BAA0B;IAG9B,mEAeC;IAED,gDAuBC;IAED,uDAGC;IAED,uFAmEC;IAED,oDAEC;CACJ;wBA1JuB,cAAc"}
+{"version":3,"file":"Slide.d.ts","sourceRoot":"","sources":["../../../../../../src/engine/control/first-person/abilities/Slide.js"],"names":[],"mappings":"AAKA;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH;IAOQ,gEAAgE;IAChE,0BAA0B;IAG9B,mEAuBC;IAED,gDAuBC;IAED,uDAGC;IAED,uFAmEC;IAED,oDAEC;CACJ;wBAlKuB,cAAc"}

package/src/engine/control/first-person/abilities/Slide.js

@@ -47,7 +47,15 @@ export class Slide extends Ability {
         // simply by holding crouch and walking up to sprint speed.)
         if (runtime.prevCrouchHeld) return false;
         // Need significant horizontal speed — slide is a run-into-slide,
-        // not a standstill-into-slide.
+        // not a standstill-into-slide. The mono-exponential ground
+        // accel model (see FirstPersonPlayerControllerConfig.js's
+        // `groundAccelHalfLife`) ensures reaching this threshold from
+        // standstill naturally requires ~300 ms of committed sprint —
+        // longer than human reaction time — so the speed gate alone is
+        // enough to make slide feel earned. Speed-only is also the
+        // right model for the cases the design wants to explicitly
+        // allow: walking off a ledge or accelerating down a slope into
+        // a slide. (Following Apex Legends' velocity-only gate.)
         const speed = Math.hypot(runtime.velocityX, runtime.velocityZ);
         if (speed < cfg.minEntrySpeed) return false;
         return true;

package/src/engine/control/first-person/prototype_first_person_controller.js

@@ -1,7 +1,9 @@
-import { BoxGeometry, MeshStandardMaterial } from "three";
+import { BoxGeometry, MeshStandardMaterial, TorusKnotGeometry } from "three";
 import { Ray3 } from "../../../core/geom/3d/ray/Ray3.js";
 import { BoxShape3D } from "../../../core/geom/3d/shape/BoxShape3D.js";
 import { CapsuleShape3D } from "../../../core/geom/3d/shape/CapsuleShape3D.js";
+import { TransformedShape3D } from "../../../core/geom/3d/shape/TransformedShape3D.js";
+import { shape_mesh_from_geometry } from "../../../core/geom/3d/shape/shape_mesh_from_geometry.js";
 import Vector2 from "../../../core/geom/Vector2.js";
 import Vector3 from "../../../core/geom/Vector3.js";
 import { SerializationMetadata } from "../../ecs/components/SerializationMetadata.js";
@@ -217,6 +219,80 @@ function buildGym(ecd) {
     buildLedgeGrabStation(ecd);
     buildSlideTunnel(ecd);
     buildGapJumpStation(ecd);
+    buildMeshShapeShowcase(ecd);
+}
+
+/**
+ * Drop a torus-knot prop off to the side as a smoke test for
+ * {@link MeshShape3D}: arbitrary indexed triangle mesh → tetrahedralised
+ * collider via {@link shape_mesh_from_geometry}.
+ *
+ * Dynamic body, so the player capsule (kinematic) can bump it around.
+ * KinematicPosition bodies don't receive impulses themselves (the
+ * controller writes the Transform), so a static knot vs. kinematic
+ * capsule produces zero solver response and the capsule clips through.
+ * Making the knot dynamic flips the relationship: when the capsule
+ * penetrates, the solver applies impulse to the knot — it bounces away
+ * and the player gets a visible reaction.
+ *
+ * Placed off the spawn plaza's main travel path (radius 18 north-east of
+ * spawn) so it's visible but not in the way of the parkour drills.
+ */
+function buildMeshShapeShowcase(ecd) {
+    // TorusKnotGeometry (radius, tube, tubularSegments, radialSegments).
+    // 64 × 8 = 512 segments → ~512 verts / ~1024 tris — plenty of detail
+    // for visual interest, light enough that the per-vertex `support()`
+    // scan stays fast.
+    const geom = new TorusKnotGeometry(0.5, 0.15, 64, 8);
+    geom.computeVertexNormals();
+
+    // Three packs positions as Float32Array (interleaved x, y, z) and
+    // indices as Uint16Array by default. The MeshShape3D factory wants
+    // a Uint32Array index buffer — convert once at construction.
+    const positions = geom.attributes.position.array;
+    const src_indices = geom.index.array;
+    const indices = src_indices instanceof Uint32Array
+        ? src_indices
+        : Uint32Array.from(src_indices);
+
+    const shape = shape_mesh_from_geometry(positions, indices);
+
+    const material = new MeshStandardMaterial({ color: 0xffaa66, roughness: 0.5 });
+    const sg = ShadedGeometry.from(geom, material);
+    sg.setFlag(ShadedGeometryFlags.CastShadow);
+    sg.setFlag(ShadedGeometryFlags.ReceiveShadow);
+    sg.setFlag(ShadedGeometryFlags.Visible);
+
+    const transform = new Transform();
+    // North-east of spawn, lifted ~2m off the ground so the knot drops
+    // onto the floor when the sim starts and the player can walk over,
+    // bump it, and watch it tumble.
+    transform.position.set(SPAWN_X + 18, 2, SPAWN_Z - 18);
+
+    const rigidBody = new RigidBody();
+    rigidBody.kind = BodyKind.Dynamic;
+    rigidBody.mass = 1;
+    // Bounding radius ≈ main_radius + tube_radius = 0.65. For a chunky
+    // bumpable body matching the existing 1m cube reference, use the
+    // same `(6, 6, 6)` inverse inertia — it's slightly under-rotational
+    // for the torus knot's mass distribution but reads as solid.
+    rigidBody.inverseInertiaLocal.set(6, 6, 6);
+    rigidBody.linearDamping = 0.5;
+    rigidBody.angularDamping = 0.5;
+
+    const collider = new Collider();
+    collider.shape = shape;
+    collider.friction = 0.5;
+    collider.restitution = 0.2;
+
+    new Entity()
+        .add(sg)
+        .add(rigidBody)
+        .add(collider)
+        .add(transform)
+        .add(Tag.fromJSON(["GymObstacle"]))
+        .add(SerializationMetadata.Transient)
+        .build(ecd);
 }
 
 /**
@@ -612,7 +688,17 @@ function buildPlayerEntity(ecd) {
     rigidBody.kind = BodyKind.KinematicPosition;
     rigidBody.mass = bodyCfg.mass;
     const collider = new Collider();
-    collider.shape = CapsuleShape3D.from(radius, cylinderHeight);
+    // Capsule lives in [feet .. head] in world space. CapsuleShape3D is
+    // centred at its local origin, so wrap it in a TransformedShape3D
+    // with a +Y translation of totalHeight/2 — that puts the capsule
+    // bottom at the player's feet (Transform.position) and the top at
+    // the head. Without this, shape_cast queries against the ground
+    // would stop the capsule centre at floor + half-extent, leaving
+    // the player visibly floating half a body height above the floor.
+    collider.shape = TransformedShape3D.from_translation(
+        CapsuleShape3D.from(radius, cylinderHeight),
+        [0, totalHeight / 2, 0],
+    );
 
     // Build order matters: Transform is added LAST so the FirstPerson
     // controller system's link() sees the RigidBody already attached.

package/src/engine/control/first-person/test/buildTestPlayer.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"buildTestPlayer.d.ts","sourceRoot":"","sources":["../../../../../../src/engine/control/first-person/test/buildTestPlayer.js"],"names":[],"mappings":"AAKA;;;;;;;;;;;;GAYG;AACH;eAF0B,SAAS;cAAY,QAAQ;EAWtD;0BAxByB,mCAAmC;yBADpC,kCAAkC"}
+{"version":3,"file":"buildTestPlayer.d.ts","sourceRoot":"","sources":["../../../../../../src/engine/control/first-person/test/buildTestPlayer.js"],"names":[],"mappings":"AAMA;;;;;;;;;;;;GAYG;AACH;eAF0B,SAAS;cAAY,QAAQ;EAkBtD;0BA/ByB,mCAAmC;yBADpC,kCAAkC"}

package/src/engine/control/first-person/test/buildTestPlayer.js

@@ -1,4 +1,5 @@
 import { CapsuleShape3D } from "../../../../core/geom/3d/shape/CapsuleShape3D.js";
+import { TransformedShape3D } from "../../../../core/geom/3d/shape/TransformedShape3D.js";
 import { BodyKind } from "../../../physics/ecs/BodyKind.js";
 import { Collider } from "../../../physics/ecs/Collider.js";
 import { RigidBody } from "../../../physics/ecs/RigidBody.js";
@@ -22,7 +23,14 @@ export function buildTestPlayerBody() {
     rigidBody.mass = 1;
 
     const collider = new Collider();
-    collider.shape = CapsuleShape3D.from(0.34, 1.12);
+    // Capsule lives in [feet .. head] in world space — see the prototype's
+    // buildPlayerEntity for the rationale. Wrap the centred CapsuleShape3D
+    // in a TransformedShape3D with a +Y offset of half the body height
+    // (1.8 / 2 = 0.9), matching prototype geometry.
+    collider.shape = TransformedShape3D.from_translation(
+        CapsuleShape3D.from(0.34, 1.12),
+        [0, 0.9, 0],
+    );
 
     return { rigidBody, collider };
 }

package/src/engine/graphics/geometry/CapsuleGeometry.d.ts

@@ -0,0 +1,42 @@
+/**
+ * A capsule aligned with the Y axis, built as a single continuous surface of
+ * revolution: a top hemispherical cap, a cylindrical mid-section and a bottom
+ * hemispherical cap.
+ *
+ * Dimensions follow the {@link CapsuleShape3D} convention:
+ *   - `radius` is the radius of both the caps and the cylindrical section.
+ *   - `height` is the length of the cylindrical section ONLY (the caps are
+ *     added on top of it), so the total extent along Y is `height + 2 * radius`,
+ *     spanning `[-(height/2 + radius), +(height/2 + radius)]`, centred at the
+ *     origin.
+ *
+ * Two further parameters control tessellation:
+ *   - `capSegments` rings per hemispherical cap (from equator to pole).
+ *   - `radialSegments` segments around the Y axis.
+ *
+ * Watertightness: the mesh is emitted as one grid of vertex rings running from
+ * the top pole down to the bottom pole. Consecutive rings — including the
+ * top-equator -> bottom-equator ring that spans the cylinder — are stitched
+ * sharing their ring vertices, so there is never a gap between the caps and the
+ * body. The angular seam is duplicated only for UV continuity (the duplicate
+ * sits at the same position) and each pole is a proper triangle fan, so welding
+ * vertices by position yields a closed, consistently oriented 2-manifold.
+ */
+export class CapsuleGeometry extends BufferGeometry {
+    static fromJSON(data: any): CapsuleGeometry;
+    /**
+     * @param {number} [radius=0.5] radius of the caps and the cylindrical section
+     * @param {number} [height=1] length of the cylindrical section, excluding the caps
+     * @param {number} [capSegments=8] number of rings in each hemispherical cap
+     * @param {number} [radialSegments=16] number of segments around the Y axis
+     */
+    constructor(radius?: number, height?: number, capSegments?: number, radialSegments?: number);
+    parameters: {
+        radius: number;
+        height: number;
+        capSegments: number;
+        radialSegments: number;
+    };
+}
+import { BufferGeometry } from "three";
+//# sourceMappingURL=CapsuleGeometry.d.ts.map

package/src/engine/graphics/geometry/CapsuleGeometry.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"CapsuleGeometry.d.ts","sourceRoot":"","sources":["../../../../../src/engine/graphics/geometry/CapsuleGeometry.js"],"names":[],"mappings":"AAEA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH;IA6II,4CAEC;IA9ID;;;;;OAKG;IACH,qBALW,MAAM,WACN,MAAM,gBACN,MAAM,mBACN,MAAM,EAsIhB;IA/HG;;;;;MAKC;CA+HR;+BA1K+D,OAAO"}