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. karl_jones

    karl_jones

    Unity Technologies

    Joined:
    May 5, 2015
    Posts:
    4,261
    Hey.
    That sounds interesting. Is this available to watch one one of the Unite videos?
    As far as I know we don't currently have plans for GPU accelerated particles however we are currently moving over to a new SIMD math library which should provide improved performance. We also have various other changes, keep an eye on the roadmap :D
     
  2. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,726
    Hey :)

    https://www.assetstore.unity3d.com/en/#!/content/46208 +
    (unite talk)

    And regarding combining offscreen with soft particles, it always felt like as you have to render to texture behind the scenes, it may as well be less waste to combine.

    SIMD sounds really cool! Was there a practical reason for not using GPU accelerated particles (just curious really)?
     
    karl_jones likes this.
  3. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,163
    Awesome! I didn't know this was possible, thanks a lot. I did some tests and it seems to be a bit faster.
     
  4. karl_jones

    karl_jones

    Unity Technologies

    Joined:
    May 5, 2015
    Posts:
    4,261
    Thanks I'll check the video out. To be honest I am not sure about the decisions regarding GPU particles or what the future holds in that area, perhaps @richardkettlewell can shed some light ;)
    I do know the SIMD work is unrelated, its more us trying to take advantage of some engine wide improvements/features.
     
  5. SugarChap

    SugarChap

    Joined:
    Jan 19, 2015
    Posts:
    22
    What a great thread!

    Who are you?


    I'm Adam Langridge, have made big games (Black & White & Fable Franchise) and small games (Marvellous Miss Take). Am part of a small Indie team called Upstream Arcade.

    What kind of game are you trying to build or would like to build?

    We're making a highly stylised, 3rd person brawler inspired by retro comics.

    How does particles fit into that? What use-cases do you have?

    Everywhere! Explosions! Dust! Smoke! Impacts! Sparks! Blood! Debris!

    What are the GOOD things about the particle system now you like?

    Seems like a pretty solid editor so far. I made the particle systems used in Black & White 2 and there's plenty to like here.

    What are the BAD things about the particle system now you dislike?

    The limited (but improving) feature set for mesh particles.

    How can we make it BETTER?

    We'd really like to have more expressive mesh particles, which would involve non uniform scaling (per axis). This would allow us to have stylized mesh smoke systems (where the clouds drift up, slow and then flatten before dissipating). It would be extra useful if this could be applied either before rotation, or after rotation (allowing us to have variety of shapes introduced by rotating meshes, but still flattening them later on in their lifetime).

    Another great feature would be to pre-align mesh particles based on different factors (for example their velocity) which allows us great effects like sparks flying around.

    Thanks again, looking forward to your thoughts.
     
    richardkettlewell likes this.
  6. ninjapretzel

    ninjapretzel

    Joined:
    Jul 19, 2011
    Posts:
    26
    I dunno if this have been mentioned before, of if it has, but the built-in soft particles SUCK. It would be nice to have some control over how fading/soft particles even happening at the material level. I have some particle systems in a game that NEED to be seen, even if they are close to surfaces. Soft particles makes these invisible, and makes the effect completely lost.

    Having one global project 'soft particles ON/OFF' isn't good enough when individual systems need tuning, and we need to be able to tune more than just what the "_InvFade" property lets us right now.

    I'd like to be able to control the depth to begin fading, as well as the length of the fade, so that some particles could be completely visible for when above a surface, but quickly fade to zero from the surface to just below a surface, and at the same time, have other particles start fading a distance above a surface and gradually fade to zero below the surface.

    Example- Scene paused - only the 'soft particles' setting is changed
    (Besides the particles, only an animated shader that is re-rendered every frame changed)
    Soft particles ON:
    http://puu.sh/mfkhi/da5be70ce9.jpg

    Soft particles OFF:
    http://puu.sh/mfkim/720a053bbf.jpg

    Needless to say, we won't be using soft particles for this project, even though there are some areas where it would make an improvement.
     
    Last edited: Jan 1, 2016
  7. Jingle-Fett

    Jingle-Fett

    Joined:
    Oct 18, 2009
    Posts:
    566
    Here's another suggestion...right now we can use meshes as particles. Why not go all the way and allow for actual gameobjects/prefabs? Other particle system packages like Thinking Particles for 3ds Max and Element3d for After Effects just treat everything as a particle, regardless of geometry or hierarchy and they're quite powerful because of it. Being able to use prefabs as particles opens the door to components like trail renderers, lens flares, lights, etc. applied directly to particles, as well as more complex particles capable of reacting to stuff or playing animations--like if you wanted to make a death gib particle system where limbs have ragdolls and stuff like that. Doing this would also make it easier for users to customize the particle systems to their needs since we can add regular scripts to the prefabs.
     
  8. McMayhem

    McMayhem

    Joined:
    Aug 24, 2011
    Posts:
    443
    Who are you?
    I am a meat Popsicle currently employed to specifically use Unity for rather unspecific applications.

    What kind of game are you trying to build or would like to build?
    Isometric cyberpunk rpg (more than 8 bits).

    How does particles fit into that? What use-cases do you have?

    The same way particles fit into any game. I can't think of a scenario aside from the smartass reply of "Ho ho ho, what a bout pong? No particles!" that you *wouldn't* need to use particles. But yea everything from combat to ambiance.

    What are the GOOD things about the particle system now you like?
    +Great performance so far.
    + Nice bells and whistles such as collisions, message sending, normal direction, billboard type, curve editors for interpolations such as velocity, scale, and rotation. All great stuff.
    + Sub-Emitters save a lot of development time
    + Randomization capabilities make particle systems naturally unique in look from one another, even if it's a clone. Great for impact effects and explosions.

    What are the BAD things about the particle system now you dislike?
    - About as customization as a tomato.
    - Little to no access over variables from code or from the animation editor.
    - No control over pivot point means that you can't have randomized rotation for stretched billboards.
    - Stretched billboards in general need a lot of love. Currently, you need to spend a lot of time to make those kinds of effects look nice. Thought they do look REALLY nice when you get it right.
    - No multi-editing.
    - No ability to randomize or curve certain values such as gravity.
    - Emission control is rudimentary at best
    - Restrictions, restrictions, restrictions.

    How can we make it BETTER?
    > Take the time and rework the Stretched Billboards section.
    > Allow us to set the sprite pivot. For any kind of billboarding this should be very simple to do. Hell you could just put a grid on there with X/Y axis and a red dot that you can drag around to show where the pivot is.
    > GPU particle effects (really though, this should have been part of Unity 5 right from the start)
    > More options for controlling Size/Color/Velocity/etc over lifetime. There should be only 1 category for each of these and then a drop down list for how it is effected.
    > Change X By Distance - This one needs a bit of explaining. Currently you allow for a change in color over lifetime which is great, as it allows for us to "fake" lighting of particles and other goodies. However, in order for it to look any kind of good, you then have to set the particles to a static lifetime. Allowing us to lerp values by distance from start point would give us much more power, and it's stupidly simple to implement that.

    My best advice though? Ditch the inspector-based editor and do something unique. Particles feel a bit like an after-thought right now. Like someone said "eh, we don't really NEED to have our own particle system, let's just toss this together."

    A highly customizable, node-based editor would work wonders. I'm talking mainly about the particle system tool in 3dsMax which allows for adding/connecting any amount of nodes that do different things. This would allow us to have better control over particles without having to add more systems to get the better effects we want.

    There you go. Those are my feelings. Do with them what you will.
     
  9. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    9,295
    Soft particles are great! Unity's shaders are unfortunately just designed with a very specific game scale in mind, a third-person-with-units-in-meters scale. If you're doing a first person game with units in meters or a scale larger or smaller than that the range available is terrible. The other problem is the way Unity (and many other games) do soft particles is to have a constant depth blend distance for a particle system when really in most cases you want a blend factor scaled by the particle's size. I implemented this, plus particle camera depth push, for a game I'm working on using geometry shaders, but 5.4's additional particle data will hopefully make that additional expense unnecessary, though I don't know if they implemented an Unreal style data mapping for the additional per particle vector data. Doing particles using an instance geometry style particle system would also remove that requirement, but they'd most likely implement such a change like they do with GPU skeletal meshes with two passes where the final pass will have lost all that useful information again.
     
  10. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,163
    I have a scale close to RTS perspective, with 1 unit = 1 meter, and the soft effect is lost almost completely. I don't know how it works internally, would it be possible to compensate for this with simple changes in the shader?
     
  11. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    9,295
    The Soft Particle Factor range of 0.01 to 3 translates to a fade distance of 100 to 0.333; internally the shader calls it the InvFade as the factor is actually equal to 1.0 / Fade. Shader wise this is a very simple idea, take the depth buffer depth at a pixel and the poly surface depth and subtract one from the other and multiply it by the factor. The easiest modification is to make a copy of a particle shader and change the ranges, say to 0.001 and 1000, and maybe make the range a [PowerSlider(10)].

    Download the built in shaders from https://unity3d.com/get-unity/download/archive
    Find the particle shader you want to modify, and copy it into your project and look for this line:
    _InvFade ("Soft Particles Factor", Range(0.01,3.0)) = 1.0
    Change it to:
    [PowerSlider(10)] _InvFade ("Soft Particles Factor", Range(0.001,3.0)) = 1.0

    You could do more modifications like change it to a divide which would make the factor be the actual fade distance in units, and maybe change the falloff to be exp or pow which might look nicer than a linear fade.
     
    Martin_H likes this.
  12. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,163
    Awesome, thanks a lot for the help! I'm gonna try that!

    Edit: works like a charm :)
     
    Last edited: Jan 2, 2016
  13. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    @karl.jones is there any way to get UV not modified by "Texture Sheet Animation" module into my vertex shader input? I have tried accessing uv, uv1, uv2 but they are all dependent on this module.
     
  14. karl_jones

    karl_jones

    Unity Technologies

    Joined:
    May 5, 2015
    Posts:
    4,261
    No I don't believe its possible. If UV animation is enabled then it modifies all UV channels.
     
  15. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    9,295
    That's extremely unfortunate as you're rarely using the additional UV sets for actual texture UVs with effects. They're almost always extra data like pivot points, mask weights, etc., ie: stuff you don't want mucked with by flipbook animation.
     
  16. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    Hmmm. I think that only first UV channel should be modified by flipbook module. This way you could still use additional UV channels for other stuff such as texture shifting over your particle. Right now I have to multiply my UV inside the shader by amount of rows and columns assigned in texture sheet module. In result of this, I have to create many material copies which are exactly the same but have different UV multiplication parameters. Not very robust.

    Also, what happened with custom per particle vertex data? It was on the roadmap for 5.4 but now it's gone.
     
  17. karl_jones

    karl_jones

    Unity Technologies

    Joined:
    May 5, 2015
    Posts:
    4,261
    Would you prefer to have an option to select which UV channel/s to animate?

    I'm not sure about the custom vertex data, did you mean this?

    Its in the investigation and design work section so maybe it was delayed from 5.4.
     
  18. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    Yes, I'd love to choose which UV channel should animate - the more customization the better effects can be done.

    That's exactly what I meant. It is one of the most important feature for me. Thanks for the info.
     
  19. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    9,295
    Agreed, on both counts. I'm sad to see the vertex shader and particle lights being pushed back to investigation, but I can understand it considering the way the current particle system works.
     
  20. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,644
    We are working on allowing you to choose which UVs are affected by the flipbook animation, and hoping to release it in 5.4!
     
  21. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    Cool, it will be another huge improvement for Shuriken in Unity5! Do you think that it will be also possible to expose some kind of flipbook animation data for particle shaders? I want to implement smooth frame-to-frame blending (the same way UE3/4 Cascade does). It is currently not possible because there is no "lifetime" or "current/next flipbook texcoord data" exposed.
     
  22. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,644
    The Z component of the 2nd UV channel actually has the blend value in it. So if you are comfortable writing your own shaders, you could take a copy of one of the particle shaders and modify it to perform 2 texture reads and blend between them using this value. However, this is undocumented and therefore is prone to change in a future release. (I should also mention that I've never tested this out myself.. I've just seen it in the code, so it may not even work!)
     
    varfare, bgolus and karl_jones like this.
  23. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    9,295
    There doesn't happen to be some hidden value being passed to the material for the flipbook col/row numbers, is there? Not exactly super important since a material is going to have that fixed ahead of time, more just curious.
     
  24. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    That would make sense. I had this problem where particle nomal map's strength was modified while texture-sheet animation module was turned on. So maybe my surface shader was using this UV2.z for normal map and it went dimmer/stronger over time. I need to do some research on this.

    http://fogbugz.unity3d.com/default.asp?706060_ngea0ot325f1f159
     
  25. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,644
    I don't think so, no, sorry!
     
  26. czapata24

    czapata24

    Joined:
    Jan 31, 2014
    Posts:
    2
    Who are you?

    Charles Zapata, founder of indie studio Escape Fuel in Redmond, Washington.

    What kind of game are you trying to build or would like to build?


    We are working on “Commander Kamala Lays Down The Law!”, a space shooter. See http://www.commanderkamala.com.

    How does particles fit into that? What use-cases do you have?


    We use particles for combat effects: emission/discharge/muzzle flash, hit effects, energy glow of charged particles, agent state (e.g., “electrified”.)

    What are the GOOD things about the particle system now you like?


    For getting basic sprites moving and alpha-ing about the screen, it works well.

    What are the BAD things about the particle system now you dislike?


    There are still a few weird edge cases around immediately creating a particle on a specific frame. I find I have to play a few games with Looping/PlayOnStart and GameObject.setactive to get the particle to emit (and stop) exactly when I want them to.

    How can we make it BETTER?


    (1) HDR particle color. (This is the reason I hunted down this thread.) We use particles for fast combat effects, which means we want them to be more intense than anything on the screen, AND we’d really like to bloom them out, because bloom looks wonderful for energy and fire effects. However, we don’t want to bloom the rest of the scene. What we are doing is lowering intensity across the entire game so that we have a thin band of intensity that we can set our bloom threshold at. Basically, poor man’s HDR.

    (2) Particle orientation on start. Right now the stretch billboard renderer sort of does this, but it seems a bit of a hack (ee.g, now I have to add speed to get direction.) I’d love the ability to orient the particle with the direction of the particle system for directional (asymmetry) particles.

    (3) The emit-a-single-a-particle-right-now problem as described above.
     
  27. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,644
    I've added (1) to our Roadmap.. it has come up before, it's a good suggestion. A workaround right now would be to use a custom shader and set up a color multiplier parameter to boost particle colors above 1.0.

    Regarding (2), you should be able to do this as of Unity 5.3 - Use one or both of "3D Start Rotation" and "Renderer: Billboard Alignment" to choose a starting rotation in full 3D, and also choose whether particles face the camera, the world axes, or remain oriented local to their Transform.

    I think (3) might be a bit better in 5.3 or 5.4, but it would be worth submitting a bug with a reproduction case, so we can see the exact problem. Or maybe it's already logged?

    Thanks!
     
    varfare likes this.
  28. theskyjoker

    theskyjoker

    Joined:
    Sep 23, 2014
    Posts:
    2
    gameplay engineer in a small indie studio.

    an fantasy action & moba game on mobile devices, which presents a dozen of characters fighting with quite a lot of effects in the screen.

    The particle system is the main tool of our fx artists. And the major use-cases in our project is effects made by 5~10 particle system for about 5 particles per each.

    It's powerful and agile to use, capable for most type of effect animations and artists can animate those quads very swiftly

    Our artists are good at using a few quads with different textures to create good-looking effects. Which means not many particles but quite a lot particle systems and many set-pass-calls (about 200+ in extreme cases), which could kill the performance on low-end mobile devices.
    And the most annoying thing is, it's hard to do batching. Even we can't pack textures into a big one, we have not access for setting ups to shuriken. The tricky thing we can do is to use the 'texture sheet animation' of shuriken to modify uvs, but only in a limited way and have to waste a bit cpu time.
    Another thing is in 5.3 particle systems can no longer be batched, we really need this feature back.

    1.simpley allows set up uv in the particle system?
    2.or make particle system compatible with sprites? (good for auto batching and easy using)
    3.and better to bring the batching back. Draw calls are also not that cheap for mobile.
     
  29. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,433
    is this thing still work until now? might be usefull to be able to blend flipbook frames.
    also is there a sample to create custom module? yeah i'm basically looking for somekind of Dynamic Parameter for shuriken
     
    AndrewGrayGames likes this.
  30. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,433
    Btw you guys saying that particle can be lit by using LPVolume, but there's no built-in particle shader that support LPVolume
     
  31. Archanor

    Archanor

    Joined:
    Dec 2, 2013
    Posts:
    470
    This is not my idea, but from someone who purchased particle system effects from me. He was commenting on how time consuming it can be to find the correct prefab, as you have to drag and drop the prefabs into the scene to preview them.

    So maybe a sort of preview window in the inspector could come in handy for those who browse particle effect assets. Personally I wouldn't want it enabled all the time, but having it as an option would be nice.
     
    varfare, angrypenguin and Martin_H like this.
  32. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,644
    I've looked at this in more detail and can confirm that the 2nd UV + Blend Factor are actually in the Tangent stream. (xy=uv, z=blend factor). However this is undocumented, and I can guarantee you it will be changing, because it prohibits Normal Mapping from working, and we have a new improved solution coming in Unity 5.5:

    For Unity 5.5, we will be introducing a new feature allowing you to choose what data gets sent to your Shaders. For example size, rotation, speed etc. This includes the ability to:
    - Send Tangents to your shaders, to support Normal Mapping
    - Use the Standard Shader on your particles
    - Send the 2nd UV stream and the blend factor in via a Texture Coordinate channel. A new built-in shader is provided to make this accessible for all users.
    - Lots lots more!

    Regarding a custom module, the only way to do anything like that would be via GetParticles/SetParticles in a script. There is an example of its usage here: http://docs.unity3d.com/ScriptReference/ParticleSystem.GetParticles.html
     
  33. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,644
    You're right - we are working on this at the moment :)
     
    Reanimate_L and karl_jones like this.
  34. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,433
    Oooh seems it's time for a new blog post about particle future?? :D
    and is there any sample how to use the blend function at the moment?

    No worries, there's a sample of the code in LPPV blog post anyway.
    Just want to make sure that this is planned since not everyone write shaders :)
     
    Last edited: May 17, 2016
    richardkettlewell and karl_jones like this.
  35. Ukitakemalcom

    Ukitakemalcom

    Joined:
    Nov 10, 2015
    Posts:
    19
    We are an independent game development group.
    We are working on a RTS/Moba type of game with characters in 2D (sprites) and the world in 3D.
    We use Particle Systems for all kind of attacks, effects, etc.
    We would like to use particle systems in 3D with sprites but right now we can only set the SortingLayer and the OrderInLayer of the entire particle system and not of the individual particles.

    We asked about this topic in the forums but the replies said that it was not possible with the current system.

    So, we are asking here for a way of setting individual orderInLayer of particles to make them be in front or behind a sprite.

    Thanks for everything
     
  36. Wahooney

    Wahooney

    Joined:
    Mar 8, 2010
    Posts:
    275
    @richardkettlewell, something that is coming up more and more in our work is that often you want a single particle system with multiple emitters. (ie. trail on a rocket/missile, where you want the particles to animate away rather than being killed immediately when you remove the missile on hit)

    I've written my own scripts to handle this, but a native solution would probably be better.

    The tricky elements are spawning by distance, spawning a pre-warmed system, inheriting velocities, etc. I managed these in my implementation, so doing it with backend access should be a breeze.

    Any thoughts? Are there plans for this?
     
    Martin_H likes this.
  37. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,644
    You mean something to let you effectively specify multiple Shape Modules? (Each one with its own Transform, I guess, too)
     
  38. Wahooney

    Wahooney

    Joined:
    Mar 8, 2010
    Posts:
    275
    Partially, yeah.

    A great byproduct of how the system currently works (with ParticleSystem::Emit()) is that you can actually set up different starting lifetime, velocity, size, color, etc. per emitter. So you can have different coloured smokes, different sizes of debris, etc. from a single system and multiple emitters.
     
  39. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,163
    Wouldn't all this be better solved if there was some sort of dynamic batching for particle systems? That's what I'd personally would love to see. I've tried for a long time to "manually batch", but I got bad sorting issues between different particle systems and had to resort to using hundreds of individual ones again.
     
  40. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,644
    There is dynamic batching for particles :)
    But there is no global sort of particles in a batch. I suspect that is what you are hoping for with dynamic batching.
     
    Martin_H likes this.
  41. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,548
    What about GPU hardware accelerated particles?
     
  42. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,163
    Huh, indeed there is! I wonder what gave me the impression that this isn't there. Google says there was a time where it was deactivated after some update and it got re-introduced later. Might be that I mostly used that version back then and currently I had lights attached to many particle system objects, so that made a massive drawcall increase correlate with spawning the particle systems, but it wasn't the cause. Thanks a lot for pointing this out!
     
    richardkettlewell likes this.
  43. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    The more I work with Cryengine the more I think that Unity should get Emitter Rotation module. Cryengine calls it "angles"
    http://docs.cryengine.com/display/SDKDOC2/Particle+Editor+Params#ParticleEditorParams-Angles

    It is really useful when you want to make your particle effect more random and natural looking. Its especially handy with explosions. I often use this feature in CryEngine to set random rotation of debris&sparks emitters. This way every explosion shoots these pieces in random directions.

    In my imaginary Emitter Rotation module I would have these options:
    * X, Y, Z rotation (float, random floats, curve, random curves)
    * Rotation space: local, world
    * Rotate the object (bool). If set to yes, then you actually rotate the gameObject so every child will rotate with it. If set to false, you only set emitter's rotation (children are unaffected).

    Current "Randomize Direction" implementation is somewhat tackling this problem but it is really unpredictable and imprecise.

    Also, what is the correct way of having a trail particles which do not render the main particle at the beginning? Let's just say that I want to render the trail only and hide the trail's head.

    BTW. I've been using Unity since 3.5 and I am really glad to see all those improvements to Shuriken. It's shaping up nicely!
     
    Martin_H likes this.
  44. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,644
    I'm not familiar with all the features of the Angles feature in Cryengine, but from your description, plus the link, it sounds a bit like our 3D Rotation Settings/modules, combined with the Alignment setting in the Renderer Module. Let me know what's not possible, and we can look at adding it :)

    In the Renderer module, set the Render Mode to none.
     
  45. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
    I think the "Angle" module also needs the "pivot" parameters as I have suggested in Feedback page:
    https://feedback.unity3d.com/suggestions/particle-emitter-pivot
     
  46. ifurkend

    ifurkend

    Joined:
    Sep 4, 2012
    Posts:
    349
  47. Archanor

    Archanor

    Joined:
    Dec 2, 2013
    Posts:
    470
    Got a few ideas lately..

    1. Not sure if this is possible, but it would be very interesting to see a Stretched Meshes renderer mode, similar to the Stretched Billboards!

    2. Something that could be interesting when emitting particles from a Mesh is for the particles to be locked to the surface of the Mesh. So even if you have speed and noise added to the particle, they would travel alongside the surface.

    3. I'm sure there's other ways to do it, but perhaps a "Timescale" option to slow down or speed up an effect could be handy. Often when I want to change the "speed" of something, there's a lot of variables to tinker with. Double the Start Speed, halve the Start Lifetime, adjust the Velocity over Lifetime, Gravity etc.
     
    richardkettlewell likes this.
  48. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,644
    I can hopefully answer this part easily - we added "simulation speed" in 5.5, in the main settings.
    Prior to 5.5, this variable existed, but was only settable via script.

    Thanks for the feedback!
     
    Ryan-Gatts, karl_jones and Archanor like this.
  49. Archanor

    Archanor

    Joined:
    Dec 2, 2013
    Posts:
    470
    @richardkettlewell Oh snap, I've been using 5.5 for a few weeks without even noticing it..
    Thanks for pointing that out :)
     
    richardkettlewell likes this.
  50. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    It is possible to create a simple script that sets random rotation for the emitter with separate X,Y,Z axis controls etc. We have a transform component for this, right? ;) But here is the problem:
    If you have a hierarchy like this:
    Parent A
    Child Aa
    Child Ab
    Child Abc

    Let's just say that you have a script that sets random rotation via transform component. Rotation is set with every new loop cycle. You attach this script to the Parent A. The problem is that you will rotate every single object in the hierarchy because you are literary rotating the game object, not the emitter. The only solution is to detach every child object before rotating and attach them again after rotation. Not very cool. Imagine the chaos that you'll introduce in editor mode with all the parent detach-attach changes. But let's make it more complicated. Let's say that you have another rotation script attached to Child Ab! How do you synchronize both scripts? This problem can grow exponentially the more complicated hierarchy you have.

    As I said before - current "randomize direction" parameter is pretty cool but it does not have enough control over how you rotate the emitter.
     
    Martin_H likes this.
unityunity