# ParticleEffectForUGUI: rendering ParticleSystems inside Unity UI without an extra Camera

> Particle Effect For UGUI (package name com.coffee.ui-particle) bakes particle meshes into CanvasRenderer geometry so ParticleSystems can be masked, sorted and animated as ordinary UI elements. Here is how it works, how to install it, and where the shader and version constraints bite.

**mob-sakai/ParticleEffectForUGUI** — Render particle effect in UnityUI(uGUI). Maskable, sortable, and no extra Camera/RenderTexture/Canvas.

- Repository: https://github.com/mob-sakai/ParticleEffectForUGUI
- Stars: 6,009 · Forks: 765
- Language: C#
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/mob-sakai-particleeffectforugui

## The sorting and masking problem UIParticle removes

A normal ParticleSystem is a world-space renderer. It draws into the camera's rendering order, not into the uGUI hierarchy, so a particle effect placed behind a panel or inside a scroll view either draws on top of everything or gets hidden by it. The standard workaround is to render the particles to a RenderTexture with a dedicated Camera and display that texture on a RawImage. That works, but it adds a camera, a texture allocation, a resolution to manage, and a second sorting problem: the RenderTexture is one flat image, so individual particles can never interleave with individual UI elements.

Particle Effect For UGUI attacks the same problem from the other side. Instead of capturing particles into a texture, it feeds the particle geometry into the CanvasRenderer that uGUI already uses. The README states the package uses the MeshBake and MeshTrailBake APIs introduced in Unity 2018.2 to render particles through CanvasRenderer, and that this lets you render, mask and sort ParticleSystems for UI without an additional Camera, RenderTexture or Canvas. The audience is Unity UI developers: people building menus, HUDs, reward popups and card effects where the particles need to behave like a UI element rather than like a scene object.

## MeshBake, CanvasRenderer and what the package adds on top

The mechanism is a bake step. Unity's particle system can hand its generated mesh to a callback rather than draw it itself; the package takes that mesh, and a UIParticle component on a RectTransform drives a CanvasRenderer with it. Because the geometry arrives as canvas geometry, it inherits the things canvas geometry gets for free: sibling-index sorting, Mask and RectMask2D clipping, and CanvasGroup alpha. The README lists trail module support, CanvasGroup alpha integration, and no allocations among the features, and it notes that a MeshSharing group exists to improve performance when several UIParticle instances share the same mesh.

The trade-off is that the particle system no longer owns its own draw. Shaders therefore have to be written for the canvas path. The README has a dedicated Shader Limitation section: built-in shaders are not supported, and on Unity 2018 or 2019 the UV.zw components are discarded and custom vertex streams are affected. That is the real cost of the design. You get correct UI ordering and masking, and in exchange every particle material must be a shader that works with the baked mesh. The README also documents an Overheads section and a comparison of the baking-mesh approach against the conventional approach, which is where a reader should look before assuming the canvas path is always cheaper.

## Installing via OpenUPM and adding your first UIParticle

The README lists four installation routes: OpenUPM, UPM through the Package Manager UI, UPM manually, and as an embedded package. The OpenUPM route uses the package name com.coffee.ui-particle, which is also the name in package.json. The manifest entry below is the scoped-registry form the package is published under; the registry URL is the OpenUPM one shown in the README badge.

```json
{
  "scopedRegistries": [
    {
      "name": "package.openupm.com",
      "url": "https://package.openupm.com",
      "scopes": ["com.coffee.ui-particle"]
    }
  ],
  "dependencies": {
    "com.coffee.ui-particle": "4.14.1"
  }
}
```

After the package resolves, the README's Basic Usage section describes adding the UIParticle component to a GameObject and assigning a ParticleSystem to it. The package also ships a Demo sample: package.json declares a sample with displayName Demo at path Samples~/Demo, which Unity exposes through the Package Manager's Samples import. The README points at two WebGL demos, one of them a Cartoon FX Free and War FX build by Jean Moreno, if you want to see the result before importing anything.

The README also documents three companion pieces worth knowing about on day one: UIParticleAttractor, ParticleSystemPreviewer, and project settings. The previewer exists because a baked particle system is no longer visible in the Scene view the way a normal one is, which is a small but real workflow change.

## Where the shader requirement turns into a wall

The clearest case where this is the wrong tool is a project whose particle effects come from the Asset Store with materials built on the built-in particle shaders. The README states plainly that built-in shaders are not supported, so those effects will not render correctly through UIParticle until the materials are replaced or rewritten. The README includes a section titled How to Make a Custom Shader to Support Mask and RectMask2D Component, which tells you the expectation is that you or your TA will author the shader. If nobody on the team can write a canvas-compatible particle shader, this package is not a drop-in.

The second wall is Unity version. On Unity 2018 or 2019 the README warns that UV.zw components are discarded, and that custom vertex streams are affected. Effects that encode data in those channels will look wrong, and the fix is not in the package. The README's own FAQ entry, Why Are My UIParticles Not Displayed Correctly, exists precisely because this class of problem is common enough to need a heading. A third, softer limitation: because rendering goes through the canvas, the effect is subject to canvas rebuild behaviour, and the README's Overheads section is the place to check what that costs rather than assuming it is free.

