@woosh/meep-engine 3.15.0 → 3.16.0

package/src/shade/renderer/particles/graph/ParticleValueType.d.ts

@@ -0,0 +1,188 @@
+/**
+ * The semantic type of this name, or `null` for a name that is not one.
+ *
+ * How a tag written somewhere else — an attribute in a
+ * {@link ../layout/ParticleLayout.js ParticleLayout}, most of all — becomes a type. An unknown name
+ * is not an error here: the caller knows the shape regardless, and falling back to it leaves an
+ * effect that names a semantic this build has never heard of working as the plain vector it is.
+ *
+ * @param {*} name
+ * @returns {ParticleValueType|null}
+ */
+export function particle_semantic_type(name: any): ParticleValueType | null;
+/**
+ * The type of a value `components` lanes wide.
+ *
+ * Always a plain shape: a width says how many lanes there are and nothing about what they are for,
+ * so a semantic type is only ever arrived at by name.
+ *
+ * @param {number} components
+ * @returns {ParticleValueType}
+ * @throws if there is no such width
+ */
+export function particle_value_type(components: number): ParticleValueType;
+/**
+ * The type of a value `components` lanes wide, or `null` where that is not a width a value can
+ * have — which is how a node whose parameters do not describe a type says so without throwing in
+ * the middle of an editor.
+ *
+ * @param {*} components
+ * @returns {ParticleValueType|null}
+ */
+export function particle_value_type_or_null(components: any): ParticleValueType | null;
+/**
+ * The widest of some types, ignoring the unknown ones; `null` when none is known.
+ *
+ * This is the rule every element-wise operation types itself by: the result is as wide as its
+ * widest operand, and every operand is read at that width. Among types of equal width the one that
+ * means something wins, so a colour times a number is a colour, and a colour added to a plain
+ * `vec4` comes out a colour whichever side it was on. Between two that both mean something, the
+ * first arrival wins — there is no ordering over meanings, and the alternative is refusing to type
+ * a graph that is arithmetically fine.
+ *
+ * @param {Iterable<ParticleValueType|null|undefined>} types
+ * @returns {ParticleValueType|null}
+ */
+export function particle_widest_type(types: Iterable<ParticleValueType | null | undefined>): ParticleValueType | null;
+/**
+ * What it means to read a value of one type as another, said the way a person would want to hear
+ * it — or `null` where nothing is read differently: an exact read, a broadcast, or a change of
+ * meaning between two types of one shape.
+ *
+ * @param {ParticleValueType} from the value's own type
+ * @param {ParticleValueType} to the type it is read as
+ * @returns {{dropped?: string, zeroed?: string, message: string}|null} the lanes concerned, and
+ *   one sentence about them
+ */
+export function particle_type_conversion(from: ParticleValueType, to: ParticleValueType): {
+    dropped?: string;
+    zeroed?: string;
+    message: string;
+};
+/**
+ * The types a value in a particle graph can have: a float vector of one to four lanes, and the
+ * types that say what such a vector *means*.
+ *
+ * The VM has always run its instructions at a width, so the values have always had one; what a
+ * graph could not do until now was *say* it. Every port was declared `vec4`, which made a delta
+ * time read as four lanes and left `add` unable to tell an author what it was adding. These are the
+ * types {@link ./infer_particle_graph_types.js} resolves over a graph, and they are what a view
+ * shows on a port and colours a wire by.
+ *
+ * ## Shape and meaning
+ *
+ * `components` is the type's shape, and shape is all the arithmetic cares about: a `vec3` is three
+ * lanes whatever it holds. The name and id are its identity, which is what a person cares about.
+ *
+ * Keeping the two apart is what lets a type say what a value means without changing how it is
+ * computed. {@link PARTICLE_TYPE_COLOR} is the first: it is a `vec4` to every instruction the
+ * compiler emits, and a colour to the author — a swatch to edit, its own colour on the wire, and a
+ * name on the port that says what the four lanes are for. The rules in
+ * {@link ./ParticleNodeRegistry.js} compare shapes, never identities, so a colour goes wherever a
+ * `vec4` goes and a `vec4` goes wherever a colour is wanted, with nothing to convert either way.
+ *
+ * Where two types of the same width meet, the one that means something wins — see
+ * {@link particle_widest_type} — so a colour scaled by a number, or mixed with a plain `vec4`, is
+ * still a colour on the far side. That is the whole of the sugar: the meaning survives the
+ * arithmetic instead of being lost at the first operation.
+ *
+ * ## Conversions
+ *
+ * Where a value meets a port that reads it as a different shape, {@link particle_type_conversion}
+ * says what happens. A scalar into a vector slot broadcasts, as it does in every shading language,
+ * and silently. A vector read narrower keeps its leading lanes; read wider, the missing lanes read
+ * zero. Both of those are how the four-lane register file always behaved, so a graph written before
+ * types compiles to the same lanes it did — but each is now a warning naming the lanes concerned,
+ * because a `vec4` literal feeding a three-component attribute is either a mistake or a literal
+ * that ought to be a `vec3`.
+ *
+ * Types of the same width never convert, whatever they mean, so nothing is said about a colour
+ * meeting a `vec4`. A view still draws the two in their own colours, which is worth seeing — it is
+ * where a raw vector is being used as a colour, or a colour as raw arithmetic — but it is a change
+ * of meaning and not of lanes, and no instruction is emitted for it.
+ *
+ * ## Ids
+ *
+ * A type's id is what a {@link NodeGraphVisualData} colours by and what the node registry indexes,
+ * so these are fixed rather than taken from a counter: id 0 is the declared type of every port
+ * ({@link ./ParticleNodeRegistry.js PARTICLE_VALUE_TYPE}), the plain shapes take their lane count
+ * as their id, and the types that carry a meaning are numbered from {@link PARTICLE_SEMANTIC_ID_BASE}
+ * upward.
+ */
+export class ParticleValueType extends DataType {
+    /**
+     * @param {number} id
+     * @param {string} name
+     * @param {number} components
+     * @param {object} [options]
+     * @param {boolean} [options.semantic] see {@link #semantic}
+     * @returns {ParticleValueType}
+     */
+    static from(id: number, name: string, components: number, { semantic }?: {
+        semantic?: boolean;
+    }): ParticleValueType;
+    /**
+     * How many lanes a value of this type occupies, `1..4`.
+     * @type {number}
+     */
+    components: number;
+    /**
+     * Whether this type says what a value *means* on top of how wide it is.
+     *
+     * A plain shape (`f32`, `vec3`) says only how many lanes there are. A semantic type says what
+     * they are for, and is what survives when the two meet — see {@link particle_widest_type}.
+     *
+     * @type {boolean}
+     */
+    semantic: boolean;
+    /**
+     * @returns {boolean}
+     */
+    get is_scalar(): boolean;
+    /**
+     * @readonly
+     * @type {boolean}
+     */
+    readonly isParticleValueType: boolean;
+}
+/** @type {ParticleValueType} */
+export const PARTICLE_TYPE_F32: ParticleValueType;
+/** @type {ParticleValueType} */
+export const PARTICLE_TYPE_VEC2: ParticleValueType;
+/** @type {ParticleValueType} */
+export const PARTICLE_TYPE_VEC3: ParticleValueType;
+/** @type {ParticleValueType} */
+export const PARTICLE_TYPE_VEC4: ParticleValueType;
+/**
+ * Where the ids of the types that carry a meaning start, above the four the lane counts claim.
+ * @type {number}
+ */
+export const PARTICLE_SEMANTIC_ID_BASE: number;
+/**
+ * Four lanes that are a colour: red, green, blue and alpha, in that order.
+ *
+ * A `vec4` in every respect the compiler cares about — it lowers to the same instructions, goes
+ * into any `vec4` slot and takes any `vec4` — and a colour in every respect an author does: a
+ * swatch to edit rather than four numbers, and a colour of its own on the wire, so the path from
+ * where a colour is made to where it is written is visible in a graph full of vectors.
+ *
+ * @type {ParticleValueType}
+ */
+export const PARTICLE_TYPE_COLOR: ParticleValueType;
+/**
+ * The plain shapes, narrowest first. Indexed by lane count, see {@link particle_value_type}.
+ * @type {ReadonlyArray<ParticleValueType>}
+ */
+export const PARTICLE_VALUE_TYPES: ReadonlyArray<ParticleValueType>;
+/**
+ * The types that say what a value means, in id order.
+ * @type {ReadonlyArray<ParticleValueType>}
+ */
+export const PARTICLE_SEMANTIC_TYPES: ReadonlyArray<ParticleValueType>;
+/**
+ * Every type a value can have. What a registry registers and a palette of wire colours covers.
+ * @type {ReadonlyArray<ParticleValueType>}
+ */
+export const PARTICLE_ALL_VALUE_TYPES: ReadonlyArray<ParticleValueType>;
+import { DataType } from "../../../../core/model/node-graph/type/DataType.js";
+//# sourceMappingURL=ParticleValueType.d.ts.map

