Shuriken, the new particle system

In the Renderer module you can set the Max Particle Size (prevents massive overdrawing). There should be no upper limit on that. If you experience any limitation then submit a bug with a repro please.

Note sure what you mean by 'same particles'. Please submit a bug report on this one so we can check if its by design.

Bug. We will look into this. EDIT: Its now fixed..

This is by design. When Prewarm is enabled Start Delay does not make sense (and therefore also greyed out (disabled) in the editor)

The local transform scale can be used for scaling the Emitter Shape. If you want to scale existing particles use Get/SetParticles. Or try SetStartSize() and SetStartSpeed ().

We would be very happy if you could submit bug reports with repro steps on all crashes you experience! Thanks

THX!

 

I am happy to have stimulated a discussion for a single surface particle system.

Perhaps, have an option, or a psys version mobile, or something that lets us use an atlas of particle textures instead a single would be just enough.
beware that these kind of particles will not be able to make UV animation like u do for single texture usual particles.

So, at the end, we will come up with 2 particle systems.
A Shurinken and a Single Surface one, able to play together and optimize a lot our App.

I will try to make a demo, to explain how it should be done, and perhaps end up with a system on the Asset Store because the idea of Unity being OpenSource ( in the sense we actively contribute in it ) is the thing that actually did make the difference with other engines.
Of course I would like rather to see this built in in Unity better than profit from users with something is missing.

 

Thanks for taking the time to reply MPN, I appreciate it.

Here's some followup on the questions:

Got it, didn't realize it could be set elsewhere.

I created a particle system, added a second particle system to it (it becomes nested under the first system in the editor). Then, in the hierachy, I duplicated the Particle System 2, and changed the material to a new material (I wanted two types of particles with the same emitter parameters). When I ran it though, what I got was both emitters fired particles with exactly the same position and direction, as if they had say, the same seed value. I haven't looked into it very hard though, it just seemed like it was buggy duplicating a nested emitter in such a fashion, so I avoided doing it. I will look further to see if there is a real bug here or if I'm doing it wrong.

Woo.

When looping is disabled, the prewarm button is greyed out, and the gui lets you enter a start delay. However, even though prewarm is greyed out, if it was checked before you disable looping, any start delay value you enter will enter will be ignored. Basically, the start delay box is enabled as if it were relevant, but it is ignored because prewarm is selected, even though prewarm itself is greyed out and requires looping enabled to do its thing.

What I mean is, for example, I create an explosion particle effect. If I wanted to create an explosion with half the size of normal, I would not only need to scale the size of the emitter, I would also need to halve the size and speed of the particles emitted. It would be cool if I could just set the local scale to 1/2 and get the correct result. Although, I guess I could probably write a script to handle that too.

It seems a little weird. Like one time I added a texture to my project, created a material, dragged that material into the material slot for the emitter, and bam, it crashes. I start my project back up, re-add the texture, create the material, and it works. I've had crashes in several cases, although most often while adding materials, and once while starting a simulation. It just seems unpredictable, so its hard to submit it as a bug because it's not easily reproducable.

 

Ok, I can now reproduce the crash and the particle overlap thingy 100% of the time. I made a video describing how to reproduce it.

 

@Doddler

This is not "weird" like you say. Mixing green and red gives yellow; And you should also check out what additive means...http://en.wikipedia.org/wiki/Additive_color

The crash is a bug however you are right on this part.

 

Thanks for the repro! Much appreciated! Will investigate... EDIT: Fixed!

If anyone else have repros like this please do as Doddler or submit a bugreport.
And please note what build you are using (see Help -> About Unity...)

 

It's weird because as two separate emitters they should be emitting separate red and green particles. Two separate emitters shouldn't be emitting particles with exactly the same position/velocity/etc that they blend additively like that. The expected output when duplicating the emitter in that fashion would be like this:



The fact that the particles are emitted with the same properties tells me that something internally is getting mixed up, which probably is why it crashes! Anyways apparently they're already aware of this particular issue, and are hoping it will be fixed in RC1.

 

This is because they have identical random seeds. You will be able to change that in the next drop.

It's now fixed! And it was not related to Particle Systems but to the duplicating of the material and it not being saved before going into playmode. So until next drop save your scene before going into play mode. Thanks again for taking time to make a video of this issue.

 

I have a question: Is it normal then that the simulation is different from the result when pressing play ?

I did the same thing Doddler did in his video but for the system emitting the green material I changed the emission rate. The results were that the simulation only showed red and yellow particles but when I pressed play I had all three colors. So this mean the seeds seem to be different between hitting play and simulate.

 

All the Shape of Emitter shapes except Cone allow RandomDir to be turned off. Why not Cone?

