Runtime cost and memory
Understand sampling, particle rendering, baked masks and sample-bank reuse during gameplay.
This topic covers runtime cost only. Baking is an editor step and is not included here. During gameplay, TUNS reads the prepared sample bank on the GPU; it does not run spacing relaxation or rebuild the distribution.
What costs time at runtime?
| Work | Runtime cost |
|---|---|
| Sampling in Particle Spawn | Each new particle reads a bank entry. Skeletal sampling also resolves that point against the current animated pose. |
| Sampling in Particle Update | Attached particles repeat the sample and skinning work each frame. Use this when they must follow the surface. |
| More live particles | More Niagara simulation and rendering work, even when they share a sample bank. |
| Larger translucent sprites | More pixels to shade and potentially more overdraw. |
| Larger sample bank | A larger GPU atlas to keep resident. Bank capacity does not set the live particle count. |
Baked masks add no mask draw calls
The mask’s allowed regions and density are already stored in the baked distribution. TUNS does not render or sample the original mask texture for runtime particle placement, so the baked mask adds no runtime draw calls. The particles still have their usual renderer and material costs.
More particles than samples
Sample Bank Size is the number of reusable surface locations, not a particle limit. Sample indices wrap around the bank. For example, a burst of 4,096 particles can reuse a 1,024-point bank four times.
Those particles reuse the same surface locations; TUNS does not create another bank or generate extra unique points. They can overlap at spawn, then separate through their own motion. Particles kept attached can remain stacked at shared locations.
A smaller bank reduces atlas memory. Each particle still performs its own sampling, simulation and rendering work, so reusing locations does not make the extra particles free.
GPU memory
A 65,536-point bank uses approximately 2 MiB for skeletal samples or 4 MiB for static samples, plus a small header. Static banks also store positions and normals. GPUBytes reports the bank payload, not total VRAM used by meshes, materials, Niagara or the scene.
Compare runtime performance fairly
Match the mesh, mask coverage, live particle count, renderer, material, camera and resolution. Warm up shaders and loading, then run each method separately. Compare whole-frame, game-thread and GPU time; a side-by-side scene measures both effects together.
The comparison screenshots measure spacing quality, not runtime timing.