## How it differs from the RenderTexture camera approach

The conventional alternative is the one described earlier: a second Camera rendering a particle layer into a RenderTexture, displayed on a RawImage inside the canvas. The difference in approach is where the compositing happens. With a RenderTexture, the particles are flattened into a single image before the UI ever sees them, so a particle can never be drawn between two UI elements, and the effect inherits the texture's resolution and filtering. With UIParticle, the particle mesh goes into the canvas as geometry, so sibling index decides what is in front, and Mask and RectMask2D clip the particles the same way they clip an Image.

That difference cuts both ways. The RenderTexture route works with any shader, including built-in ones, because it is just a camera render. UIParticle works with far fewer shaders, but gives you ordering and masking that the RenderTexture route cannot express. If your effect lives in a fixed rectangle with nothing overlapping it, the RenderTexture route is simpler and imposes no shader work. If your effect needs to slide behind a button and in front of a panel, only the baked-mesh route can do it.

## Maintenance, versions and the MIT licence

The repository is not archived, and the last push was on 2026-09-07. Releases are frequent: v4.14.1 and 5.0.0-preview.23 were both published on 2026-09-06, with 5.0.0-preview.22 on 2026-08-27. Note the split. package.json on the default branch still declares version 4.14.1, so a manifest that resolves com.coffee.ui-particle without pinning will get the stable 4.x line, not the preview. If you want the 5.0.0 preview, you are choosing an explicitly labelled preview build and should expect API movement between preview numbers.

Upgrade cost is dominated by shaders rather than by C# API. A version bump that changes how the baked mesh is produced can require revisiting custom shaders written against the earlier behaviour, and the README's shader sections are the reference for that. The project is MIT licensed, which is permissive and places few obligations on commercial use, but the shaders you write on top are your own and carry whatever terms you give them. This is not legal advice; read LICENSE.md in the repository for the actual terms.

The dependency surface is small: package.json requires com.unity.ugui 1.0.0 and com.unity.modules.particlesystem 1.0.0, and declares unity 2018.2 as the minimum editor version. That low floor is why the 2018 and 2019 shader caveats exist at all.

## Conclusion

Adopt it if you are shipping uGUI screens that need particles to sit between UI layers, obey Mask or RectMask2D, and fade with a CanvasGroup; the MeshBake and MeshTrailBake path is exactly what removes the second Camera and its sorting problems. Do not adopt it if your particle materials rely on built-in shaders, if you are pinned to Unity 2018 or 2019 and need custom vertex streams, or if you want a fire-and-forget drop-in for an existing world-space effect. Verify three things before committing: that your project runs Unity 2018.2 or newer, that every particle material has been converted to a UIParticle-compatible shader, and that the 4.14.1 line in package.json is the version you actually want, since the 5.0.0 previews are published separately and are not what the manifest resolves to.

## FAQ

### What does ParticleEffectForUGUI do that a normal ParticleSystem cannot?

It renders particles through CanvasRenderer using the MeshBake and MeshTrailBake APIs, so they can be masked by Mask or RectMask2D and sorted by sibling index alongside other UI elements. The README states this removes the need for an extra Camera, RenderTexture or Canvas.

### How do I install ParticleEffectForUGUI in Unity?

The README lists four routes: OpenUPM, UPM through the Package Manager UI, UPM manually, and as an embedded package. The package name is com.coffee.ui-particle, and package.json declares com.unity.ugui and com.unity.modules.particlesystem as its dependencies.

### Why are my UIParticles not displayed correctly?

The README has a FAQ entry with exactly this title, and the Shader Limitation section gives the likely cause: built-in shaders are not supported, and on Unity 2018 or 2019 UV.zw components are discarded and custom vertex streams are affected. Check the particle material's shader first.

### Does ParticleEffectForUGUI work with URP and HDRP?

The README lists any render pipeline support as a key feature and states compatibility with Universal Render Pipeline and High Definition Render Pipeline. It also states any canvas render mode is supported: overlay, camera space and world space.

### Which version of ParticleEffectForUGUI should I use?

package.json on the default branch declares version 4.14.1, so an unpinned manifest resolves to the stable 4.x line. The 5.0.0 builds are published as previews, with 5.0.0-preview.23 released on 2026-09-06.

## Sources

- [Issues](https://github.com/mob-sakai/ParticleEffectForUGUI/issues)
- [License: MIT](https://github.com/mob-sakai/ParticleEffectForUGUI/blob/main/LICENSE)
- [mob-sakai/ParticleEffectForUGUI on GitHub](https://github.com/mob-sakai/ParticleEffectForUGUI)
- [README](https://github.com/mob-sakai/ParticleEffectForUGUI/blob/main/README.md)
- [Releases](https://github.com/mob-sakai/ParticleEffectForUGUI/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mob-sakai-particleeffectforugui