@voluma/vlam 0.2.4 → 0.3.0

package/README.md

@@ -31,7 +31,8 @@ npm install @voluma/vlam three
 
 ```ts
 import * as THREE from 'three/webgpu';
-import { SplatMesh, createSplatRenderer, loadScene } from '@voluma/vlam';
+import { SplatMesh, createSplatRenderer } from '@voluma/vlam';
+import { loadSplatData } from '@voluma/vlam/loaders';
 
 const renderer = await createSplatRenderer();
 renderer.setSize(innerWidth, innerHeight);
@@ -42,7 +43,7 @@ const camera = new THREE.PerspectiveCamera(60, innerWidth / innerHeight, 0.01, 1
 camera.position.set(1, 0.5, 1.4);
 camera.lookAt(0, 0, 0);
 
-const splats = new SplatMesh(await loadScene('/scene.sog'));
+const splats = new SplatMesh(await loadSplatData('/scene.sog'));
 scene.add(splats);
 
 renderer.setAnimationLoop(() => {

package/dist/budget-governor.d.ts

@@ -2,10 +2,10 @@
  * Shared splat-budget governance across multiple streamed meshes.
  *
  * A single `StreamedSplatMesh` keeps itself within a per-device budget, but a
- * host that shows several streamed scenes at once (a main capture plus marker
+ * host that shows several streamed scenes at once (a main capture plus additional
  * or inset meshes) must not let each mesh claim the whole device budget -
  * their pools are separate, so the costs add. Historically hosts hand-tuned
- * this ("shrink the main mesh to 0.7 when markers exist"); the
+ * this ("shrink the main mesh to 0.7 when additional meshes exist"); the
  * {@link BudgetGovernor} makes it a first-class policy: register each mesh
  * with a priority weight and the governor splits one total budget across the
  * members, reallocating when membership, weights, or the total change.
@@ -50,7 +50,7 @@ export interface BudgetGovernorOptions {
     /**
      * Grow dead-band as a fraction of a member's current budget (default
      * `0.1`). A reallocation that would *raise* a member's budget by no more
-     * than this fraction is skipped, so brief membership churn (a marker mesh
+     * than this fraction is skipped, so brief membership churn (an additional mesh
      * appearing for a moment) does not thrash LOD schedules. Shrinks always
      * apply immediately - that is what keeps `sum(member budgets) ≤ total` an
      * invariant rather than a goal.
@@ -98,7 +98,7 @@ export declare class BudgetGovernor {
      *
      * @param member - The mesh (or compatible object) to govern.
      * @param options - `weight` (default `1`): the member's share is
-     * proportional to its weight - e.g. main mesh `7`, marker `3` reproduces
+     * proportional to its weight - e.g. main mesh `7`, additional mesh `3` reproduces
      * the old 0.7 host split. `0` registers the member suspended.
      */
     register(member: BudgetGovernedMember, options?: {

package/dist/camera-budget-governor.d.ts

@@ -2,16 +2,16 @@
  * Camera-driven splat-budget weighting across several streamed meshes.
  *
  * {@link BudgetGovernor} splits one total by *priority*, which a host must
- * choose and maintain. That is the wrong axis for a scene of markers: what
- * makes a marker worth splats is that the camera is near it, and that changes
- * every frame. Splitting a pool evenly instead (`pool / N`) gives the marker
- * you fly up to a quarter of the budget it needs while three markers nobody is
+ * choose and maintain. That is the wrong axis for a scene of additional meshes:
+ * what makes a mesh worth splats is that the camera is near it, and that changes
+ * every frame. Splitting a pool evenly instead (`pool / N`) gives the mesh
+ * you fly up to a quarter of the budget it needs while three meshes nobody is
  * looking at hold the rest.
  *
  * {@link CameraBudgetGovernor} closes that loop: each update it measures every
  * member's projected size from the camera, multiplies in the host's priority
  * tier, and writes the resulting weights to a `BudgetGovernor` in one batch.
- * Approaching one of four markers pulls budget off the far ones automatically.
+ * Approaching one of four additional meshes pulls budget off the far ones automatically.
  *
  * This is Spark's model, reached differently. Spark shares one `lodSplatCount`
  * and biases meshes with a per-mesh `lodScale` (focused 2, adjacent 0.25,
@@ -53,7 +53,7 @@ export interface CameraBudgetMember extends BudgetGovernedMember {
     /**
      * The visibility that actually decides whether the member's splats reach the
      * screen, when that differs from `visible`. `SplatMesh` provides it: a
-     * `UnifiedSplatRenderer` forces `visible = false` on every source it owns
+     * `UnifiedSplatMesh` forces `visible = false` on every source it owns
      * (only to keep the regular scene draw from double-drawing them) while the
      * source may be fully on screen through the unified draw - without this, the
      * governor would suspend every unified source and freeze its streaming.
@@ -117,8 +117,8 @@ export interface CameraBudgetMemberOptions {
     /**
      * Pins this member's weight, opting it out of camera weighting while it still
      * competes for the same total. Use it for a main scene that should hold a
-     * steady share while markers fight over the rest - e.g. `fixedWeight: 4`
-     * against markers averaging `1`.
+     * steady share while additional meshes fight over the rest - e.g. `fixedWeight: 4`
+     * against extras averaging `1`.
      */
     fixedWeight?: number;
 }
@@ -129,8 +129,8 @@ export interface CameraBudgetMemberOptions {
  * ```js
  * const governor = new CameraBudgetGovernor({ totalBudget: 4_000_000 });
  * governor.register(main, { fixedWeight: 4 }); // steady share