package/src/shade/renderer/particles/graph/ParticleValueType.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"ParticleValueType.d.ts","sourceRoot":"","sources":["../../../../../../src/shade/renderer/particles/graph/ParticleValueType.js"],"names":[],"mappings":"AAqKA;;;;;;;;;;GAUG;AACH,mDAFa,iBAAiB,GAAC,IAAI,CAQlC;AAED;;;;;;;;;GASG;AACH,gDAJW,MAAM,GACJ,iBAAiB,CAW7B;AAED;;;;;;;GAOG;AACH,8DAFa,iBAAiB,GAAC,IAAI,CAQlC;AAED;;;;;;;;;;;;GAYG;AACH,4CAHW,SAAS,iBAAiB,GAAC,IAAI,GAAC,SAAS,CAAC,GACxC,iBAAiB,GAAC,IAAI,CAkBlC;AAKD;;;;;;;;;GASG;AACH,+CALW,iBAAiB,MACjB,iBAAiB;cACJ,MAAM;aAAW,MAAM;aAAW,MAAM;EAyB/D;AA3RD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiDG;AACH;IAwBI;;;;;;;OAOG;IACH,gBAPW,MAAM,QACN,MAAM,cACN,MAAM;QAEY,QAAQ,GAA1B,OAAO;QACL,iBAAiB,CAU7B;IAvCD;;;OAGG;IACH,YAFU,MAAM,CAED;IAEf;;;;;;;OAOG;IACH,UAFU,OAAO,CAEA;IAEjB;;OAEG;IACH,yBAEC;IAqBL;;;OAGG;IACH,8BAFU,OAAO,CAE8B;CAN9C;AAQD,gCAAgC;AAChC,gCADW,iBAAiB,CACyC;AAErE,gCAAgC;AAChC,iCADW,iBAAiB,CAC2C;AAEvE,gCAAgC;AAChC,iCADW,iBAAiB,CAC2C;AAEvE,gCAAgC;AAChC,iCADW,iBAAiB,CAC2C;AAEvE;;;GAGG;AACH,wCAFU,MAAM,CAE2B;AAE3C;;;;;;;;;GASG;AACH,kCAFU,iBAAiB,CAE0F;AAErH;;;GAGG;AACH,mCAFU,cAAc,iBAAiB,CAAC,CAOvC;AAEH;;;GAGG;AACH,sCAFU,cAAc,iBAAiB,CAAC,CAIvC;AAEH;;;GAGG;AACH,uCAFU,cAAc,iBAAiB,CAAC,CAKvC;yBA9JsB,oDAAoD"}

