You can support HDR particle colors now with a custom shader and the custom data streams. Unity’s particle system has gotten a lot better in the last few years, but it’s still effectively a 12 year old particle system design that’s just now getting features most others had 10 years ago. They did just add support for using instanced meshes as particles which is nice, brings it up to an 8 year old particle system design. I’d love to have some of the power that PopcornFx has, but you’re very limited in the shaders available when using PopcornFx in Unity so that’s always been a non-starter for me.
The new Standard Particle shaders are a bit nicer than the old basic ones with a few new features, but they’re still quite basic. No attempts at adding support for any kind of psuedo volumetric lighting, or UV effects. And until the upcoming Scriptable Render Pipelines come out particles can’t receive shadows with out some spectacular hacks.
If you want GPU particles the are already some assets on the store, and some halfway systems on Keijiro’s Github.
If you’ve got the engineering to do it, writing your own particle system may be worthwhile for performance reasons as well, but it really depends on what your needs are.
Honestly I used to be really hung up on missing features, but after I learnt some basic scripting to fill in the gaps, I think the particle system in Unity is really, really powerful. If you’re comfortable with C# it’s really easy to create your own custom modules and particle behaviors, something I don’t think is equally approachable in Unreal.
Like mentioned, GPU particles is the big thing missing out of the box, so if that’s a must-have you might want to invest some enginnering time on that. In my experience, the issues I couldn’t create my own solution for mostly dealt with inherit issues with the engine rendering pipeline, which is undergoing some major changes with SRP being introduced.
If your VFX team is fairly hands-off when it comes to tech you might have to rely on a tech artist to field some feature requests. But if they’re tech-savvy enough to deal with Popcorn, I don’t think using C# to create their own custom features will be of any greater issue.
tldr: Unity’s strength is not that it has every feature out of the box, it’s that it’s flexible enough to let you decide how things should work. Your needs and resources should guide your decision, but as an artist I’d really recommend it
I’m currently working fulltime with Unity and PopcornFX.
Things I’d need from Shuriken to enjoy working with it:
HDR Color pickers in the particle editor.
GPU particles
Proper Subemitters
Attractors
Better Texture Sheet Animation controls
Lighting…
If you are working with VR, the option to disable Roll.
Spawnprobability
Lods
Better culling settings
Camera proximity fades
Heightfield snapping/collision
Particle softness controls
The ability to preview all emitters at once without selecting them all.
The list goes on.
Now, for Popcorn. It has a LOT of functionality but unless you’ve exhausted all shuriken options or you desperately need the performance I wouldn’t use it. There are still too many issues with it.
So far, I have yet to create an effect in Popcorn that just worked as expected in Unity first try. It always takes at least half an hour to figure out why it’s not showing up, why it’s the wrong size, why the color isn’t matching and so on. Add to that the fact that you can’t see them in the editor camera (depending on your project), and Unity stalls every time you shut down the game it makes for a remarkably slow turnaround time. Especially since you have to wait for the game to be completely shut down before you reexport from popcorn, even if you just changed one value, lest you risk a crash/bsod.
The popcorn team is great, but lately I have seen waaay more talk about getting it into iClone (what even is that!?) than supporting Unity or Unreal to be comfortable.
All the emitters in that effect will play then. But say I want a character effect to play on 8 different characters, triggered in a timeline, I’m fooked.
I only use Unity and i found it amazingly easy to learn and even master. Shuriken has come a LONG way imo
if we’re better off going with a 3rd party solution like PopcornFX
I think popcorn will give your team more flexability ; middleware is like having your own artist sandbox but when publishing in Unity there is something to be said for working in the deliverable format.
with that said getting Unity’s particles to play with animation(timeline) and characters (FBX imported) needs major tech support
it really comes down to team experience imho : If your team are rockstars at popcornFX they can (imho) easily learn unity and probably use both
As mentioned, this can be currently accomplished by using a custom data stream instead of the built in color, but it does limit what you can do as the custom data streams only animate over the normalized particle lifetime. However you can also pass any other data you might need or want (actual lifetime, speed, size, velocity, rotation, etc) to the shader directly and do your custom calculations there. In the end this can be far more efficient than doing all of the work in the CPU like PopcornFX and Unity both do it.
They got a lot better just in the last few months, but yeah, still a lot of missing (and last I checked minorly buggy) stuff there.
I’m actually curious what more you’d want here. The current flipbook controls have a lot more functionality than I’ve seen most places. They also added support for sprite atlas based animation.
Yep, this is one I’ve had to write for every project. Currently works via a script job that tracks the current camera and then counter rotates the sprites on the systems I’ve marked (with an attached component) just before rendering. I might look to move this to be part of my particle shaders instead so I’m not iterating over so many arrays every frame. I was pleased to see Unreal added this some time ago.
See the new Standard Particle shader they added with 2017.3+. A lot better implementation than the confusing “Soft Particles Factor” they have on the older particle shaders, and not clamped to ranges too small for large scale effects and too large for first person effects.
This is possible now, though it’s still not great, and still not built in which is perhaps the most important part.
Relatively trivial to add via scripting, but I agree. Unity has some very basic physics forces (basically just directional and spherical wind, and gravity) that you can have affect particles, but they don’t have built in attractors of any kind. It’s always struck me as an odd omission.
Yeah …
This was a feature that was requested when they were asking for features people wanted, and they consider it implemented … but they did it purely as burst emission count ranges which isn’t quite what those people were asking for.
Yeah, this is a big one. The usual response is to use Unity’s built in LOD system, but this is terrible for particles as it means when the LOD changes it just swaps to a completely different particle system, which means the particles are guaranteed not to line up.
Another one that’s relatively easy to do from script, and I believe some of the assets on the store that extend the particle system have this. In general there are a ton of more advanced features like this that Unity don’t seem interested in implementing on their own.
Curious about this one. What would you want specifically?
Yeah, most can be solved through scripting or materials. What I’m asking for is to have this in the particle editor, by default. No hacks, cheats or workarounds.
Texture sheets. I want to be able to set a framerate and just let it loop for as long as the particles lives. I don’t want to have to change cycles if I make it live longer and so on. Preferably, I’d be able to smoothly interpolate the framerate down over life.
Soft particles. Haven’t tried the new shaders, but again I want it in the editor. A slider or a value that I can set per emitter, not per material.
Culling settings. I want to be able to set a distance per emitter. If I have an impact made up of smoke, two debris emitters and a flash I want to be able to disable one of the debris emitters if more than 5 meters from player. Second one at 10 meters and so on. I’d like to be able to force a bounding box to a certain size. I’d like to disable culling so I can make an emitter spawn outside of frustrum etc.
@Partikel@michalpiatek you both mentioned the poor particle lighting support, or a lack of ‘proper’ particle lighting. What are the limitations you’re running into, or what features are missing that you would like?
@Torbach We will be VERY heavily interfacing with the animation timeline for our work. Are the issues you encountered with this primarily bugs, or just a difficult and/or cumbersome workflow?
Again, thank you all for the info. I’ve got a much better platform of knowledge to start from now =)
[as an example] I had to hand track particle systems to a collapsing FBX Mech. You can scrub through the mech animation but when switching to the VFX prefab the Mech just goes back to frame 1 – i had to hand place and do a ton of refinement which would swim horribly
also triggering particles systems using timeline is non existent in editor; you have to enter playback mode and it just slows down production
short of your own proprietary front-end/CMS system, it needs support
Thank you for sharing your feedbacks Andreas! @bgolus we hear you as well, shaders limitation is no more with the upcoming version (already used in production by some studios).
I can guarantee that teams are working hard to improve the PopcornFX integration and experience to ease both Unity and Unreal workflows, and Popcorn features at large! That’s a really useful thread for us, of course I don’t want to advocate “too much” on PopcornFX here, it’s great to have your feelings @Fenix@Partikel@Chris@bgolus@Torbach
As a short answer to the initial post, @Jaybles, we would be happy to discuss your needs anytime, we will always be here to help your teams concentrate on bringing added value, don’t hesitate to contact us!
This is a very useful thread for us here at Unity to read too I don’t want to derail it too much from the original list, but I’d love it if you wanted to DM me (or start a new thread) to discuss the following stuff:
I’d love to hear specifics about what you’d like to see added.
I see you elaborated on this in a subsequent post - we will get this on our roadmap, to add a simple FPS mode.
Agreed… this is on our roadmap already
Can you elaborate? @bgolus we don’t consider it done if people want something else what are we lacking here?
As discussed, these exist in the standard particle shaders in 2017.3, but maybe we can add per emitter overrides via material property blocks… you could actually probably write a script to do this right now
How would the heightfield be defined? (Do we have a heightfield component in Unity?)
We have this now in 2017.3 on the Scene View Overlay. You can choose which layers to preview. @bgolus why isn’t it great?
Tell me more!
Ive also neglected to reply to a few on your list… stuff like culling and lodding is known to be quite weak, but we don’t have any immediate plans to improve it. One day hopefully though!
I’m being a little harsh there, but it’s not uncommon for different requests to get bundled together as a singular feature or partially misunderstood. UVs for trails are a good example of that. It’s as much the community’s fault as Unity’s, you’re busy trying to actually get work done while reading through a lot of comments of varying quality level and English proficiency (non-native English speakers and natives alike).
Honestly, this is certainly a case where the term could be used for several different features.
For me it basically comes down to creating emitters with more randomness to them. Right now Shuriken has the burst emissions which have a start time, a spawn count (with a range), cycle count, and repeat interval. The recent additions here are quite welcomed. The thing I think of when someone says “spawn probability” is a percentage chance on each emission burst cycle to spawn or not. In particle systems I’ve worked on I added this, along with an interval range which can provide similar controls over randomness for effects with out a finite lifetime, though they’re still useful together.
A basic example is bursts of sparks. You want these to happen at semi random intervals, but not all the time. Current I accomplish this by using sub emitters. Make an emitter with max particles of 1, spawn rate of 1000, and a lifetime range of 0.2 to 2.0. Use a sub emitter to spawn an immediate burst of 7 to 11 particles. This works, but it’s quite roundabout for what would be better accomplished by just having a spawn probability and / or random interval range.
Instead of the above you could have a single burst with a particle range of 7 to 11, an interval range of 0.1 to 0.4, a cycle count of 6, and a spawn probability of 35%. That’s a lot of nice random variety where at most it’ll spark 6 times, but on average it’ll only spark twice.
I’ve also seen some particle systems have a spawn probability for every particle spawned, even when using a normal emission rate. It might seem like overkill, but it can be useful for adding a bit of visual texture to the effect if the particle spawn rate isn’t constant. Sure, a similar effect could be accomplished with a curve on the emission rate, but it doesn’t quite give the same results.
Another feature the term “spawn probability” could be referring to is being able to affect spawning based on a texture or vertex color. Right now you can have the particles’ color be affected by the mesh’s vertex colors, but being able to adjust the spawn chance allows even more control. I tend to work around this by building spawn meshes with varying vertex densities, but that can be laborious.
There is a workaoround for that! Create a Particle system as a master, and disable the rendering modul.
If you put now new particles systems in to the master. You need just select the master and all particles in the master will now play.
Now show me that for 14 effects (with 3 emitters each) parented under 8 different characters in a cutscene, each triggered by separate timeline events while several weather effects are playing around the world. Also, make sure that at least half of them are popcornfx.
I’ve used dummy/master emitters extensively (and also been scolded by code for doing so. It’s very expensive to create emitters even if they do nothing). At this point I’m somewhat familiar with the basics of unity. It’s the real world uses of the previews I find lacking.
yes, emitters are expansive as a code!
I had until to days no big issues with that, but I am considering to create a script as well.
If I have more particles systems in the scene triggered by different animations,i can see those in the play modus.
The good thing is since the 5.4 or 5.5 version you can apply your changes in the play modus, I am happy about this improvement.
But still this is also not the best way in my opinion.
I don’t want to derail it too much from the original list, but I’d love it if you wanted to DM me (or start a new thread) to discuss the following stuff:
