Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

[Official] Particle System [Shuriken] Improvements

Discussion in 'General Graphics' started by bibbinator, May 26, 2014.

  1. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,620
    Riiiight, I think I get it now. So you'd like a rotate XYZ in the Shape Module, to rotate the emitter shape?
    I guess full transform options would be even nicer.. so you could do position + scale, too?
     
  2. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    Yea, that would be rad!
     
  3. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    I started working on Unity 5.5.0f3. Noise module is really good but terribly slow to work with. Whenever I change any particle parameter with Noise module enabled Unity slows down tremendously. Dragging curve points, changing value parameters - all this actions are freezing Unity for a moment. With Noise module disabled the problem is gone. I'm on Windows 10, i7-3770, gtx970, 32gb ram.

    Also, can we get new limit velocity over lifetime module? It is really hard to understand and super hard to control. Instead, a simple dampen parameter or "air resistance" would do better. For example, a dampen of 1 would decrease the speed by 100% over one second, 0.1 would decrease it by 10% etc. Current "limit velocity" works more like a clamp which is not very useful.
     
    Last edited: Feb 4, 2017
    Archanor likes this.
  4. Archanor

    Archanor

    Joined:
    Dec 2, 2013
    Posts:
    465
    Yes to this! Being able to scale size/radius of cone emitters over time would rock, been wanting to use something like that on one of my last effects.
     
    Last edited: Feb 6, 2017
    richardkettlewell likes this.
  5. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    Same feeling. My solution when I really need to keep Noise module while editing is to stop simulation preview.

    My opinion is that "limit velocity over lifetime" module is a misnomer because it takes the resultant movement speed calculated from start speed, gravity, velocity, force, noise and external force into consideration instead of just "velocity over lifetime". This means it can be very tricky to get the proper speed cap for damping. To make this module more intuitive to work with I boldly suggest to measure the slowest and fastest particle movement and report these speed values right in the particle playback controller in Scene view. If it drags preview-editing performance like Noise module, maybe you can make a separate Particle Speed recording controller and set "not recording" by default.

    Feedback ticket: https://feedback.unity3d.com/sugges...maximum-and-minimum-speed-values-of-particles

    maxminspeed_mockup.png
     
    Last edited: Feb 7, 2017
    richardkettlewell likes this.
  6. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,620
    Turning off Resimulate should solve this. Resimulate can cause the editor to have to do a lot of work when settings are changed, and it gets worse, as the playback time gets larger.

    We have a bug report about it here: https://issuetracker.unity3d.com/is...-editing-particle-system-causes-editor-to-lag
     
    Martin_H, varfare and karl_jones like this.
  7. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    richardkettlewell likes this.
  8. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,132
    @richardkettlewell: I finally got around to start experimenting with trail renderers (really cool feature!) and I have a question. I was trying to make things like rocket smoke trails with trail renderers (both inside particle system for smoke trails of debris, and with normal line renderer components for projectiles), and I can't seem to find the kind of texture tiling option that I would need (in 5.5.0, I'm not sure what got added in 5.6, if it's already in that would be even better ^_^ ). Either it stretches the whole texture over the entire trail, or it tiles but keeps pulling the UVs with it so that it looks more like a moving snake/catterpiller, than something leaving a trail. The kind of behaviour I'd need for smoke trails would be something like creating the uvs based on the distance traveled in worldspace and keeping the UVs of already created vertices unchanged when the trail gets longer. I think I could then make a custom shader that uses the vertex color gradient on the trail to make the trail drift away in the wind direction by offsetting the vertices in the vertex shader. Some pseudo animation of the smoke could be made with distorting its UV coordinates with a second texture and another input from the vertex color gradient.

    Is there a chance the UV generation code for the "end cap vertices" gets an update?
    This is how it currently looks:
    2017-02-23-a.JPG

    Since the convention seems to be to use trail- and line renderers with textures that fade out towards the upper and lower edges to create glowing beam effects etc., I would have expected the end cap vertices to try to stick to the upper and lower edge of the UV space to generate some kind of "soft" end. I have made a quick mockup that demonstrates it better than I can explain:

    2017-02-23-b.JPG

    In case of a more complex tiling smoke trail texture there would still be a visible seam on the center axis, but that would be much less noticable than the current solution. Could this maybe be added as an optional feature in the future?
     
    Marco-Sperling and varfare like this.
  9. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
  10. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
  11. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
  12. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,132
    @richardkettlewell: I just experimented a bit with the particlesystem renderer mode "mesh". There's a list of meshes in the inspector that you can add meshes to that the particlesystem picks from, but I can only add 4 meshes. Is it possible to unlock this limitation so that I can add more?
    I tried to do it from code with this:

    Code (csharp):
    1.  
    2. public class MParticleSystemMeshSetter : MonoBehaviour {
    3.     public Mesh[] meshes;
    4.  
    5.     void Start () {
    6.         ParticleSystemRenderer renderer = GetComponent<ParticleSystemRenderer>();
    7.         renderer.SetMeshes(meshes);
    8.     }
    9.    
    10. }
    But that doesn't work. The changes don't take effect until I deactivate and reactivate the renderer module in the inspector. Even if I do this from code the issue remains:

    Code (csharp):
    1.  
    2.         renderer.enabled = false;
    3.         renderer.enabled = true;
    4.  
    And it does seem to ignore all but the first 4 meshes from the array, only shows the first 4 in the inspector and also seems to only render those 4.

    Is this a bug? I don't see any mention of such limitations in the docs:
    https://docs.unity3d.com/560/Documentation/ScriptReference/ParticleSystemRenderer.SetMeshes.html

    I'm using 5.5.2f1 in case it matters.

    Cheers!

    P.s.: In case you're wondering what I'm needing this for, I'm trying to make a complex particle system/sub emitter setup for debris, where bigger pieces break down into smaller pieces and ultimately leave stationary particle debris meshes on the ground that stay around for a long while. The numerous performance optimizations in the particle collision module seem to really help with performance compared to using rigid bodies instead.
     
  13. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,620
    It's a pretty difficult limitation for us to address, due to how we handle multi-mesh particle systems internally. I can add it to our roadmap for investigation though, thanks :)

    I know it's not much of a workaround, but perhaps you could instantiate 2 (or more) identical prefabs, and override the 4 meshes to be different in each..? Just a thought.
     
    Martin_H likes this.
  14. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,132
    Thanks for the quick reply and for adding it to the roadmap!

    At least I now know it isn't a bug :). I guess I can work around it to a degree with multiple particlesystems, thanks!
     
    richardkettlewell likes this.
  15. Archanor

    Archanor

    Joined:
    Dec 2, 2013
    Posts:
    465
    @richardkettlewell Hey, just had to ask about this again; would it be possible to have meshes point in the direction they are moving? Maybe even a Stretched Meshes render mode (which would be similar to Stretched Billboards). Haven't found any other way to do this yet.
     
    Martin_H likes this.
  16. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,620
    It's coming in 2017.1, but it's not in the current beta.

    We have added a new Render Alignment option called Velocity, which allows particles to face the direction they are travelling. (but no stretching and not camera-facing, and supports using the Rotation Modules with them). This is in the current beta.

    Currently, this option only works for billboard particles. An upcoming beta will allow mesh particles to use all the options in this dropdown too. (View, Local, World, Facing, Velocity)

    You can track the progress of the original request here: https://feedback.unity3d.com/suggestions/mesh-particle-to-face-the-camera-like-billboard-particle
     
  17. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,132
    I'm still on 5.5, currently playing around with the new lights module, which is really cool and helps make vfx more complex without adding a ton of unneccessary scripts and objects. For example I have a particle effect for impact sparks that could look nice with lights added, but I'd need to add a little vertical offset because otherwise the light source is too close to the ground. Is something like that already on the roadmap or could be added?
     
    richardkettlewell likes this.
  18. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,620
    Hey, that's a good idea, thanks :)
    (And no, nothing on the roadmap currently)

    Right now, you could use the pivot offset in the Renderer to move the particle instead of the light. I appreciate this may or may not work though, depending on the use case.
     
    Martin_H likes this.
  19. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,132
    Thanks for the suggestion! I just tried adjusting the pivot of the particle in the renderer tab, but the light remains at the emit position of the particlesystem. I would need to calculate an offset where I place and emit the particle from code and I'd lose the ability to apply random rotation to the particle. In that case I think the random rotation is more important to avoid the effect looking too repetetive (the spark burst is a spritesheet from stock footage). But you gave me another idea :), I could use a second particle system just to emit lights from, that would also give me finer control over the lights' intensity over time than I have now (some fades are in spritesheets so the color over time gradient doesn't represent the particle brightness very well).
    Thanks a lot for your help!
     
    richardkettlewell likes this.
  20. Torbach78

    Torbach78

    Joined:
    Aug 10, 2013
    Posts:
    171
    Martin_H likes this.
  21. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    https://feedback.unity3d.com/suggestions/shuriken-particle-inherit-emission-seed-module

    Previously I made the feature request of Particle Seed and Auto Randomize Seed when auto randomized seed malfunctioned in 5.4. These are now in the latest Shuriken main module. In hindsight my request was ill-made because of lacking more thorough discussion with Unity technicians. Back then the functions were available for scripting but without being exposed to the editor UI. I doubt that any fx artist would ever manipulate the emission seed in the editor UI considering that it still requires some degree of scripting to take full advantage.

    My original goal was to inherit (override) the emission type (time, distance or burst), rate and seed (either defined by the user or auto-generated) of one emitter to another emitter, creating a "follow me" behaviour of multiple emitters. I know this can be done via script, and surprisingly simple, but the point is to benefit fx artists without them dealing with scripting which often worries the actual programmers of the team.

    The Inherit Emission module would be similar to the Sub Emitter module but without the spawning condition and inheritance options, maybe the inheritance is kept for choosing between which kind of emission to be inherited (seed, emission over time/distance or burst). Of course the engine would halt and warn the user if the linked emitter is already inheriting emission from another emitter.

    An example of effect benefits from the emission seed inheritance is that you can overlay the glow particles directly on another set of particles with different material. If this is done with Sub Emitter, the glow sub emitter must use high emission rate (either over distance or time) to allow its particles to exactly overlap the spawning particles when they move, but with the issue of undesired flickering glow, not to mention the unnecessary emission just for the follow-me behaviour.

    EDIT: Changed the title of the "Inherit Emission Seed" module to "Inherit Emission" indicating emission seed isn't the only inherited value.

     
    Last edited: May 29, 2017
  22. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    https://feedback.unity3d.com/suggestions/shuriken-particle-simulation-speed-with-animationcurve

    Another suggestion which can be easily done via script but would be very helpful for pure artist.

    The "stasis effect" I mean in the ticket is similar to this speckle effect from Final Fantasy XII at 0:08. I understand the said effect in FF12 doesn't use animated simulation speed at all but likely simple animated curve of velocity over lifetime of y-axis (world), it just gives you graphical reference.

     
  23. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    Last edited: Jul 25, 2017
  24. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    Bug report 943649 which happens only in 2017.1 about Invalid WorldAABB errors when particle effect object transform.position is controlled by script and it spawns sub particles on collision. There is also report on Answers about the same error messages in case that person hasn't filed a bug report. Disable the position script and move the particle object manually against the collider repeatedly does not trigger the error, but the collision behaviour is so different than 5.6 that the "interior collisions" parameter is missing in 2017.1 and assumes always "true" which is something I want to learn an alternative. The particle effect attached in the bug report is the one I don't want it to trigger interior collision (as well as "exit collision").
     
    karl_jones likes this.
  25. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    I filed a bug ticket about how trails module changes the behaviour of sub emitter on death or collision undesirably. The QA member how reviewed my ticket did not classify it as a bug so I requested closing the case and may file a suggestion ticket instead.

    https://feedback.unity3d.com/sugges...and-death-messages-property-for-trails-module

    Generally a particle sends “death” or “collision” messages for spawning sub emitter as intended unless you have enabled Trails module without checking “die with particles”, the death message is only sent after the trail is dead as well. If the particle is already dead upon collision (life loss = 1 in Collision module) but the trail is still alive, it will continuously send collision message. The result is either sub emitter spawned much later than expected (on death) or excessive amount of sub emitter being spawned (on collision). The collision one can be alleviated by giving small amount of bounce (0.1) but it doesn't guarantee spawning sub emitter correctly and the trail is visibly crooked upon collision. I hesitate to enable "die with particles" unless it's for mobile, killing the trail abruptly just doesn't look good. Or I can replace the trail by stacking small glow sub particles on birth, skyrocket transparency overdraw.

    Now I propose a new boolean option in Trails module, something like "send death/collision message" and set false by default because most of the time a particle trail is meant to be ornamental, not influencing sub emitter spawning result.
     
    Last edited: Aug 31, 2017
  26. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    @richardkettlewell Check the (closed) bug ticket 942619 for the collision/death message from particle trails. The "issue" exists since the implementation of Trails module.
     
  27. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    I skipped 2017.2 and head straight to 2017.3 beta now. Besides the just reported bug of emission rate over distance (955733), I want to confirm if "start delay" is intentionally disabled for sub emitter on birth.
     
    karmington2 likes this.
  28. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,620
    That is disappointing to hear; they are both things that seem to break quite often, which I can only apologise for. I'll take a look at both and make sure we are well covered by automated tests to prevent it happening again in the future. From a quick glance, it looks like the sub emitter start delay is broken in 2017.2, and QA have reported that 955733 is only broken in 2017.3.

    Thanks for reporting.
     
    hippocoder likes this.
  29. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
  30. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    790
    @richardkettlewell
    Will there be an option to use the noise module for spawn-density as well?
    The noise module can already generate 3D noise.
    So it should (I really don't know) be simple to use that output to determine how much particles to spawn at each point inside a Box-Shape particle spawner.

    Or is there a way to already do this that I just missed?
     
  31. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,620
    We have nothing planned for this currently, but we can add it to our roadmap. I'm not sure it's so simple to add :)
     
    Torbach78 and dadude123 like this.
  32. Archanor

    Archanor

    Joined:
    Dec 2, 2013
    Posts:
    465
    Is there any way to use the same noise-pattern (seed?) between two particle systems? Could be useful for syncing the movement of systems.
     
  33. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,620
    If they are both set to World Space Simulation, and have specified the same Random Seed, they will share the same noise field :)
     
    varfare and Archanor like this.
  34. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    Will setting the same Random Seed on emitters with Local Space Simulation work too?
     
  35. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,427
    @richardkettlewell is the current shuriken still using the old quad per particle or is there an adaptive particle shape (the particle shape are closely fit to the current sprites/textures used) option somewhere?
     
  36. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    I mean it's super easy to test it by yourself. If you set local space for all particle systems sharing emitter seed, their noise patterns will behave identitcally no matter how you posit or rotate the emitters. In world space, if the positions and rotations of emitters differ they don't move the same way, but you can tell they share the same space of the noise pattern.
     
    richardkettlewell likes this.
  37. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    You can customize your own mesh for particle system and set "facing" of "render alignment" in renderer module which can be seen as "mesh billboard mode".
     
    richardkettlewell likes this.
  38. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,427
    Oh never tried that, thanks for the info
     
  39. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    About the new auto-destruct/disable in main module, my issue is it doesn't check its child particle systems, especially sub emitters, leading to abrupt ending of the effect.
     
  40. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    Just realized that 2017.3 (maybe 2017.2 as well) spams warning logs when (Skinned) Mesh Renderer shape mode is chosen but no Mesh Renderer is assigned. I understand why it happens but it doesn't feel necessary in Play mode, instead it's more constructive to fallback to "no shape selected" (as if Shape module is disabled) status so particles are emitted just from a single point of object's position. This log is better to be shown once in Edit mode when no Mesh Renderer is assigned and the user begins simulation manually only.
     
  41. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    Is Sort Mode and Sorting Fudge is not available for trails? Most of the times I set Render Mode to None as I don't want to render main particle, just the trail itself. But with RenderMode:None all render-related options are gone.

    I have the same issue with Custom Vertex Streams. They are not available if RenderMode is set to None but setting it to none is the only way of getting rid of the main particle. Sure, I could set Size to 0 and set Trail size independently in the Trail module but this is a silly workaround.

    I find naming very odd. Render Mode applies only to the main particle. Ribbons and Trails are not affected by all of these modes. To disable rendering for them I need to disable Trails/Ribbons module. This is confusing because nowhere in the Renderer tab an information can be found that Render Mode only applies to main particle. Tooltip says: "Defined the render mode of the particle renderer". I thought that Particle Renderer is responsible for rendering everything that a emitter produces, not just main particles.
     
  42. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    Also just realized cast shadow and receive shadow need to be shown for particle trails (none render mode).
     
  43. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,620
    Correct - currently the trails cant be sorted, so the sort mode is hidden. We are looking at adding support for it, either as a separate option, or by hooking in to the existing option. Any preference?

    You’re right though that sorting fudge, cast and receive shadows should be displayed. We will fix that. A workaround if you’re desperate would be to set them up via script.

    EDIT: Actually, an even easier workaround: just set the Render Mode to Billboard, set the options up, then switch back to None :)
     
    Last edited: Nov 20, 2017
    varfare likes this.
  44. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    Hey, thanks!

    But I have another question :p Is there a way of disabling trails rendering without disabling the trails module? Let's just say that I want to use trail data to render something else or just use that data to drive behaviour of something but I don't want to render them at all. I did exactly that for my contest VFX.


    I used particle data (motion, size etc) to drive behaviour of my custom shader. Let's just say I want to do the same thing but for trails. Disabling Trails module means that no data will be generated at all and setting Size to 0 means that I will loose Size data (it will be equal to 0). I could use a custom material which render nothing but that's a waste of performance.
     
  45. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,620
    Interesting idea! There's no way to do this currently.. no way to disable trail rendering and no way to access the trail geometry to use for something else. We can add it to our roadmap though :)

    FYI we are working on a new API to bake particle geometry out to a mesh. This would give you a way to access the trail geometry to use for some other purpose, although copying the data may not be the most efficient approach.

    I am familiar with your RTVFX contest entry, I looked at a few people's entries when the competition was running. Yours was excellent - a worthy winner!
     
    varfare likes this.
  46. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    Thanks man but that would not be possible without all new features you guys added this year! And I mean it - without custom vertex streams I think it would be much, much harder to achieve if at all.
     
    richardkettlewell likes this.
  47. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    @richardkettlewell How would you approach pixel perfect movement of particles? I am developing pixel-arty style game which means that everything that renders must be snapped into pixel grid to avoid any visual jittering. My game is using 32 pixels per unit, this means that one pixel is equal to 1/32=0,03125f.

    I had this idea to use Get/Set Particles on OnPreRender event, snap all particles to my pixel grid and during next frame, before all particle updates occurs, I would set them back to the original position (non snapped location), let Particle System update position and snap them to pixel grid again before they render. But I realised that there is no such thing as OnPreParticleUpdate or anything like that so my whole plan failed. I could snap positions of particles in vertex shader by passing particle location but I would rather use Custom Data for something else.
     
  48. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,620
    Hey, so I think you could use LateUpdate to do the snapping. It runs after the particle simulation.

    However, if you could do it in the vertex shader with a custom shader and custom streams, the performance would be far better (unless you have spare CPU performance to burn)
     
    varfare likes this.
  49. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    That's a really interesting bit of information! Is there an even which happens before particle simulation? I'll probably use vertex shader to snap particle positions to pixel grid but it would be still worth knowing events order for particle system.
     
  50. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,620
    Update happens before Simulation, and LateUpdate afterwards :)
     
    varfare likes this.
unityunity