API reference

Every public class, method, and event in @codexo/exojs. Generated from source.

C

classParticleRenderMode

@codexo/exojs-particles / particles / stable

Turns a particle system's SoA storage into drawable vertex data. A mode owns the whole "how": the vertex layout, the shader pair, the draw model, and the loop that fills the buffer. The backend renderers only upload what it produces and issue the draw it declares, so a new primitive is a new mode rather than a renderer change. Implementations are fixed at system construction (see `ParticleSystemOptions.render`) and default to `QuadParticles`. **Limits of the seam.** The executors are deliberately thin, so a new mode has to stay inside what they can express: - The geometry's `stride` must be a multiple of 4. WebGPU's `queue.writeBuffer` validates its copy size against that alignment and rejects anything else, so a mode with, say, a 38-byte stride draws on WebGL2 and fails validation on WebGPU. - An **indexed, non-instanced** mode always draws the geometry's fixed `indexCount` and ignores count on both backends. That is right for a fixed-topology mode and wrong for one whose element count varies per frame; such a mode needs the executors taught to derive an index count from count first. No mode ships in that shape today. - An **instanced** mode that declares no vertexGeometry has to derive its vertices in the shader from the vertex index, and its dataLayout must carry the indices that address them. Without either there is nothing to tell the executors how many vertices one instance spans.

7
props
5
methods
0
events
Import
import { ParticleRenderMode } from '@codexo/exojs-particles'

Turns a particle system's SoA storage into drawable vertex data.

A mode owns the whole "how": the vertex layout, the shader pair, the draw model, and the loop that fills the buffer. The backend renderers only upload what it produces and issue the draw it declares, so a new primitive is a new mode rather than a renderer change.

Implementations are fixed at system construction (see `ParticleSystemOptions.render`) and default to `QuadParticles`.

**Limits of the seam.** The executors are deliberately thin, so a new mode has to stay inside what they can express:

- The geometry's `stride` must be a multiple of 4. WebGPU's `queue.writeBuffer` validates its copy size against that alignment and rejects anything else, so a mode with, say, a 38-byte stride draws on WebGL2 and fails validation on WebGPU. - An **indexed, non-instanced** mode always draws the geometry's fixed `indexCount` and ignores count on both backends. That is right for a fixed-topology mode and wrong for one whose element count varies per frame; such a mode needs the executors taught to derive an index count from count first. No mode ships in that shape today. - An **instanced** mode that declares no vertexGeometry has to derive its vertices in the shader from the vertex index, and its dataLayout must carry the indices that address them. Without either there is nothing to tell the executors how many vertices one instance spans.

Constructors1
new(): ParticleRenderMode
Methods5
_ensureCapacity(byteLength: number): void
Grow the scratch buffer to hold at least byteLength. Grow-only: a shrinking particle count reuses the larger buffer rather than reallocating, matching the renderers' existing buffer policy.
_onBufferGrown(_data: ArrayBuffer): void
Re-create typed-array views after _ensureCapacity reallocates.
_setCount(count: number): void
Record the element count produced by a build.
Fill the scratch buffer from the system's live particles. particles is the simulation's own channel storage, handed in rather than read off the system: a render mode is the one consumer that legitimately works in bulk, and it runs at the point in the frame where those values are the ones being drawn.
destroy(): void
Optional cleanup, called from ParticleSystem.destroy.
Properties7
Layout of the buffer build fills each frame: attributes, stride, upload hint, and - when this mode declares no vertexGeometry - the topology and index list the draw uses. Named after data, the buffer it describes. It holds per-instance records for an instanced mode and per-vertex records otherwise, so a name fixed to either would be wrong for one of the two draw models.
gpuEligible: boolean
Whether this mode can run while the system is in GPU compute mode. Mirrors UpdateModule.wgsl(): a mode that cannot forces the whole system onto the CPU path, silently and observably via ParticleSystem.gpuMode. A GPU-eligible mode's layout must match what the compute pipeline emits into gpuState.instanceBuffer - the shared 40-byte per-instance layout (instanceAttributes). QuadParticles and MeshParticles both declare exactly that layout and differ only in the shape they expand it into, which is why both are eligible without the compute shader knowing either.
instanced: boolean
Draw model. true issues an instanced draw, false a plain draw over the built vertex buffer. Declared here because a layout carries topology but has no instancing concept.
Fixed per-vertex geometry this mode instances, or null when it derives its vertices in the shader from the vertex index - which is what QuadParticles and RibbonParticles do. When set, it supplies the topology, index list and index count for the draw in place of dataLayout's, and the executors bind its vertexData as a second vertex buffer stepping per vertex beside the per-instance one. Only meaningful on an instanced mode: without instancing both buffers would step per vertex and no draw is expressible. Attribute names must not collide with dataLayout's, since both sets bind into the same shader. Mutating the geometry is picked up on the next draw through its version, so invalidate() after an in-place edit is enough to reach the GPU.
count: number
Element count of the draw call this mode's last build produced. Draw-model relative: instance count when instanced, vertex count otherwise. Do not assume one meaning.
data: ArrayBuffer
The buffer the renderer uploads. Valid until the next build.
Source