Since we have some folks from Unity ( @richardk ) looking through this forums I figured this would be the place to post some feedback on Unity’s particle system.
Please, keep this topic on-point, keep it professional and cut the emotional side of things to bare minimum. We all know how easy it is to give “feedback” on the Internet
So to start things off, I have some concerns on how Shuriken will fit into the new HD pipeline? I’ve read many Sebastien Legarde posts on new rendering features but I could find nothing on particle system. I would like to know what we should be expecting in terms of HD pipeline particle workflow.
Secondly, I don’t really like how Shuriken’s UI displays on two monitors. Sure, we can open separate Particle Editor window which has all emitters from within hierarchy displayed but I am missing multi-column display for a single emitter. Currently, all modules of a single emitter are displayed in one, really long column. This is fine for simple particle systems but things can be quite slow when I have to jump between top and bottom of that column. I was thinking that something in the fashion of 3ds max multi-column display would help:
Similar solution is used in Cryengine and I like it very much. In Lumberyard (which is based on CryEngine) they improved the system by bringing customizable particle system UI. You can dock each module into a different section of the UI. You can even create custom tab with modules which you use the most. Customizing the Particle Editor UI - Lumberyard User Guide
I personally loath Max’s basic particle systems and general UI, but I do agree the giant long UI can get a little crazy. Multi-column wrapping might help with that, maybe as a per-emitter toggle. Basically allow you to view a single emitter column wrapped or all emitters as they are now.
There are a few features of Unreal’s Cascade I miss when doing effects in Unity.
Non destructive muting / solo play of emitters:
Muting can be done by disabling the emitter’s renderer, but solo play is the one I really miss. It’s a button that lets you show only a single emitter at a time with out having to manually disable all the other emitters. Effectively it’s a shortcut to disable the renderer on all other emitters with out actually disabling them. Technically you can set more than one emitter in a system to be “solo”, so maybe “preview” would be a better term. I don’t remember what term Unreal used.
The basic logic is like this:
If any emitter has “preview” enabled, all emitters not set to “preview” are not rendered (but are still potentially simulated).
Name always at top:
Right now when you expand out the emitter long enough the material swatch and name scroll away as well. When digging deep into emitter modules it’s easy to have them get quite long and require scrolling. Once you do that the name scrolls out of view too. On especially complicated emitters I find I’ll often end up modifying the wrong emitter as it’s easy to loose track of where you are without the names of the emitters visible at all times. It’d be nice if that stayed at the top at all times no matter what. It would also be a convenient place to put the preview toggle.
Emitter module instancing:
Cascade’s UI makes this a bit easier to deal with and visualize as the workflow is directly manipulating and adding modules to emitters, and you can basically drag a module from one emitter to another while holding down a key and it’ll make an instance of the first module in the other emitter. This also colors the modules with a unique color in their UI to show they’re linked. Then you only need to modify that one module and all of the other emitters using that module will be updated. Shuriken’s UI isn’t really designed around this, not to mention the actual internal implementations of the particle systems are much different. Not entirely sure how I would go about implementing something like this for Unity, but I frequently miss it’s existence.
I work on mobile games and our tech guy said that “Particle systems are very inefficient since unity needs to serialize every single field in the particle even if we are not using it”. So he asked me to avoid using particle system as much as I can.
I don’t know if this affects performance or not. If yes, there should be an option to discard unused modules (Like Unreal i guess).
@richardk
I have Parent Emitter which has particles with random lifetime. There’s a Child Emitter which is a subemitter of Parent Emitter. How to I make sure that Duration of Child Emitter is always the same as Parent Emitter particle lifetime? Use case: I am creating water splashes for a cutscene. I am emitting few particles from Parent Emitter to create “trail” for Child Emitter to emit from. I want to reduce Child Emitter’s particle size over Parent Emitter particle’s lifetime so the result would be:
Before 5.6, Particle Systems did indeed use far too much memory. But in 5.6 we massively reduced their memory usage (something like 35kb for a default system, down to 5kb, can’t remeber exact numbers though).
This would only ever affect memory usage though, not performance.
If I understand correctly, I think you can use the Inherit Lifetime option in the sub emitter module for this. If a particle has a life of 5 seconds, and spawns a sub emitter particle after 3 seconds, the sub particle will have a lifetime of 2 (so the overall effect length is the same, whether the sub emitter spawns or not)
When using this mode, the sub emitter Lifetime becomes a multiplier. So a lifetime of 2, in my example above, would make the sub particle last for 4 seconds instead.
I want to reply regarding all the other feature requests/feedback in due course. We really appreciate you letting us know about this stuff! I’ll be back with answers to that stuff when I have time to go through it properly… feel free to leave more feedback while you wait!!
Hey, this one is easy to give you answers to, so here goes
I’ve spoke with the Animation team, and they agree, so I have made the change to use Auto mode by default on those 3 presets, which means they wont bend like that.
However, when upgrading, your old preset library will be preserved, so watch out for that. Once the fix lands you’d need to delete the presets in AppData\Roaming\Unity\Editor-5.x\Preferences\Presets and restart Unity I’ll land this change in 2018.1, I think…
This is a mistake on our part… somehow our circle emission has become non-uniform! I’ve made a note to fix it, thanks!
I’ve also added this to our roadmap, to improve the gizmos to provide more information about Arc and Thickness.
These are a couple fancier requests, but they’re things I desperately miss in every particle editor I work in.
Rotational Velocity Alignment - Velocity aligned particles, rather than being a flat plane that aligns it’s axis to the velocity, instead stay camera facing, but rotate to face the direction they’re moving. Cryengine does this and it makes velocity aligned particles more versatile because you no longer have to worry about them turning flat when they’re moving toward or away from you.
Cryengine also pulls some fancy stretching and squashing, so if a particle is moving side to side, it’ll actually stretch in the direction of it’s velocity, but if it’s moving toward and away it’ll squash down to a more square shape.
Align to Initial Velocity - This one is a rarer feature that I don’t see in most mainstream engines. The idea is to have a velocity aligned particle, but one that only aligns to it’s initial velocity. So it doesn’t change its alignment as it moves in other directions.
Last I checked, Stretched Billboard does what I illustrated in the first picture, where the particles will appear flat if you look at them head on.
Rotational velocity alignment means that the billboard will always stay camera facing, but will change its rotation to align with the direction it’s moving. So even if you’re looking at the particle head on, it will stay facing you, instead of flattening out and revealing that it’s a plane.
I second the “rotational velocity facing mode”. I made a video explaining how this feature should work. I took Lumberyard as an example (Cryengine3 and 5 have the exact same feature):
And this is how it works in Unity:
I think Cryengine/Lumberyard implementation is much more robust. When your texture is not very directional you can create fake “volumetric” effects as you never see straight edge no matter what the camera angle is. Also, Unity is doing something funky when stretched particle gets close to the camera. It looks like it’s flipping itself.
And this sounds like Align to Direction in our Shape Module
I think this is one of the issues with how paramaters are laid out. I don’t see how Align to Direction is related to emitter shape. This should be placed in Render tab. Logically there is no connection between spawn volume and how particle looks like. You may want to Align to Direction no matter what the emitter shape is. These inconsistencies are all over the place. I don’t know why Flip U and V are put in Texture Animation Sheet module. What if I want a static texture and still flip U or V? How is that specifically related to Texture Animation? And why all inheritance settings of sub emitters are accessible in Parent Emitter, not in the actual subemitter UI? Tooltips are sometimes quite confusing too. I have no idea what “Randomize Direction” does in the shape module. It says it’s increasing how random the direction is but istn’t the default particle direction random already? Small things like that are making the whole system slightly more confusing than it should be. I think some kind of UI refactor pass/sanity check would be very welcome.
Hey, I finally have some answers for this… sorry for my slowness
So for this, it’s a bit of a lame answer (sorry again!) … we are working on figuring this out, but haven’t got anything concrete to shader right now. But rest assured that we are looking at it!
This one is the main reason for my slow reply - it’s not really a particle-specific request, as it could be utilised by all Inspectors. As such, I’ve been speaking to the Editor team about this request. The result is to tell you that we like the idea, and are planning to prototype it to figure out how it could work.
I think we already have this. But I suspect when I tell you, you’re going to say that this is totally hidden away in a stupid part of the UI
So, if you have an effect with multiple nested emitters in the GO hierarchy, opening the Particle System popout Window, and toggling “Show Selected” / “Show All” will give you kinda what you’re asking for. It only hides emitters within the same hierarchy though…
What are your thoughts on that?
I’ve been speaking to the Editor team about this, as it pertains to more than just Particle Systems, and it turns out they are already looking at making this happen, because it’s already agreed that it would be much better to work as you describe, for all GameObjects.
I agree this would be awesome, for both memory usage and less pain setting up similar emitters. It’s on our roadmap, but is a pretty big change to how it currently works, which means it’s a lot of work, which in turn means it’s not something we can deliver quickly. But it is something we agree with and care about Right now I guess you can save a bit of duplicated setup via Prefabs, and maybe soon even Nested Prefabs…
Ah right, yes, gotcha! Yes we will take a look at that. I think we’ll need to preserve the existing functionality, so maybe it will be a new checkbox on the Stretch mode… thanks!
I think you’re right, and I’d like to hear a complete list of things you think are in the wrong place, and where they should go. I don’t fully agree with all the examples in your post though…
This option simply applies a rotation to the particles when they are born, based on the shape. So I think the Shape Module is the right place for this. It’s not a render alignment, like stretch, or billboard, etc, it is a checkbox that sets up the initial rotation of a particle.
Yes I agree with this. I’ll speak to the team and see if we think we should move it.
I’m not sure about this. I don’t see an obvious place to move these options to. Consider that we have a place in the UI where the Parent defines who its Sub Emitters are, but that we have no place in the UI of the Sub-Emitter where properties relating to its Parent are defined. Adding a new module, or some new UI for this, could be equally confusing, leaving users with a Sub Emitters module, defining the children, and some other UI, defining relationships to the Parent. I’m open to suggestions, but right now all I see is ways to make it more confusing
I’ll take a look at improving the tooltip, though I’d suggest that’s pretty obvious if you just set up a circle shape emitter and then experiemtn with the property - particle directions default to something based on their shape (eg outwards from the circle, in my example). Randomizing the direction deviates this direction towards a random direction. The higher the value, the more the random direction is applied. It’s super simple to see this happening in the Scene View, but I’ll also try to make the tooltip more descriptive.
I did miss that, and it works exactly like I want. I don’t mind if it doesn’t hide emitters in other hierarchies. Playing with it I also never realized you could click on the material icon in the corner to select the emitter GO until now (or Ctrl+Click to multi-select). My first inclination was to left click on the name for that, which just collapse / expands the main node. Those two things combined means that feature does indeed exist! How long has that been there? I remember Resimulate and Show Bounds being there for ages, but I don’t think I ever noticed the Show: All, heh. It is hidden in a stupid part of the UI, but the “stupid part” here might be the User and not the Interface.
Awesome! It’s certainly not something I would expect any time soon, but I’m glad it’s something being thought about.
+1 for this as well. When it first showed up it didn’t even work for anything but sprite particles! This is definately something I would expect to see right under “Start Size”, a la “Flip Rotation”. I use it on almost everything now. For the particle systems I’ve written myself I’ve actually had this kind of feature default to “on”.
What I’m looking for the particle’s up axis to align to it’s initial direction, but keep it camera facing, like stretched billboards. If there could be a checkbox when using stretched billboards to have it align with the initial velocity and stay in that alignment for the duration of it’s lifetime, it’d be perfect.
I should actually ask how Shuriken will work with scriptable rendering loops but I guess the answer is the same. Good to know that you guys are working on it
Ok, maybe I was confused because I was envisioning that it should not matter what the emitter shape is. In my head this feature was simply aligning particles to their initial velocity direction - meaning that even with shape module disabled this option should be available (what if you have inherit velocity and shape module disabled and still want to use this feature?). But it seems that you have some shape dependencies in the code which are influencing the orientation of a particle (do I get this right?) so it makes sense to put it there.
Yea, I have a good understanding what this feature does after playing around with it but I remember my confusion after coming back to Unity after few weeks of not using it. Tooltip was saying exact same thing as the feature’s name which kind of makes the whole idea of a tooltip pointless I think the most confusing combo is Cone and this param. Cone has an Angle and Randomize Direction of 1 means that particle will have its initial direction set from anything between and Angle of 0 and whatever is set in Angle. Makes sense and it a good feature, but it’s not really randomizing the direction on all axis (if Angle=50 and Randomize=1 particle will never be emitted at 50+ angle, only in 0-50 range). Long story short, different tooltip should solve the issue
I agree and disagree at the same time, hah. With how subemitters work currently I think where subemitter inheritence settings are is the best choice. I am just not very convinced that this is how subemitters should work in the distant future. So the issue I have currently is that if I have a subemitter outside of its parent’s hierarchy (which Unity allows me to do) there is no “link” which would lead me to that parent emitter. I have to remember where it is. Meaning that whenever I need more data to be inherited, instead of changing these settings in the child emitter itself, I have to select parent, scroll down to subemitter section, enable more inheritance settings and go back to the subemitter. Just needs much more clicks in general than having these options in the subemitter itself. So maybe a workaround would be:
Add UI tooltip that this emitter is a subemitter
Have an option to select parent emitter somewhere on the UI (useful in cases where subemitter is not within parent emitter’s hierarchy
Show which options are inherited from a parent in the subemitter’s UI
) looking through this forums I figured this would be the place to post some feedback on Unity’s particle system.
I’ll land this change in 2018.1, I think…
I think the most confusing combo is Cone and this param. Cone has an Angle and Randomize Direction of 1 means that particle will have its initial direction set from anything between and Angle of 0 and whatever is set in Angle. Makes sense and it a good feature, but it’s not really randomizing the direction on all axis (if Angle=50 and Randomize=1 particle will never be emitted at 50+ angle, only in 0-50 range). Long story short, different tooltip should solve the issue