Think of it like a shower head: the non-random direction of a particle from a Cone emitter should be directly forward (angle 0) for particles from the center of the emission circle, and at Angle for particles from the edge of the circle.

Interestingly, you do get such non-random direction both at Angle==0, and at Radius==0.

 

Hi, at b7 the delay for particle emitting is not functionable. All emittors run imediately without delay.

BTW: some Speed by lifetime component is usefull, and what about angle force and velocity?

shuricen is so usefull.

m.

 

Make sure pre-warm is unchecked. Even though prewarm is greyed out (and does nothing when loop is off), it still prevents start delay from functioning.

 

b7 is there an update to the 3.5 beta?

 

The only thing I can say about the new particle system is this - in the first 10 minutes that I spent looking at it my thoughts were "WTF am I supposed to do with this". The interface is definitely not intuitive until you REALLY dig into it and start to understand all the bells and whistles. After spending some time with it it gets better, but it takes some time to make the transition if you don't know what you're doing.

 

I don't know if this is a bug or by design but start delay does not work when using distance (rather than time) for emitting.

That would be useful for timing effects like trails of particles behind a projectile. Here's a common example: If you use a sub emitter that is set to use distance for emission, but its parent's emission is set to time, it would be nice if when the main particle system is turned on, that the sub emitter respects the start delay regardless that it is set to distance. Right now this doesn't work.

Edit: If its by design then I believe it should be grayed out when emission is set to distance.

 

Yes beta7 has regressions regarding start delay. Will be fixed..

 

Yes. The 3.5 developer preview build from before christmas was beta 6

 

Is there a 3.5b7 version of Unity?? I may have misunderstood...

 

Yes b7 was mentioned so I thought there might have been a minor update to the build.

 

Unity -> Help -> Check for updates -> 3.5.0b6
Unity.com -> Download -> 3.5.0b6

Hum...

 

But that's the public windows beta, what about the mac beta and the private beta?

 

The folks in the private beta are likely a version or two ahead so sit tight

 

There seem to be a problem with the cone emitter. If you move the handle to make it flat like a disc, you can't turn it back into a cone afterwards and you are stuck with the shape of a disc because the handle and the transform handle are located in the same position once you do that. Is there any way to reset the shape of an emitter then ?

 

Length of the cone gizmo controls start speed, so just increase that and you're good.

 

This is the problem I see with the Cone shaped emitter:



Why is there no way to turn off RandomDir?

 

Thanks !

On another note, in case you haven't stumbled on it, I found a bug that is probably related to the particle system. I posted a video of how to reproduce it along with some explanation in this thread :

http://forum.unity3d.com/threads/120472-BUG-3.5b6-Particle-Prefab-Bug-makes-Unity-hang-forever.

 

One of the big holes in the old system was that the size of the Ellipsoid particle emitter could not be set from scripts (eg. here, here, and here).

Now it's even worse - it's only a sphere (not an ellipsoid), and the radius cannot be set from scripts.

The new system seems to repeat and compound the problems of the old system.

 

There is Component.particleSystem, but no GameObject.particleSystem, even though the legacy particleEmitter exists in both.

 

Ooooh, I like that GetParticles/SetParticles no longer requires allocating Particle arrays! This should improve performance enough to allow us to implement more stuff ourselves.

 

We implemented support for letting the scale of the particle system affect the emitter but there are some corner cases we didn't have time to fix, so it's disabled in 3.5. We will look into getting it in in the future.

 

You can also change to Rotate, this transform gizmo does not block the center.

 

That's definitely the best solution! I'm glad to wait - correctly scaling particle systems will be excellent!

 

"Lifetime"? I think you mean "life". The word "lifetime" refers to the whole of a life, not the remaining time one has to live.

Roy in Bladerunner: "I want more life". Not "I want more lifetime".

Of course, since you've just changed it from "energy", I guess you've had half of the discussion already.

 

This is one of the nicer systems I've ever used, and certainly does it's job. The mesh support and sub emitters are appreciated too. I can only suggest a few things to add...

1. random emission rate range
2. rotate/orient to velocity vector (damned handy)
3. screen space coordinates (gui fx)
4. custom modules (certainly already requested)

Lastly, and sorry if this has already been asked, but how do I adjust the alpha of a particle over time? For additive blended particles it's simply to fade them to black, but how is this done for particles utilizing alpha blending? Having particles pop out of existence is no good =(

That'd be an excellent suggestion 5, if it's not something I'm dumbly overlooking.

 

Lifetime is a term used in a lot of effects systems, just like "emitter" and "particle" are terms.

 

Using "Color over lifetime"; the colour gradient editor has Alpha swatches at the top, RGB swatches at the bottom.

 

Thanks, Pro!

