Renderer · class
ParticlePool
Explained in Hello world.
class ParticlePoolimport { ParticlePool } from '@driftengine/core';Constructor
new
constructor(options: ParticlePoolOptions)| Parameter | Type | Description |
|---|---|---|
options | ParticlePoolOptions |
Properties
| Name | Type | Description |
|---|---|---|
instancesreadonly | InstanceData | |
particlesreadonly | ParticleInstances | The same particles, as a particle material wants them. See ParticleInstances. |
Accessors
| Name | Type | Description |
|---|---|---|
liveget | number | How many particles are alive. |
Methods
emit
emit(x: number, y: number, z: number, vx: number, vy: number, vz: number, seed: number, sizeScale?: number, lifeScale?: number): voidAdd one particle.
| Parameter | Type | Description |
|---|---|---|
x | number | |
y | number | |
z | number | |
vx | number | |
vy | number | |
vz | number | |
seed | number | |
sizeScale? | number | |
lifeScale? | number |
More
seed drives the per-particle variation instead of Math.random, so a
caller inside a deterministic system can pass a tick count and get the same
plume twice — which a replay needs, since the same run has to look the same
on the way to being a clip.
update
update(dt: number): voidAdvance every particle and rebuild the instance buffer.
| Parameter | Type | Description |
|---|---|---|
dt | number |
More
Compacting as it goes: live particles are written to the front of the instance data, so the draw call submits exactly the live count and dead particles cost nothing but the loop iteration.
clear
clear(): voidDrop everything, for a respawn or a scene change.