What started as an attempt to work around the limitations of Shuriken and Legacy particles has turned into a completely new particle system.
Hydra Particles is an open source particle system for Unity that can be used as-is or freely extended. We are designing the system to be as accessible as possible to both developers and designers of many levels.
Per particle quaternion rotations - Legacy and Shuriken only provide a single arbitrary axis.
Forces - Forces are simple components that can be added to the scene to immediately create new effects (gravity wells, directional forces, turbulence, etc).
Colour blending - Simultaneously utilise per particle colour, colour over speed and colour over lifetime. Choose exactly how these values mix (multiply, overlay, burn, dodge, etc).
Programmer Advantages:
Fully open source - Tear it apart, modify it, learn from it.
Comprehensive API - If you can see it in the inspector, you can modify it via code.
The renderer is pending a rewrite, so the inspector is currently very messy.
We have implemented most of the base features and we will be close to a testing stage soon.
We are trying to accommodate for as many user requirements as possible and are keen to hear any further features you guys might like to see in a particle system.
What do you like/dislike about other particles systems you have used?
What would you would like to see in your ideal Unity3D particle system?
What do you most commonly use a particle system for?
Currently being developed:
Point cloud
Vertex color shaders to compliment default Unity shaders.
Option for 2D games - to lock to appropriate axis
Editor utilities
Tutorials
Documentation
Potential Future extensions:
Prefab instantiator (instantiating prefabs and mapping their transforms to particles)
The per particle quaternion rotation sounds like an attractive feature, one of the primary limitations of Shrunken for me is the constraints in that regard. Could you elaborate on how this new system may work?
Also, if I was to put a feature on my particle systems wish-list it would be the ability to emit particles evenly distributed around a cylinder. Similar to the smaller circular emission of smoke in the image below, however evenly and consistently distributed without the need for multiple particle systems.
Each HydraParticle in our system has a Quaternion rotation, and a Vector3 angular velocity property (soon we’ll add rotation over lifetime, rotation over speed).
(Emitter per-particle rotation settings)
You can very simply set the rotation value of each individual HydraParticle as you would a Transform, and the HydraParticleRenderer will orient the particle accordingly. In this very simple demo I am using the HydraLookAtForce to demonstrate how simple it can be to rotate particles:
using Assets.HydraParticles.Scripts.Abstract.Forces;
using Assets.HydraParticles.Scripts.API.Emitters;
using Assets.HydraParticles.Scripts.API.Particles;
using UnityEngine;
namespace Assets.HydraParticles.Scripts.Concrete.Forces
{
/// <summary>
/// HydraLookAtForce adjusts rotational velocity such that particles
/// turn to look at the force position.
/// </summary>
public class HydraLookAtForce : AbstractHydraForce
{
/// <summary>
/// Applies the force to the specified particle.
/// </summary>
/// <param name="emitter">Emitter.</param>
/// <param name="particle">Particle.</param>
/// <param name="deltaTime">Delta time.</param>
public override void Apply(IHydraParticleEmitter emitter, IHydraParticle particle, float deltaTime)
{
Vector3 position = emitter.GetParticleWorldPosition(particle);
Vector3 particleToForce = transform.position - position;
if (particleToForce == Vector3.zero)
return;
Quaternion toForceDirection = Quaternion.LookRotation(particleToForce, transform.up);
float delta = 180.0f * deltaTime * GetIntensityAtPosition(position);
particle.rotation = Quaternion.RotateTowards(particle.rotation, toForceDirection, delta);
}
}
}
It is also extremely easy to inherit from AbstractHydraForce and create completely new effects.
With regards to the cylinder emission, I feel there are a few potential solutions:
With Hydra Particles it is trivial to instantiate a bunch of new particles and add them to an existing emitter. You can completely configure the particles, including their positions in local/world space. Currently we are writing a Point Cloud script to help demonstrate/facilitate this usage.
We have discussed briefly the idea of particle systems having multiple emission shapes. Is this something that you see being useful?
We still need to implement mesh emission, which could include the ability to distribute particles over geometry. We could also implement some form of bezier emission shape.
That is very cool, I think the ability to have more control over gimbal lock when billboarding would be nice. That is to lock the pitch, yaw and roll in any combination. This system may be well implemented in the inspector allowing people (like myself) with a vague understanding of scripting the ability to efficiently adjust such a thing. On the other hand seeing as modification of the current systems is quite accessible that may be a bit of a time sink.
In response to your suggested solutions I imagine a solution may be explored allowing one or more custom mesh emitters to strictly use the normal directions of the mesh as the emission direction and perhaps even having control over the deviation from the surface normal direction of the mesh.
For instance a cylinder could then be used quite efficiently to emit particles in an even distribution. Perhaps you can utilise the smoothing groups of an object, I only have a limited understanding of the technicalities behind mesh smoothing and it may already be utilised inside Shrunken, I’m just spit-balling here and I’d love to hear your opinion on that. To summarise control over emission based on normal direction with the ability to control the deviation would be totally badass.
With regards to the use of multiple emission shapes I think if having multiple meshes per particle system will lower performance overhead then it is something I’d gladly use. However if simply having two particle systems doing the same job (with more modularity) would have no negative impact on performance compared to the former method then I could live without it. I think it’d be a neat feature nonetheless.
I love the locking idea. From playing games where rain splashes are quickly drawn randomly on the ground in rapid succession, it is important to have billboards that only rotate in yaw.
Mesh emitter is something I need to get started on. I don’t think the normals/smoothing should be much of a problem, though I need to research how to distribute mesh points evenly.
Yes we do! We also provide the ability to modify each axis independantly:
You’ll also notice you can make the randomization linear. This means that instead of each axis being randomized, you instead get a random point between the two values. This is useful in cases such as scale where you want random sized particles, but you want to maintain the ratio.
Mesh Rendering - With this rotation for X Y Z should be available rather then just X
Material Rendering Properties over particle lifetime - The biggest problem that I face is the fact I can’t change a Materials property over a Particles lifetime. I have solved this by using a Vector parameter but this as you can guess this stops me form using it for other properties like Colour and Alpha.
Those are my subjections but I’m sure there are some I have missed out.
Thanks for the suggestions. By mesh rendering/rotation do you mean something like this?
The material properties is an interesting one I hadn’t considered. I’ll have to run it past our shader guru and see what we can come up with, unfortunately she’s on vacation for the week.
That’s great, an added benefit would be locking a rotation axis of mesh very much how you are able to like the billboard render as previously posted. a benefit to this is for 3D water splash.
Another addition (Sorry to badger on) would be a better stretching render. What I mean is the ability to stretch a billboard or mesh over time. UDK’s Cascade uses this but Unity requires that the particle has a velocity which is really annoying.
Thanks again and I am excited to see the outcome,
Tim.
Hello.
About the collision, against what can the particle collide, 2D & 3D colliders? At the moment the Unity particle system only supports 3D collision, so to have also finally a particle system which supports 2D colliders would be great.
Does this particle system support animating particles via material offsets?
Overdue a bit of an update. The past week I’ve mostly been working on optimizations across the board, but I’ve also been able to implement:
A bezier editor - soon this will be hooked up up to the emitter so you can emit particles in all kinds of crazy arcs (click for short video):
Locking Vector3 fields - for when you don’t want each axis to be independant:
Now, Perracolabs, I haven’t actually taken a look at Unity’s new 2D features, but I would like to think 2D collision would be simple enough to implement. Perhaps you could describe a scenario (or even provide a scene) where particles would be colliding with an object in 2D and I can work on the collision there.
Can you elaborate on the animation comment? I think you’re asking for texture driven animation?
About the animation, I refer to the existing functionality of the Shuriken particle system “Texture Sheet Animation”, which allows to use tiled materials to emit particles each taking a different tile from the material. So an example is that I might have a material which uses let’s say a 4x4 tiled texture, each tile having a different shrapnel piece, then each emitted particle would be using any of the 16 tiles which I placed in the material. This is useful when the particles should have a resemblance to an exploding object.
About Unity 2D, all 2D colliders have an infinite Z axis, meaning that no matter how far objects are from each other on the Z axis, they will still collide between them only because of the X/Y axis.
To test 2D collision is very simple to setup. In a 2D-game-mode scene with a orthographic camera, create a 2D sprite and give it a Physics2D.BoxCollider2D, place HYDRA emitting near it on the X/Y axis but far on the Z axis, The expected result is that no matter in which Z axis position HYDRA is placed, emitted particles which intersect with the same X/Y axis of the sprite will still collide with it, even if by the Z axis particles are very apart from the sprite.
In a 2D game the user will never see any Z axis at all. the Z axis is used usually only at design time to not have all the gameobjects cluttered on the same plane and to z-sort them.
About 2D collisions, I can give you many scenarios where it would be useful. A game example is BroForce (see video), though this game is a 2D platformer it has been implemented behind the scenes in 3D.
The Unity Shuriken system has no 2D colliders support, so 2D platform games which need to use such effects need to be developed with 3D colliders and 3D physics, giving a unnecesary overhead.
Thanks for clarifying everything. The texture sheet animation is definitely on the todo list. Shouldn’t be hard to implement at all (just need to randomly offset uvs by some factor).
I did some reading on 2D and it looks like it’s going to be trivial to get Hyrda particles colliding with 2D colliders. I’ve got the model/inspector updated:
Next step is to update the simulation logic. I should have a demo for you this evening!
(Video showing collision - Made using the Hydra Particles system)