package/src/shade/renderer/particles/graph/ParticleValueType.js

@@ -0,0 +1,287 @@
+import { DataType } from "../../../../core/model/node-graph/type/DataType.js";
+import { VM_MAX_WIDTH } from "../isa/ParticleVMISA.js";
+
+/**
+ * The types a value in a particle graph can have: a float vector of one to four lanes, and the
+ * types that say what such a vector *means*.
+ *
+ * The VM has always run its instructions at a width, so the values have always had one; what a
+ * graph could not do until now was *say* it. Every port was declared `vec4`, which made a delta
+ * time read as four lanes and left `add` unable to tell an author what it was adding. These are the
+ * types {@link ./infer_particle_graph_types.js} resolves over a graph, and they are what a view
+ * shows on a port and colours a wire by.
+ *
+ * ## Shape and meaning
+ *
+ * `components` is the type's shape, and shape is all the arithmetic cares about: a `vec3` is three
+ * lanes whatever it holds. The name and id are its identity, which is what a person cares about.
+ *
+ * Keeping the two apart is what lets a type say what a value means without changing how it is
+ * computed. {@link PARTICLE_TYPE_COLOR} is the first: it is a `vec4` to every instruction the
+ * compiler emits, and a colour to the author — a swatch to edit, its own colour on the wire, and a
+ * name on the port that says what the four lanes are for. The rules in
+ * {@link ./ParticleNodeRegistry.js} compare shapes, never identities, so a colour goes wherever a
+ * `vec4` goes and a `vec4` goes wherever a colour is wanted, with nothing to convert either way.
+ *
+ * Where two types of the same width meet, the one that means something wins — see
+ * {@link particle_widest_type} — so a colour scaled by a number, or mixed with a plain `vec4`, is
+ * still a colour on the far side. That is the whole of the sugar: the meaning survives the
+ * arithmetic instead of being lost at the first operation.
+ *
+ * ## Conversions
+ *
+ * Where a value meets a port that reads it as a different shape, {@link particle_type_conversion}
+ * says what happens. A scalar into a vector slot broadcasts, as it does in every shading language,
+ * and silently. A vector read narrower keeps its leading lanes; read wider, the missing lanes read
+ * zero. Both of those are how the four-lane register file always behaved, so a graph written before
+ * types compiles to the same lanes it did — but each is now a warning naming the lanes concerned,
+ * because a `vec4` literal feeding a three-component attribute is either a mistake or a literal
+ * that ought to be a `vec3`.
+ *
+ * Types of the same width never convert, whatever they mean, so nothing is said about a colour
+ * meeting a `vec4`. A view still draws the two in their own colours, which is worth seeing — it is
+ * where a raw vector is being used as a colour, or a colour as raw arithmetic — but it is a change
+ * of meaning and not of lanes, and no instruction is emitted for it.
+ *
+ * ## Ids
+ *
+ * A type's id is what a {@link NodeGraphVisualData} colours by and what the node registry indexes,
+ * so these are fixed rather than taken from a counter: id 0 is the declared type of every port
+ * ({@link ./ParticleNodeRegistry.js PARTICLE_VALUE_TYPE}), the plain shapes take their lane count
+ * as their id, and the types that carry a meaning are numbered from {@link PARTICLE_SEMANTIC_ID_BASE}
+ * upward.
+ */
+export class ParticleValueType extends DataType {
+    /**
+     * How many lanes a value of this type occupies, `1..4`.
+     * @type {number}
+     */
+    components = 1;
+
+    /**
+     * Whether this type says what a value *means* on top of how wide it is.
+     *
+     * A plain shape (`f32`, `vec3`) says only how many lanes there are. A semantic type says what
+     * they are for, and is what survives when the two meet — see {@link particle_widest_type}.
+     *
+     * @type {boolean}
+     */
+    semantic = false;
+
+    /**
+     * @returns {boolean}
+     */
+    get is_scalar() {
+        return this.components === 1;
+    }
+
+    /**
+     * @param {number} id
+     * @param {string} name
+     * @param {number} components
+     * @param {object} [options]
+     * @param {boolean} [options.semantic] see {@link #semantic}
+     * @returns {ParticleValueType}
+     */
+    static from(id, name, components, { semantic = false } = {}) {
+        const r = new ParticleValueType();
+
+        r.set(id, name);
+        r.components = components;
+        r.semantic = semantic;
+
+        return r;
+    }
+}
+
+/**
+ * @readonly
+ * @type {boolean}
+ */
+ParticleValueType.prototype.isParticleValueType = true;
+
+/** @type {ParticleValueType} */
+export const PARTICLE_TYPE_F32 = ParticleValueType.from(1, "f32", 1);
+
+/** @type {ParticleValueType} */
+export const PARTICLE_TYPE_VEC2 = ParticleValueType.from(2, "vec2", 2);
+
+/** @type {ParticleValueType} */
+export const PARTICLE_TYPE_VEC3 = ParticleValueType.from(3, "vec3", 3);
+
+/** @type {ParticleValueType} */
+export const PARTICLE_TYPE_VEC4 = ParticleValueType.from(4, "vec4", 4);
+
+/**
+ * Where the ids of the types that carry a meaning start, above the four the lane counts claim.
+ * @type {number}
+ */
+export const PARTICLE_SEMANTIC_ID_BASE = 5;
+
+/**
+ * Four lanes that are a colour: red, green, blue and alpha, in that order.
+ *
+ * A `vec4` in every respect the compiler cares about — it lowers to the same instructions, goes
+ * into any `vec4` slot and takes any `vec4` — and a colour in every respect an author does: a
+ * swatch to edit rather than four numbers, and a colour of its own on the wire, so the path from
+ * where a colour is made to where it is written is visible in a graph full of vectors.
+ *
+ * @type {ParticleValueType}
+ */
+export const PARTICLE_TYPE_COLOR = ParticleValueType.from(PARTICLE_SEMANTIC_ID_BASE, "color", 4, { semantic: true });
+
+/**
+ * The plain shapes, narrowest first. Indexed by lane count, see {@link particle_value_type}.
+ * @type {ReadonlyArray<ParticleValueType>}
+ */
+export const PARTICLE_VALUE_TYPES = Object.freeze([
+    PARTICLE_TYPE_F32,
+    PARTICLE_TYPE_VEC2,
+    PARTICLE_TYPE_VEC3,
+    PARTICLE_TYPE_VEC4,
+]);
+
+/**
+ * The types that say what a value means, in id order.
+ * @type {ReadonlyArray<ParticleValueType>}
+ */
+export const PARTICLE_SEMANTIC_TYPES = Object.freeze([
+    PARTICLE_TYPE_COLOR,
+]);
+
+/**
+ * Every type a value can have. What a registry registers and a palette of wire colours covers.
+ * @type {ReadonlyArray<ParticleValueType>}
+ */
+export const PARTICLE_ALL_VALUE_TYPES = Object.freeze([
+    ...PARTICLE_VALUE_TYPES,
+    ...PARTICLE_SEMANTIC_TYPES,
+]);
+
+/**
+ * @type {Map<string, ParticleValueType>}
+ */
+const SEMANTIC_TYPES_BY_NAME = new Map(PARTICLE_SEMANTIC_TYPES.map(type => [type.name, type]));
+
+/**
+ * The semantic type of this name, or `null` for a name that is not one.
+ *
+ * How a tag written somewhere else — an attribute in a
+ * {@link ../layout/ParticleLayout.js ParticleLayout}, most of all — becomes a type. An unknown name
+ * is not an error here: the caller knows the shape regardless, and falling back to it leaves an
+ * effect that names a semantic this build has never heard of working as the plain vector it is.
+ *
+ * @param {*} name
+ * @returns {ParticleValueType|null}
+ */
+export function particle_semantic_type(name) {
+    if (typeof name !== "string") {
+        return null;
+    }
+
+    return SEMANTIC_TYPES_BY_NAME.get(name) ?? null;
+}
+
+/**
+ * The type of a value `components` lanes wide.
+ *
+ * Always a plain shape: a width says how many lanes there are and nothing about what they are for,
+ * so a semantic type is only ever arrived at by name.
+ *
+ * @param {number} components
+ * @returns {ParticleValueType}
+ * @throws if there is no such width
+ */
+export function particle_value_type(components) {
+    const type = particle_value_type_or_null(components);
+
+    if (type === null) {
+        throw new Error(`A particle value is 1 to ${VM_MAX_WIDTH} lanes wide, not ${components}`);
+    }
+
+    return type;
+}
+
+/**
+ * The type of a value `components` lanes wide, or `null` where that is not a width a value can
+ * have — which is how a node whose parameters do not describe a type says so without throwing in
+ * the middle of an editor.
+ *
+ * @param {*} components
+ * @returns {ParticleValueType|null}
+ */
+export function particle_value_type_or_null(components) {
+    if (!Number.isInteger(components) || components < 1 || components > VM_MAX_WIDTH) {
+        return null;
+    }
+
+    return PARTICLE_VALUE_TYPES[components - 1];
+}
+
+/**
+ * The widest of some types, ignoring the unknown ones; `null` when none is known.
+ *
+ * This is the rule every element-wise operation types itself by: the result is as wide as its
+ * widest operand, and every operand is read at that width. Among types of equal width the one that
+ * means something wins, so a colour times a number is a colour, and a colour added to a plain
+ * `vec4` comes out a colour whichever side it was on. Between two that both mean something, the
+ * first arrival wins — there is no ordering over meanings, and the alternative is refusing to type
+ * a graph that is arithmetically fine.
+ *
+ * @param {Iterable<ParticleValueType|null|undefined>} types
+ * @returns {ParticleValueType|null}
+ */
+export function particle_widest_type(types) {
+    let widest = null;
+
+    for (const type of types) {
+        if (type === null || type === undefined) {
+            continue;
+        }
+
+        if (widest === null || type.components > widest.components) {
+            widest = type;
+        } else if (type.components === widest.components && type.semantic && !widest.semantic) {
+            widest = type;
+        }
+    }
+
+    return widest;
+}
+
+/** Lane letters, in lane order. @type {string} */
+const LANES = "xyzw";
+
+/**
+ * What it means to read a value of one type as another, said the way a person would want to hear
+ * it — or `null` where nothing is read differently: an exact read, a broadcast, or a change of
+ * meaning between two types of one shape.
+ *
+ * @param {ParticleValueType} from the value's own type
+ * @param {ParticleValueType} to the type it is read as
+ * @returns {{dropped?: string, zeroed?: string, message: string}|null} the lanes concerned, and
+ *   one sentence about them
+ */
+export function particle_type_conversion(from, to) {
+    if (from.components === to.components || from.is_scalar) {
+        return null;
+    }
+
+    if (from.components > to.components) {
+        const dropped = LANES.slice(to.components, from.components);
+
+        return {
+            dropped,
+            message: `is a ${from.name} read as a ${to.name}: lane${dropped.length > 1 ? "s" : ""} ${dropped} `
+                + `${dropped.length > 1 ? "are" : "is"} dropped.`,
+        };
+    }
+
+    const zeroed = LANES.slice(from.components, to.components);
+
+    return {
+        zeroed,
+        message: `is a ${from.name} read as a ${to.name}: lane${zeroed.length > 1 ? "s" : ""} ${zeroed} `
+            + `read${zeroed.length > 1 ? "" : "s"} zero.`,
+    };
+}

