PopcornFX - Optimized Particle Effects Plugin

Thanks for clarifying this, Raphael - it worked. Now we have our particles with correct draw order.

Now the question we faced - how can we change particles' amount in Unity? There is "Spawn Count" in Popcorn editor
(http://prntscr.com/f0kiff), but changing it needs rebaking the FX everytime.
And (what's worse) with such approach several instances of same FX but with different particles' count require several FXs in project. While we would prefer one FX in project and change particles' count from one instance to another one.

Thank you in advance.

 

Glad to hear you've got that sorted out!

You can change the emission rate of an effect from Unity by creating a float attribute and putting its name in the emitting layer(s)' "FluxFactorExpression" field (the bottom one).
More info here : http://wiki.popcornfx.com/index.php/Particle_tips_FluxFactorExpression

 

Any possible support for VR in the near future? Thank you.

 

Hi, VR is already supported.

 

This is noted as being an "optimized" particle solution, and it's certainly gorgeous, but how does the performance actually fare? Particularly if you aren't having colliders with unity scene objects, let's say. Or if I wanted to have ten thousand trail renderers, what sort of load could I expect?

My understanding of this product so far from reading is that it is at best a marginal performance improvement, a notable workflow improvement, and a notable visual quality improvement if you're doing certain effect types. How accurate is that?

 

As a developer Raphael will definitely answer better, but meanwhile I'll answer as a consumer.

You actually can collide Popcorn FX particles only with pre-baked meshes. To collide them with dynamic meshes you need density particles on their colliders. And they are more perfomant than colliders, because they:
- are just spheres
- spawn for a short period of time and stay where were spawned - and if mesh moves, new volume that he occupies will be filled with density particles in the next frame.

In this video you can see lots of torches on moving plane (btw, they look much better when are used properly, don't judge by this video where they are drown in the plane).
Now 960 such torches and 16 flamethrowers that you can see on AssetStore page (in above mentioned video we used ones from Sci-Fi Effects) have FPS of 80 on average PC:
http://prntscr.com/fgl3lu
- сamera has Tonemapping and Bloom post-processes on it
- also there are 1600 density particles in cubes to detect collisions in dynamic meshes as I mentioned above.

For example, the explosion you can see on AssetStore pages should be used several dozens times at one period before it starts decreaseing FPS.

On the other hand, in Popcorn's library you can find both perfomance-efficient FXs and ones with huge one. Latest can only be used after adaptation or in solo use-case.

In general, if you are a skilled programmer (which you are, judging by your reviews on assets ) you will find optimizing Popcorn particles easy. They have nice features for batching (or something similar to it) and to reduce overdraw.

=========
The workflow in Popcorn is not its best part, not only because it has separate Editor, but mostly because Popcorn particles live in their own space (if we understand it correctly) and you have to make adjusments to make it interact with Unity's space.
But that is actually the reason why Pk Fx is peromant, I guess?

Everything apart from perfomance tests is just my opinion - I'm not a developer by any means so I could interpretate certain things wrong. Better wait for Raphael to answer more precisely.
But overall I am very glad I purchased this asset. It consumed quite some time from my programmer, but I couldn't find more perfomant particle solutions on the Asset Store for my particles-heavy game.

 

Fantastic writeup, thank you for that.

I'm curious how things stack up when there are no colliders (baked or otherwise) in there. I had noted that dynamic colliders were not handled by default, which is fine for me.

I have a variety of things I'd like to do this, but my first interest is in using this as a more efficient form of contrail renderer for what can range between a few hundred and about 40k realtime ships on the screen at once. I can get 60fps on about 10k ships at the moment, but the trail renderers are a big killer because of their need to dynamic batch and the not-my-favorite way that unity handles that right now.

I'm still experimenting with things there, and in the future I want to do some more particle-heavy first-person stuff that PopcornFX would clearly be the winner for.

I suppose I'm trying to see what I can do with it if I strip off all the safety mechanisms and try to accelerate it into orbit. From your tests there, Kirill, that looks very promising indeed! 10ms is a lot more per frame than I can afford in my CPU budget for just particles, but I'd also be doing something substantially simpler than your particular case.

 

You are most welcome, Chris. Some of your reviews helped me deciding to purchase or not to purchase several great assets, so I'm glad I can advise in at least something =)


=======

If you don't bake mesh, then not only dynamic GOs, but also static GOs won't collide with PkFx, so its particles will just go through - and it doesn't look so great. Well, if you make those particles soft, which I believe Popcorn can, it might be fine. But I actually have no idea on how to make particles soft, as we feel that Popcorn particles live in other dimension (as I said earlier). We haven't tried it out, since in our use case beams, flame-throwers, etc. have to be stopped by colliders, not to continue its flight from the back side of target GO.

======

Yes, Unity is now really cool in handling lots of GOs at the same time. We can have 8K bullets flying simultaniously and seeking for colliders by raycasts.
And yes, we also have lots of ships on the screen and need top perfomance both on CPU and GPU. Popcorn handles it so far.
In addition to countering overdraw and renderers batching (see this video), Popcorn can change its parameters depending on distance to camera (although maybe Unity particles also can do so, or at least you can force them by code), so I believe you can adjust your hundreds of contrails to use less particles if player can't see them well. Although we haven't tried it either.

So in general, my prediction: I don't know which contrails you want to use, but some 40K of some simple ones should be quite possible for Popcorn. Although you'd better wait for Raphael's answer for sure.
Or just create some post-processing FX for that - 40K contrails deserve that

 

My pleasure on the reviews, glad they were helpful.

For contrails via post-fx, it's something I've considered a few ways, but the problem is arbitrary and rapid camera rotations throwing a big wrench into that.

I'm definitely glad to see the popcorn is avoiding overdraw and batching things really well, etc. That alone is superior to unity unless unity is silently batching things without telling us (doubtful).

For my case, having no colliders is fine since these are mostly things shown at a far distance in space, with no walls, etc. For a more up-close game I'd definitely want to use the baked static colliders.

 

Yep, it's difficult to mark somehow pixel in screen space as a point of contrail's start and calculate its direction... But you know, I am sure at some point someone will do that)

Meanwhile, no matter the way you go, I will be happy to see your achievements, Chris.
Congratz with Kickstarter btw! Will keep looking up at your project.

 

Cheers, I appreciate it.

 

Hi @x4000,
Last time we did an actual side-by-side benchmark against shuriken was a while ago (even got a mobile app to compare the 2, if you look at the 1st post of the thread).
We did some more comparison on PC and XBone in Unity 5.3, the methodology probably isn't the best, it was more to get metrics than anything else. I attached the results as a pdf to this post, hopefully it shows up.

More generally, performance-wise we noticed huge improvements in comparison with shuriken when simulating an important amount of particles or when instancing a lot of effects at the same time (bursts).
We've optimized rendering as well by batching compatible materials together in a single drawcall (with the tradeoff of eventual sorting issues, as @AbyssWanderer mentioned earlier in this thread).

Your specific use case actually sounds like a challenge, I guess it all depends on how you design your fx with regards to what you want them to look like.

As far as workflow is concerned it really depends on your needs. We do provide a dedicated standalone particle editor with its own learning-curve and set of powerful tools and features.
Getting everything set-up requires a bit more work than with shuriken but will indeed empower artists to improve both visual quality and performance.

You might want to check out our "personal license" plugin on your website to see if it will suit your need without paying full price straight away. You can always upgrade your license afterwards.

Hope I answered your questions, let me know if there's anything else.
Cheers,

 

Thank you! That's actually just the sort of thing I was looking for. Very interesting results in the pdf there. I was reading your website documentation previously regarding the way that the compositing happens with your plugin, and so the way that things perform is not a huge surprise in that regard -- but it's good to see, for sure.

I actually have the Warfare HD effects pack from you guys -- if I use that as a test case to look at performance and plugin-compatibility, how comparable is that to using the main plugin with effects that I'd have authored myself?

I guess my main worries at this point, to put it another way, are eventual compatibility with things in the future. I've been doing the unity thing since 2010, so I've seen asset publishers come and go in terms of their support of their assets. If unity 2019 uses some new rendering pipeline, with a vulkan backend suddenly on osx (not available now of course), how would the authored effects from this work?

Basically I'm not clear just how far outside the normal unity rendering pipeline this lives, and thus how much continual integration work it's going to take for you guys to keep living in the unity ecosystem. As long as I don't upgrade unity versions too significantly with a game using this it's all moot anyway, but I think my first unity version was 2.6 or 2.4, so I've seen a lot of evolution.

What you're doing is fascinating, though, and all evidence thus far looks really technically impressive.

 

The plugin is the same (save for a couple crypto checks when loading effects for the first time) so it would give you a rough idea but ultimately you'll be tied to the performance of those fx, which may or may not be optimal depending on the settings of your test.

We've been continually developing our plugin since Unity 4.2. Bringing console, mobile and Linux support along the way with their lot of new rendering APIs and architectures (ios and osx come to mind).
While it's been a bit of a catch-up game we're still actively following Unity's releases.
Our next major update will bring the rendering on Unity's side (I've posted about that earlier in this thread), which should minimize greatly the amount of work required to adapt to new features and technologies.

Thank you

 

Okay. So, at this point I've had a chance to test out the Warfare HD effects pack from you guys, and here was my experience:

1. Import. No issues.
2. Run sample. No issues, and everything looks amazing.
3. Stare at performance in wonderment at how the heck this is doing so amazing of a job.

At this point I'm sitting here really in shock in a lot of ways. I've used a lot of solutions over the years for particles, ranging from particleIllusion to Timeline FX to a variety of others prior to Shuriken, and this is just fantastic. So incredibly exciting.

Then I come to the next step:

4. Dig into the documentation, and note all the various things that are apparently required as prerequisites. Get very worried. I'm running on the latest Windows 10, with a full VS 2015 install, so of course things would be most likely to import perfectly fine on this machine.

But then I start thinking: what about people on windows 7? I don't have any win7 machines anymore. Vista? I never had any handy. I've got a bunch on win 10, and one on win 8, and some older XP ones I could dig out if I had to... but still. How about OSX? I've only got one of those machines at the moment, and one ubuntu one. How much of a theoretical debugging rabbit hole might I be headed down? These effects are amazing, and the performance is like nothing I've ever seen particles-wise... but I'm on a tight time budget and I know just how much time some issues on a specific platform can eat up if I run into those.

Soooo... I wind up thinking "maybe next project, when I'm not on such a tight time budget." Which is an enormous shame, because it's hard to be so excited about something on the one hand, but on the other hand wearing your project manager hat and going "this introduces an unknown amount of risk into an already-precarious timeline."

If I wasn't so under the gun on time, I'd definitely be all over this. Or if this was all managed code for the in-unity portions, and simply the fx editor was something that needed to be compatible with MY machine and nothing else, then again that would be easier to swallow. Using something like bullet physics (that other physics library that runs in managed C# inside unity as an alternative to physX) is a lot less intimidating because I don't have to worry about cross-platform or machine-specific issues.

Anyway, I just figured that a writeup of my thought process might be useful. I do intend to come back and make use of this someday, because omigoshthisisawesome, but at the moment I have to set it aside. I'll be very interested to see how this evolves, though. You guys clearly do amazing work.

Best,
Chris

 

Has anyone tried running popcornFX projects on Hololens?

 

@x4000 Those are all valid points. Thanks for sharing your thought process!

@Autarkis : Last time I checked hololens apps had to be UWP compliant, which PopcornFX isn't. So unless a way of loading regular plugins emerged I'm afraid you won't be able to have PopcornFX particles on Hololens. We don't have plans for supporting that platform as of yet neither.

 

Thanks! All I needed to hear.
(I'll still probably get popcornFX at some point for non UWP projects )

 

Hi.

We are working on trail for the shell and want to make curve of color changing over time.
CParticleSamplerCurve cannot be edited in Unity - or we couldn't understand how.
CParticleSamplerDoubleCurve with random value rangeCursor yields more or less similar colors.

So how can we change height of reference points of Curve randomly within some range?

Thanks in advance.

 

You can move your curve to the attribute samplers (in the FX treeview in the editor) and it should appear on your PKFxFX component in Unity were you can set the number of dimensions and edit the curves.

I'm not sure I understand what you mean by that. You want to sample at random between 2 curves?
You need to sample that way : Curve.sample(LifeRatio, rand(0,1)). This will sample the curve over the particles' lifetime (1st argument) at random between the 2 curves (second argument).

More details here : https://wiki.popcornfx.com/index.php/Particle_samplers

 

Thanks for quick reply, Raphael.

Sampling between 2 curves would suit our needs.
We tried atribute of curve's sample, and it does appear in Unity - however it doesn't affect color of the trail anyhow.
While changing the same atribute of curve's sample in Popcorn Editor does affect color and works correctly.

The following video shows this:

What can be the problem?

Unity version: 5.6.2f1, Popcorn editor and Unity asset are of latest version.

 

Hey @AbyssWanderer,

Ok, I see you're sampling that curve in an evolver script, which is why it won't work with the plugin (it just samples the default value set in the PopcornFX editor).
Attribute samplers at evolve time aren't available in 1.11.5 (they can only be sampled in spawn scripts) but are implemented in the upcoming 1.12.

Sooo, I guess you'll either have to wait for 1.12 to come out or find an alternative solution.

I'm still not sure what your requirements are on this effect, do you actually need to change the curve in Unity or could you just have an attribute setting the "rangeCursor" by effect? That way you could choose where each individual instance stands between the 2 curves from Unity.

 

Thanks for clarifying this, Raphael.
We tried few approaches, but at the moment decided to wait for 1.12.
Any prediction on when it will be relesed?

 

Another question:
How can we make the effect instantly dissapear, so that particles would not run through their whole path - but instead would despawn independently of a lifetime?

We have few particles travelling very long way, and would like not to wait untill they reach their destination - but to despawn them at once.

Thanks in advance.

 

Hi @AbyssWanderer,
The 1.12 editor should come out very soon, either this or next week.
The plugin update should follow shortly.

Regarding your other question, what you want to do is enabling the fx killing in your PopcornFX settings and call PKFxFX.KillEffect() instead of StopEffect().
(Don't feel bad for not finding that in the doc, I just added the relevant bits)

Hope that helps!

 

Hello there,

The v2.9p6 of the plugin embedding the 1.12 runtime went live recently (paging @AbyssWanderer).
It's mostly a release to sync up with the editor release with a couple bugfixes while we work on the v3 which will have Unity-side rendering and get rid of the StreamingAssets burden.

Cheers!

 

Thank you very much.
I believe this will be not sooner than in 1 month from now? If so, then unfortunately our product will be released with StreamingAssets.
But it works anyway, so no big deal.

Thanks for this as well, it worked. I just don't like posting messages with just "thank you" - not to spam here.

 

Hello,

Do you have any news about popcorn for UWP? Is it still out of the question for you guys?

Thanks!

 

Hey @AG2017

As I've probably posted somewhere around here, we're currently working on a UWP port to be released with the next major version of the plugin that should bring a massive overhaul of both the rendering pipeline and the resource management (both being what makes the port possible).
In its current state we have a working port with some issues on hololens but even when it's done it will be on hold until the new plugin is ready.
Sooo.. Early next year, maybe. Probably.

Cheers,

 

Thank you for the answer,

Sorry if I missed your post, the last I saw was the one talking about not having any plan for UWP. Glad to hear it will happen.

 

Yeah, no you're right, you're welcome.
I must have posted this on our own platform answers.popcornfx.com
I tend to lose track of what information is posted where...

 

Oh that's great news! Thanks for the update Raphael.

 

PopcornFX rendering plugin rendering particle effect wrong, why???
The PopcornFX rendering plugin is rendering a multi-layered particle effect in two different positions. It is a ribbon effect layered with a mesh spawner effect and they render separately instead of together like they do in the PopcornFX editor. There is a pic below that better depicts the problem, these effects should be rendering in the same position.

 

(For the record, @smorgan's issue is being handled on our answerhub)

I would like to address the late deprecation of our packages on the asset store, since the question came up on our support email.

So, the reason for that is because they include some legacy standard assets written in javascript used in the demo scenes.
Since Unity is phasing out js support, they're cleaning up the asset store as well.

We chose not to take action because we have a major update coming up (featuring complete overhauls of the particles' rendering and resources management) that will be on the asset store as a paid "major upgrade" (fear not for we'll surely figure something out for already existing customers, maybe a grace period, we'll see. Don't hesitate to voice your opinion on the matter in this thread).

This allows us to concentrate our efforts on that upcoming release but rest assured we still provide support for the current version of the plugin (and will continue after the v3 is out, whether you upgrade or not).

 

Hi there,

Just a heads up, by the en of April I will no longer be working at PopcornFX and therefore won't be an interlocutor for the Unity plugin anymore.

My esteemed colleague Paul Baron will be taking over under the name @PkFxBaron and will be handling the announcements and so on and so forth...

It's been a great adventure, thanks everyone who showed interest in my work here.
So long!