API reference

classMeshParticles

One caller-supplied mesh per particle, drawn as a single instanced draw. The cheap counterpart to `RibbonParticles`: the relationship stays one particle, one instance, and the per-instance data is byte-identical to `QuadParticles`'s - instanceAttributes, filled by the same writer. Only the shape changes. That is what makes this mode **GPU-eligible** without touching the compute pipeline: the pipeline emits precisely that layout, so a system on the GPU path binds its instance buffer directly and never calls build. **The mesh rides in its own vertex buffer**, alongside the per-instance one. The shader is fixed and shared, so any number of `MeshParticles` compile one program per backend regardless of how many distinct shapes they draw, and a mesh is limited only by what a vertex buffer holds. **Mutating the mesh works.** Its vertices are read into a normalised `(x, y, u, v)` table - the shader binds fixed names, a caller's geometry may use any - and re-read whenever the geometry's `version` changes. Edit the geometry in place, call `invalidate()` on it, and the next draw picks it up. Changing the vertex *count* is equally fine. **Atlas frames still work.** The mesh's own UVs are treated exactly like the quad's 0..1 corners: the shader mixes them across the particle's resolved frame (`uv = mix(uvMin, uvMax, meshUV)`), so `system.frames` plus a per-particle `textureIndex` selects a frame the same way. A geometry with **no texcoord attribute** therefore carries UV `(0, 0)` on every vertex and the mix degenerates to `uvMin` - the whole mesh samples the single texel at the frame's top-left corner, which on the default 1×1 white texture is exactly "untextured, tinted by the particle's `color`". **Sizing is the mesh's own.** Unlike the quad, which derives its footprint from the texture frame, a mesh particle's footprint is whatever its vertex positions say, in system-local units, multiplied by the per-particle `scaleX`/`scaleY`. The texture only supplies colour.