package/src/shade/renderer/particles/graph/compile_particle_graph.d.ts

@@ -2,18 +2,25 @@
  * Lower a single-phase particle {@link ../../../../core/model/node-graph/NodeGraph.js NodeGraph}
  * into a VM instruction stream.
  *
- * The graph describes one lifecycle phase (SPAWN or UPDATE) of a particle effect: nodes are
+ * The graph describes one lifecycle phase (INIT or UPDATE) of a particle effect: nodes are
  * {@link ParticleNodeDescription} instances, and every connection wires a producing node's `out`
  * port to a consuming node's named input port.
  *
  * The pipeline:
+ * 0. Replace every node group with the nodes it is made of, until none is left — see
+ *    {@link ./flatten_particle_graph.js}. Everything after this point works on one flat expression
+ *    over the stock library, and so is written as though groups did not exist.
  * 1. Walk the graph from its sinks (attribute writes / kill), flattening it into an SSA-style value
  *    list in dependency order. Shared sub-expressions are evaluated once (DAG sharing via
  *    memoisation).
- * 2. Compute each value's last use.
- * 3. Linear-scan register allocation: registers are returned to the pool at a value's last use, so a
- *    result can reuse a just-consumed input register (VM ops read all sources before writing dst).
- * 4. Emit each value's opcode via its node description.
+ * 2. Resolve every value's type — see {@link ./infer_particle_graph_types.js} — which is how many
+ *    lanes it has. A value whose type cannot be told is a graph that cannot be compiled.
+ * 3. Compute each value's last use, and how many lanes wide it has to be — see {@link compute_widths}.
+ * 4. Linear-scan register allocation. Registers are `f32` slots, so a value occupies a RUN of them
+ *    and allocation is first-fit over an occupancy map; runs are returned at a value's last use, so
+ *    a result can reuse a just-consumed input's slots (VM ops read all sources before writing dst).
+ * 5. Emit each value's opcode via its node description, at the width step 3 decided, and widen the
+ *    result where a consumer reads more lanes than the value's type has.
  *
  * @param {NodeGraph} graph
  * @param {import("../isa/ParticleAssembler.js").InstructionStream} stream target section