- * governor.register(markerA); // camera-weighted, priority 1
- * governor.register(markerB);
+ * governor.register(extraA); // camera-weighted, priority 1
+ * governor.register(extraB);
  *
  * // once per frame, after the scene graph is up to date:
  * governor.update(camera);
@@ -142,7 +142,7 @@ export interface CameraBudgetMemberOptions {
  *
  * **A member can only grow into a budget its pool can hold.** A streamed mesh
  * allocates its pool once, from its construction budget, and clamps `setBudget`
- * to it - so a marker built at a quarter of the total can never be given more
+ * to it - so a mesh built at a quarter of the total can never be given more
  * than a quarter, however close the camera gets. Construct governed meshes with
  * `maxBudget` set to the largest share they should ever reach, and price those
  * ceilings with `estimateSplatPoolBytes` first: the pools cost their ceilings

package/dist/chunk-cache-budget.d.ts

@@ -2,9 +2,9 @@
  * Cross-mesh decoded-chunk cache arbitration.
  *
  * Every {@link StreamedSplatMesh} caps its own decoded-chunk cache, and in
- * `foveationMode: 'pagetable'` that cap is `min(2 GiB, this capture's decoded
- * size)` - a number sized for *one* streamed scene. A scene of streamed markers
- * therefore has no ceiling at all: thirteen markers plus a main are thirteen
+ * `foveationMode: 'page-table'` that cap is `min(2 GiB, this capture's decoded
+ * size)` - a number sized for *one* streamed scene. A scene of streamed additional meshes
+ * therefore has no ceiling at all: thirteen extras plus a main are thirteen
  * plus one independent caps, and because each is sized to its own capture, a
  * desktop that fits them never evicts. The background sweep then runs to
  * completion against every one of them, pulling every capture in the scene into
@@ -43,8 +43,8 @@ export interface ChunkCacheClient {
      *
      * Bytes above it are handed to siblings that can use them, the way
      * `BudgetGovernor` waterfills past a member's `maxBudget`. Without it a scene
-     * of one large capture and a dozen small markers would reserve most of the
-     * envelope for markers that cannot fill it.
+     * of one large capture and a dozen small additional meshes would reserve most of the
+     * envelope for extras that cannot fill it.
      */
     readonly ceilingBytes: number;
     /**

package/dist/chunk-fetch-scheduler.d.ts

@@ -3,7 +3,7 @@
  *
  * Every {@link StreamedSplatMesh} owns its own `ChunkLoader` worker and issues
  * chunk requests toward its own in-flight cap, so a scene of streamed meshes
- * fetches with no shared ordering: a marker the camera is pointed at competes
+ * fetches with no shared ordering: a mesh the camera is pointed at competes
  * for bandwidth and connection slots against a dozen distant ones, each of
  * which is equally entitled to its own cap. Spark does not have this problem
  * structurally - one global traversal orders every fetch want
@@ -81,7 +81,7 @@ export interface ChunkFetchSchedulerOptions {
      * Slots every registered mesh may hold regardless of weight. Default 1.
      *
      * Without a floor a scene's far meshes stop fetching entirely while the
-     * focused one streams, and a marker with no coarse coverage draws nothing -
+     * focused one streams, and a mesh with no coarse coverage draws nothing -
      * so the floor is what turns "far meshes wait" into "far meshes trickle".
      *
      * One slot is always granted regardless of this setting: a mesh entitled to
@@ -156,8 +156,8 @@ export declare class ChunkFetchScheduler {
      * asks - which is what keeps the first mesh to reschedule from taking the
      * pipe and holding it. Dividing the *remainder* after every participant's
      * floor instead would invert the whole point on a large scene: thirteen
-     * markers and a main at floor 1 consume a 16-slot pipe entirely, leaving the
-     * focused marker a smaller share than the far ones it is competing with.
+     * additional meshes and a main at floor 1 consume a 16-slot pipe entirely, leaving the
+     * focused mesh a smaller share than the far ones it is competing with.
      *
      * The denominator counts every mesh that plausibly wants the pipe - all
      * registered meshes except those both weightless and idle, plus the caller.