Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Shuriken, the new particle system

Discussion in 'Developer Preview Archive' started by Artimese, Dec 25, 2011.

?

How is the new system?

  1. Its great as it is, nothing needs to be changed.

    195 vote(s)
    56.0%
  2. Its too complicated to use, it must be simplified!

    108 vote(s)
    31.0%
  3. Its too hard to learn, I will not use this new system.

    45 vote(s)
    12.9%
  1. Spellbound

    Spellbound

    Joined:
    Sep 9, 2011
    Posts:
    51
    Hey, that's cool :)

    We are often filling volumes with twinkling particles using a rather short lifespan i.e. to make a light cone look more interesting. These particles are mostly not even leaving the volume (just some random turbulence motion).

    Separation and combination (factors) of radial, tangential and axial emission is great for various effects, like flat, concentrical explosions and stuff like that.

    Ah, good to know this is still on schedule. IMO both path and spacial forces with dropoff are essential tools when working with particles. I have written quite a lot of particle plugins for Maya and all these local controls are very powerful. This could also be taken a step further to kill particles that leave or enter a volume or modify color/alpha parameters.

    We had this case a few times now, that we wanted i.e. to emit differently textured billboards (i.e. 3 types of smoke texture) to enhance the look of a smoke stream and make it look less regular. Another example of different materials is having a certain amount of self illuminated particles within a smoke stream without the need to set up 2 particle systems that would also generate 2 draw calls.

    When adding object arrays, could you give each array a factor value that weights array elements against each other? This would provide us with a great control to emit i.e. 80% objects of type A and 10% of type B and C respectively. Factors could be any value, in the previous example i.e. 8, 1, 1 or 0.8, 0.1, 0.1.

    Cool. I was not sure if we should replace some performance critical particles we already built.
     
    Last edited: Dec 27, 2011
  2. alexzzzz

    alexzzzz

    Joined:
    Nov 20, 2010
    Posts:
    1,447
    There is ParticleSystem class in scripting reference, but I can't find how to access all the modules. For example I want my particles to be affected by the wind - as the wind changes, the force applied to all the particles should also change. I don't know how to access "Force over Lifetime" module to change the force.
     
  3. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    Try looking at the texture sheet module, it solves at least randomization of textures (if you pack it into the same texture).

    Good idea.

    Please let us know if you find performance problems.
     
  4. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    We haven't exposed everything in the scripting API because that allows us to do a lot of memory and performance optimizations. We have however in addition to exposing emitter related stuff (stuff that changes how particles are emitted) exposed the particle array (GetParticles/SetParticles) which you can use to apply forces (just add velocity on particles in the direction of your wind).
     
  5. RElam

    RElam

    Joined:
    Nov 16, 2009
    Posts:
    375
    Would be nice if collision worked with world.

    Nice if playback looped according to duration, or had setting in window, so when tweaking something like an explosion you don't have to turn on/off looping in the particle itself.

    Multiple renderers would be nice, so if you wanted something like bullets with billboarded flares and stretched trailer it would be trivial. Perhaps a secondary system can just copy the particles of it's master, and disable all spawning/velocity based modifiers (if multiple renderers is an architectural limitation).

    A particle renderer I found fairly useful in my stuff is one that was a billboarded quad oriented with the center edge perpendicular to the velocity, and stretching the tail vertex by the velocity. This was nice for any variable velocity objects with trails (best example likely being sparks), since you could map the particle so that the portion in one half was undeformed, and the other stretched by velocity, an effect you can’t achieve by using stretched billboard.

    Another cool addition would be stream renderer, so you can do things like lightening (this would require a particle flag for indicating one is connected to previous). This makes it trivial to create lightning with secondary/tertiary tendrils coming off of it. This works real well with a ray/spring spawner, so, making a cooler looking version of the quake 2 rail gun, for instance, would be pretty easy. The ray/spring spawner actually works really nicely with the concept of curves, since it's a 1D shape, and you can spawn temporally along the ray/spring as well as map that to a spawn curve to define things like offset from spawn point (random or velocity based), which would be clearly cool for lightning since you can shape how the lightning between beginning and end veers away from the path.
     
  6. alexzzzz

    alexzzzz

    Joined:
    Nov 20, 2010
    Posts:
    1,447
    It is sad to hear, because as a scripting guy I like to control everything from the code. Even my editor window is almost empty all the time except some helper objects, because the worlds I create are generated. Anyway GetParticles/SetParticles is a flexible solution.
     
  7. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    We didn't have time to make this for 3.5, but will add it in the future.

    Can you elaborate on this? You want it to loop the playback in a non-looping particle system as a playback option?

    Wrote these things down.
     
  8. RElam

    RElam

    Joined:
    Nov 16, 2009
    Posts:
    375
    Yes. It seems now if I'm looking at something like an explosion, I have to hit simulate each time, so a looping checkbox would do the trick, or change the stop button to loop when it's stopped, since it has no purpose then (if you wanna conserve space).
     
  9. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    Okay we'll take a look at it.

    Btw. did you know there are shortcut keys for particle playback? Check the editor prefs.
     
  10. RElam

    RElam

    Joined:
    Nov 16, 2009
    Posts:
    375
    I did not think about that, no, but it's still a bit annoying when you're working on an effect that lasts 2 seconds to have to hit hotkeys each time.
     
  11. deram_scholzara

    deram_scholzara

    Joined:
    Aug 26, 2005
    Posts:
    1,043
    I don't think it needs to be any simpler - it's just currently lacking in documentation/tooltips.

    I do, however, think that it needs to be more open to scripting. Currently only the main module has accessible variables, while the additional modules do not. Can't even change global velocity because of this.
     
  12. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    That can be done through Get/SetParticles.
     
  13. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    Where does it need tooltips?
    Which parts could be explained better with tooltips? Would be happy to improve this.
     
  14. Demostenes

    Demostenes

    Joined:
    Sep 10, 2010
    Posts:
    1,106

    Look at this manual:

    http://www.unifycommunity.com/wiki/index.php?title=TreeCreator_Tutorial

    This is how manuals for new system should be done. Not generic info like official documentation:

    http://unity3d.com/support/documentation/Components/class-Tree.html

    Difference is huge, depth of information cant be compared. First manual is amazing and answers everything, second is generic and useless.
     
  15. deram_scholzara

    deram_scholzara

    Joined:
    Aug 26, 2005
    Posts:
    1,043
    First off, the help icon links to "Particle System class" instead of "Particle System Shuriken". It should link to:
    ........Documentation/Documentation/Components/comp-ParticleSystemShuriken.html

    Secondly, there should be some indicator that choosing random between two colors in things like "Color Over Lifetime" only determines the starting color (which makes perfect sense), not randomly over the lifetime as implied. In fact, I don't see why Color Over Lifetime even needs this option, since you can already do the same thing with "Start Color" in the Particle System module.

    In my opinion, every variable should have a tooltip, but I'll just list what I think are the missing essentials for now.

    Under the "Particle System" section:
    • Duration - "The length of time the system emits for, or the length of one loop-cycle."
    • Looping - "If true, repeats emission cycle after duration length."
    • Start Speed - "The starting velocity of an emitted particle, applied in the starting direction."
    • Start Color - "This color is applied to the particles and multiplies with any other applications of color."
    • Inherit Velocity - "Applies the current directional velocity of the Transform to new particles, only works while playing"
    • Lock to Transform - "Makes particle positions stay relative to the Transform, overrides 'Inherit Velocity.'"
    • Max Particles - "New particles will not be emitted unless less particles than this number are currently in this system."

    Under the "Emission" section:
    • Bursts - "You can emit extra particles at set times during the duration of the system."

    Under the "Shaper of Emitter" section:
    • Shape - Determines the volume from which particles can be emitted, also determines non-random starting direction."
    • Random Dir - "Randomizes the starting direction of particles, regardless of shape influence."
    Also Note: "Dir" should instead be the whole word "Direction".

    Under the "Rotation Over Lifetime" "Rotation by Speed" sections:
    • Rotational Speed - "Degrees of rotation per second through the duration of a cycle."

    Under the "Force Over Lifetime" section:
    • Planes - "Particles will collide with the axial XZ planes of these objects."
    • Scale Plane - "Changes the size of the displayed grid - does not affect collision."

    The rest seems relatively straightforward to me. I think something to keep in mind when doing tooltips is that despite the fact that you may have a wonderful manual for users to reference, you still want to prevent them from needing to use it. In other words, it is more productive for users to learn from within a program's interface than it is to read through a manual - mainly because everything is in-context.
     
  16. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    Thanks!

    But it is over lifetime. Start color is random over the emitter duration and color over lifetime is over the particle lifetime.
    Also, I will add tool tips to the mentioned sections.
     
  17. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    Done. I have now added tool tips to every single property in Shuriken. Hoping it will clear up some of the confusion when we release 3.5.
     
  18. TwiiK

    TwiiK

    Joined:
    Oct 23, 2007
    Posts:
    1,729
    You sure are on top of things. :)

    Having fun making fireworks 2.0 based on the included example. Pumping it full of image effects as well seeing as I got Unity Pro for christmas and haven't used them before. :p

    Can I showcase anything made with 3.5 beta? The webplayer only works locally, as the red warning text explains. :/
     
  19. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
  20. deram_scholzara

    deram_scholzara

    Joined:
    Aug 26, 2005
    Posts:
    1,043
    Awesome! Thank you so much!

    Well I might be misunderstanding something here, but from what I see choosing "random between two colors" in "Color Over Lifetime" causes the emitter to randomly pick a color when the particle is emitted, then it maintains the chosen color over the life time of the particle. Setting "Start Color" to "random between two colors" has the same effect. It seems to me that using that setting in "Color Over Lifetime" should cause it to randomly pick a new color every frame, which would obviously be annoying, so I don't see any unique need for having this setting in this tab - unless it's just there because it can be.
     
  21. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    Oh!

    Yes, you are right. The constant color options don't really make sense for the lifetime modules. The same is true for constant for size over lifetime etc. We will look into getting rid of the options that aren't useful.
     
  22. chronosapien

    chronosapien

    Joined:
    Feb 1, 2011
    Posts:
    73
    In the old system, the World Particle Collider had an option for sending messages when a particle collided. Since (I'm assuming) the Collider module is replacing this, is there a way to get messages on particle collisions?
     
  23. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    We didn't have time to implement this for 3.5 unfortunately, but it's high on the list for the next version.
     
    Last edited: Dec 28, 2011
  24. chronosapien

    chronosapien

    Joined:
    Feb 1, 2011
    Posts:
    73
    It might also be nice, since particles have their own editor window now, to be able to add "Animation Events" like you can in an animation which trigger script functions or change parameters.
     
  25. profanicus

    profanicus

    Joined:
    Nov 23, 2009
    Posts:
    295
    I have found an issue when using a combination of Bursts with Start Energy -> Rnd 2 curves and Start Speed -> Rnd 2 curves. The particle positions warp all over the place.
     
  26. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    Hi! Please file a bug on it.
     
  27. TwiiK

    TwiiK

    Joined:
    Oct 23, 2007
    Posts:
    1,729
    How would I go about adding sounds to my particle system? I have rockets going up in the air and when they explode I want to play a sound, i.e when the rocket particles dies and the explosion particle system fires.

    Edit: I must be dense. I don't understand how GetParticles is supposed to work. I would expect an array of particles in return, but instead I get an int? And what am I supposed to send as an argument? :)
     
    Last edited: Dec 29, 2011
  28. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    There won't be control over stuff like that for 3.5. You can get the same though by making a script and in Update() go through all particles and check if particle.energy < deltaTime. If that is the case it will be killed this frame (i.e. before LateUpdate() is called), so at that point you can trigger a sound to play from the position of the partticle.

    int GetParticles (ParticleSystem.Particle[] particles);

    You pass your own array in and the particle system will fill it in for you.

    Example script that will make all particles red:
    public class ParticleBufferAccess : MonoBehaviour
    {
    private ParticleSystem.Particle[] particles = new ParticleSystem.Particle[1000];
    void LateUpdate()
    {
    int length = particleSystem.GetParticles(particles);
    int i = 0;
    while (i < length)
    {
    particles.color = Color.red;
    i++;
    }
    particleSystem.SetParticles(particles, length);
    }
    }
     
  29. TwiiK

    TwiiK

    Joined:
    Oct 23, 2007
    Posts:
    1,729
    Awesome. Was playing Battlefield while I waited for an answer. This problem stopped me dead in my tracks. :)

    It works, but I don't understand how. Why does it only update the color and not completely remove my other settings like size, energy etc.? I mean, the particles in "particles" are all empty except for the color red and GetParticles only returns a count. Does SetParticles only update the values that are set and ignore the defaults?

    Also, is there a reason you use LateUpdate?
     
  30. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    When you do GetParticles(particles) it copies the data into particles and returns the size of the internal array (or the size of your array if that is smaller).

    I use LateUpdate because Shuriken updates between Update() and LateUpdate(), so if I use Update() and it emits any new particles, they will be made "red" on the second frame, causing a short flash (depending on how different the initial color is from red) as it emits. Using LateUpdate() means they will be updated after emission.
     
    Last edited: Dec 30, 2011
  31. Screenhog

    Screenhog

    Joined:
    Jul 2, 2009
    Posts:
    498
    I've submitted a particle system bug report, but just so the forum members are aware, if you parent a particle system to another object, turn off "Lock To Transform", deactivate the particle system, move the parent, and then reactivate the particle system, a few particles will show up in the place where you first deactivated.

    As for the poll: I didn't vote for any of them, because none of them fit. I think it's a good system with a few small things to iron out (that other people have already mentioned in this thread).
     
    Last edited: Dec 30, 2011
  32. hoesterey

    hoesterey

    Joined:
    Mar 19, 2010
    Posts:
    659
    Awesome,
    Thanks for the info!
     
  33. runonthespot

    runonthespot

    Joined:
    Sep 29, 2010
    Posts:
    305
    I'm curious- is the GetParticle/SetParticle function using passing by reference to prevent us from doing silly things like copying the entire particle array each frame or some logic along those lines?
     
  34. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    Yes.
     
  35. TwiiK

    TwiiK

    Joined:
    Oct 23, 2007
    Posts:
    1,729
    Couple of things:

    1. Checking particle energy to see when it dies in my script works great, but how would you go about playing a sound when a particle spawns? Are there events I can use or is that a feature we won't see in 3.5? I've tried comparing current particle energy to starting energy etc., but spawned particles never have their exact starting values so I'm having some troubles with that.

    2. The curves for the starting values (energy, speed etc.) go from 0 - duration on the x-axis, but every other curve go from 0 - 1 instead of 0 - energy. Would it be possible to show the x-axis as going from 0 to the current start energy for the particle system? If start energy is set to random or curve then it could just show 0 - 1 or 0 - [min - max] or something similar, but at least when the starting energy is a constant it would make working with curves easier as you could time each change to the correct second instead of some arbitrary value between 0 and 1.

    3. I think the Emission module needs some work. Because now if you have a birth subemitter (like a rocket tail) the curves for emission rate does nothing when it would be really helpful to be able to control the rate across the parent particle life span to simulate the rocket going out of fuel for example. Adding to the confusion is the fact that the x-axis of the emission rate curve goes from 0 - 1 instead of 0 - duration like the other curves based on duration. It should behave differently when it's a sub emitter is my point I guess.

    4. Size over Lifetime: Setting it to random between two curves does not achieve the effect I expected. I would expect the size of each particle to flicker each frame, but instead it just sets a random starting size for each particle. This is the same as deram_scholzara noted with the color over lifetime module I guess. I think these modules should pick a random value each frame, but maybe also have an option to smoothly interpolate between random values every x frames or something.
     
  36. TwiiK

    TwiiK

    Joined:
    Oct 23, 2007
    Posts:
    1,729
    Also, please make the particle editor node based. :)

    It's so close already, but what's there now isn't comparable in terms of usability. I honestly do not use it, and instead use the inspector, because the layout seems to be based on the alphabetical sorting in the Hierarchy window which makes no sense in terms of which particle system belongs where.

    Having defined arrows pointing from each sub emitter to the correct particle system would be so great instead of just a horisontal list.
     
  37. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    The reason why they never have their exact starting value is because we perform sub frame interpolation to get perfectly continuous emission. Therefore energy values can differ up to a full deltatime. Newly spawned particles should have energy values between startEnergy and startEnergy - deltaTime though.

    Maybe. We'll consider it.

    This is how I thought it worked (it should use the lifetime value from the parent particle to look up into the emission curve). I'll look into that.

    It gets a random value at spawn and then uses that to interpolate between the 2 curves. On the force module you can set it to randomize every frame but that's about it. We're aware of this and may add it in the future.
     
  38. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    We've noted that it's hard to see how combined particle systems relate to each other and will see what we can do. We won't have time do do anything drastic for 3.5 though.
     
  39. profanicus

    profanicus

    Joined:
    Nov 23, 2009
    Posts:
    295
    It may be preferable to just change the starting values to go from 0-1 as well, to make things consistent across the board.
    A value between 0 and 1 is hardly "arbitrary", personally I always prefer working in multipliers and percentages.
     
  40. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    Another thing: to check if a particle has spawned, if you check in Update() that will essentially check the particle on frame #2, which means the delta time is not necessarily the same as it was frame #1. The nicest solution would be to check in LateUpdate() if(energy >= (startEnergy - dt))
     
  41. Moonjump

    Moonjump

    Joined:
    Apr 15, 2010
    Posts:
    2,572
    I've spent some time playing with Shuriken. Usability seems poor compared to the old system. For example, One Shot was easy to use before. Now it seems you have to set the Emission Rate to zero and have a Burst to get the same effect, but it takes experimentation to get that is what you have to do.

    I have 2 major problems though:

    1. The old system allows you to preview the effect in the Game view so that you can see what the result will be. Now you have to do it in the Scene view, which is far less accurate a guide to what will be seen in-game.

    2. So far I have only been able to animate colours using RGB, not the RGBA of the old system. It appears I can no longer have particles fade out.

    Am I missing something on these 2 points?
     
  42. TwiiK

    TwiiK

    Joined:
    Oct 23, 2007
    Posts:
    1,729
    Yup. :)

    1. If you click simulate in the bottom right corner of the scene view it will continue playing when you switch to game view. Also, if you have the particle editor window open you can click simulate/pause and stop in the top left corner at any time while in game view.

    2. Just click above the gradients to add alpha controllers.

    Edit: Also, as for your one shot problem it's shouldn't be more complex than what you're describing. Also, remember to turn off looping. It's a bit more intricate than it was, but you can also do a lot more with it.
     
    Last edited: Jan 4, 2012
  43. Django

    Django

    Joined:
    Nov 25, 2008
    Posts:
    120
    Hi,

    the problems I have with the new particle system are :

    A. You can no longer have it spawn particles that are not animated. If someone know how to do this with the new system please share.

    B. The handles for the shape of emitters could be bigger or having the possibility to change the color of the wireframe of shape of the emitter would be great because in some cases, depending on the number of particles their color and size of emitter, the particles make it hard to see the shape of emitter to tweak it in the scene view. To tweak the emitter in scene view I have to turn emit off and then turn it back on to see the results, and so on...

    C. Very unstable on my Mac for some reason. Unity keeps crashing all the time for no apparent reason when I am editing the parameters my effects in the new particle system, but I guess it is to be expected from a Beta. Its very random so far so maybe its something on my side. Anyone else having crash problems ?

    Other than that I enjoy it very much. Its not perfect but it is very flexible and you can do much more with it than with the old one. Some things like burst might not be as intuitive as one shot but burst allows for a lot more flexibility and control which is a lot better.
     
    Last edited: Jan 4, 2012
  44. BrUnO-XaVIeR

    BrUnO-XaVIeR

    Joined:
    Dec 6, 2010
    Posts:
    1,687
    Unity crashes sometimes when hit the button to simulate the particle's preview in scene view.
     
  45. Moonjump

    Moonjump

    Joined:
    Apr 15, 2010
    Posts:
    2,572
    Thank you very much Twiik.

    Regarding 1, it isn't particularly obvious or user friendly, but at least it is there.

    And onto 2, that is actually a really nice way of doing it. Pity about the unlabelled buttons that access it.

    And one more question:

    I see it is possible to animate the Texture Sheet, but is it possible to emit a random frame from the texture sheet for each particle (and then stay on that frame)?
     
  46. angel_m

    angel_m

    Joined:
    Nov 4, 2005
    Posts:
    1,160
    I think the old system was better for fast results or make simple effects and it was much more intuitive.
     
  47. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    Any chance of making the Shuriken Gradient system available for use in other areas e.g. animation or as a component?
     
  48. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    What does this mean? That they don't move? Just set start speed to 0 on the default system. What are you trying to achieve?

    Noted.
     
  49. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    Yes. Just pick random between two curves in the frame over time curve and set them both to constant (i.e. a horisonal line). The area between the curves is now the range of texture sheets it will select randomly from.
     
  50. WBDN

    WBDN

    Joined:
    Dec 23, 2011
    Posts:
    109
    We wanted to expose it so you can use it in your scripts any way you want, but there was no time to finish it for 3.5.
    We will look into it for the next one.