Another query: Is there a way to offset the transform of individual particles (so rotate makes them orbit around a center point, rather than spin in place?)

 

So is there no ability to use PhysX's collision with the new particle system? One of my major go-to effects is to have sparks from an explosion bounce around the environment as they burn-out and come to a rest. The plane thing just isn't going to cut it for such a thing...

David

 

Little update: I definitely need the ability to offset particle pivots for rotation if it's not possible yet. Should just be two lines of code, right?

 

Run-time reference is on my hard drive... thought I'd post a link so you could find it too.

file:///F:/Program%20Files%20%28x86%29/Unity/Editor/Data/Documentation/Documentation/ScriptReference/ParticleSystem.html

 

In my opinion the new particle system is better than the previous one but there are some strange behaviors (some has already been mentioned) and some old features gone, preventing me to do the same as in the old syste,:

1. Default Emitter rotation: It's always (-90,0,0) Really annoying...
2. Emitter shapes forced to face Z: All the emitter shapes are facing the Z axis, without being able of change it (you have to rotate de transform)
3. Emitter shape box and start velocity: It seems that start velocity always put the particles up (if Random Direction is false) even if you just put make a plane facing the XY
4. Emitter shape Random Direction: When true all the emitter shapes makes the same
5. Ellipsoid emitter is gone
6. Tangent velocity is gone: Because of this and the previous point I can't make a particle ring (particles are emitted in a plane from a center point to the outside, damping the particle velocity so they make a circumference around the center). I have been trying to achieve this with Shuriken, but seems impossible, because I can't spawn particles with random directions on the same plane and with the same module Any help here will be appreciated
7. World rotation for easier manipulation
8. World particle collider gone

Other advance things that I miss from other particle system out there:

1. Particles following a path
2. Force fields
3. Beam/lighting system

Despite that I really like the new system

 

After playing with it for a bit, there's one thing I really miss and two relatively simple things that could add a lot:

1: Tangent velocity. It seems a lot of old-particle-system effects can't be copied without this.
2: An option for mesh particles to face along their direction of motion.
3: 'Fade out when near' and 'fade out when edge-on' render options would add a lot of pretty.

 

Sorry if this has already been asked or is a silly question but I was wondering how / if this new particle system is supported on iOS ?
I unfortunately can't update and test this new unity right now as I'm in the middle of some important updates on my recently released apps..
Thanks !
oX

 

It works on iOS for me. However, a bug that I would like to point out:

I cannot create particle systems at runtime using iOS. Period.

• AddComponent<ParticleSystem> doesn't seem to work at all on iOS (this works on the desktop) - it complains of ' ' (yes, it resolves to a blank type) not being derived from 'Component'.
• The legacy particle system doesn't expose Ellipsoid or Mesh Particle emitters, and AddComponent("EllipsoidParticleEmitter") doesn't seem to work on iOS (this also works on the desktop).

Right now I'm using an ugly workaround for Shuriken which involves instantiating a resource prefab with a particle system, adding an empty MonoBehaviour, and using ParticleSystem system = myScript.particleSystem.

I'll file a bug report on the above today.

I would also like to see more access to modules (possibly through a GetModule() function) to control more aspects of the particle system at runtime.

 

Hi,

We're having problems figuring out how to make our particles face the way we expect them to when using mesh particles.

We're using the cone emitter and an asymmetric mesh. All we want is for the mesh to shoot out facing AHEAD.

So, if we change the transform rotation of any particle object, or even parent object, the particles are emitted in the appropriate direction but their individual rotation is fixed, instead of relative to emission direction. This seems crazy to us and makes no sense? Can someone explain what we're doing wrong? Moreover, the rotation field has room for only one value in it... how does this work with a mesh, which is 3d?

 

That's a very good point. There seems to be no way to control the axis of rotation of a mesh particle. If there were options for controlling X,Y and Z rotation for mesh particles, that would be great.

 

I'd just like to mention how brill i think this system is, thanks guys!

 

I'm looking into Shuriken and it seems pretty straightforward. One thing I haven't been able to find is emitter sorting. It's possible to sort the individual particles within a emitter but what about the emitters themselves? If you take the flare particle, say you want to give the flare a higher priority than the smoke coming of it and thus the flare always being shown on top, how do you achieve this?

 

@FrankB

Its in the reference manual...

Sorting Fudge -> Use this to affect the draw order. Particle systems with lower sorting fudge numbers are more likely to be drawn last, and thus appear in front of other transparent objects, including other particles.

 

are there any tutorial / Examples how to use Shuriken ?
That would be very helpful... maybe a nice Demo Project ;-)
I'm looking for UV Animation that work with the old Particle System...
can't get it to work...
thxx