@@ -22,16 +29,16 @@
  */
 export function compile_particle_graph(graph: NodeGraph, stream: any, asm: ParticleAssembler, layout: import("../layout/ParticleLayout.js").ParticleLayout): void;
 /**
- * Compile a full effect (SPAWN + UPDATE) into a {@link ../isa/ParticleProgram.js}.
+ * Compile a full effect (INIT + UPDATE) into a {@link ../isa/ParticleProgram.js}.
  *
  * @param {object} params
- * @param {NodeGraph} [params.spawn]
+ * @param {NodeGraph} [params.init]
  * @param {NodeGraph} [params.update]
  * @param {import("../layout/ParticleLayout.js").ParticleLayout} params.layout
  * @returns {import("../isa/ParticleProgram.js").ParticleProgram}
  */
-export function compile_particle_effect({ spawn, update, layout }: {
-    spawn?: NodeGraph;
+export function compile_particle_effect({ init, update, layout }: {
+    init?: NodeGraph;
     update?: NodeGraph;
     layout: import("../layout/ParticleLayout.js").ParticleLayout;
 }): import("../isa/ParticleProgram.js").ParticleProgram;

package/src/shade/renderer/particles/graph/compile_particle_graph.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"compile_particle_graph.d.ts","sourceRoot":"","sources":["../../../../../../src/shade/renderer/particles/graph/compile_particle_graph.js"],"names":[],"mappings":"AAGA;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,2EAHW,iBAAiB,UACjB,OAAO,6BAA6B,EAAE,cAAc,QAqD9D;AAED;;;;;;;;GAQG;AACH;IAL8B,KAAK;IACL,MAAM;IACoC,MAAM,EAAnE,OAAO,6BAA6B,EAAE,cAAc;IAClD,OAAO,2BAA2B,EAAE,eAAe,CAa/D;kCAjGiC,6BAA6B"}
+{"version":3,"file":"compile_particle_graph.d.ts","sourceRoot":"","sources":["../../../../../../src/shade/renderer/particles/graph/compile_particle_graph.js"],"names":[],"mappings":"AAMA;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AACH,2EAHW,iBAAiB,UACjB,OAAO,6BAA6B,EAAE,cAAc,QAmB9D;AA8PD;;;;;;;;GAQG;AACH;IAL8B,IAAI;IACJ,MAAM;IACoC,MAAM,EAAnE,OAAO,6BAA6B,EAAE,cAAc;IAClD,OAAO,2BAA2B,EAAE,eAAe,CAa/D;kCArUiC,6BAA6B"}