PA Particle Field - Superfast, GPU Based, Persistent Particles

thanks mark, tested and working perfectly.

 

@popupAsylum Hi there, I wrote on the asset store about needing world space render for the rain/snow demo. By default the particles were only following me.. I haven't looked at what space setting it is set to but I'll have a look at it soon and see the difference.

One last feature to note would be cool.. I don't know if its possible but it would be profound if people were able to use a script to convert regular particle systems to this one. I haven't read everything yet in the manual so I don't yet know what is or isn't possible.

 

Hi @Ascensi, have you looked at the simulation space setting?

For converting shruiken systems to particle field I think it'd certainly be possible but they are quite different systems, it'd be a best guess conversion and particle field doesn't support everything shruiken does (yet)

 

Uh oh. IDK what I did! lol.
(I'm the ultimate beta tester, I can break anything! )

I'm on version 1.26 installed today, although this was happening on the previous release too.
PAPF is Playing "pacman" with memory for me. Running under the profiler, I see a lot of Texture2D Assets (like 2100 of em) being referenced by material instances from PAPF's that I have in scene. Interestingly, they appear to be from the pooled stuff that I turn on and off and reuse.

When looking at the detailed view in the profiler/memory area...
I see the texture name(s)...2100 ish ref count, and over on the right I see PAPFObjectName (instance) ### (Material)

I held off saying anything the other day because I knew you had a new version on the way to the asset store. So I checked today and memory consumption is still there. Now, it could be something I'm doing that's messing it up, but somehow it looks like previous resources are not being released for dynamic material allocation.

This all started happening on the previous release (or so), about the same time as UT updated with 5.3.4.P2. P3 didn't fix anything, nor did this latest PAPF update.

So maybe it is an unknown issue? IDK what more info I can give you to reproduce. Do you need a test case, if so I'll try and spend time creating one, but won't if I needn't bother.

Another good place to look is in the profiler...CPU area, under the GC-Alloc column. It looks like PAPF.CreateInstanceMaterial is doing most of the allocating (27K ish per frame) (24 fields active for me at that frame...8 objects with 3 fields each).
(P.S. FYI - Foreach allocates temps...I replace it with for loops... but that can't account for the allocations here.)

It's probably just some weird combination of stuff I'm doing. IDK. Please advise.

 

PA Particle Field v1.26 is now on the store

What's new (since 1.24):
Turbulence Modes add per particle random movement creating more effect possibilities
Particle Count Mask reduces the particle count at runtime without any garbage allocation (just billboard particles for now)
Shader Optimizations improve performance
Improved Serialization adds better support for prefabs
An Unlit Mesh Shader adds highest performance for Mesh Particles
The Fish Demo provides a practical example of Turbulence Mesh Particles

Also v1.25 introduced some bugs affecting devices with low instruction counts, these have been resolved in this version
The inspector has also been improved with collapsible areas and full multi edit support.

Finally, the Documention and Manual page has been updated to load quicker and show the new features, with more detailed feature explanations.

 

@CarpeFunSoftware just when I thought I had everything sorted! I'll look into it, I clearly need more test cases

 

@CarpeFunSoftware that leak is just in the editor, for now its quick and safe to just remove the #if UNITY_EDITOR section in PAParticleField.cs 's Update method, and I'll work on a proper fix

 

Particle Field 1.261 is on the store now (and has been for a couple of weeks)

There's a few features in the works, the shader keywords that have been removed (e.g. EDGE_ALPHA) are getting added back into the .cginc file, so that users with custom shaders can take advantage of the performance benefits if their project has keywords to spare.
The shader side is also being updated to give access to more data about the particle, such as speed and direction. This is mostly again for use in custom shaders, for example in the Animated Mesh Particles demo the speed the robots' legs move is matched to the speed the particle is moving, and (theoretically) in the Fish demo the fish will be able to bend as they turn.
I also plan to open up the PAParticleMeshGenerator a bit more making it easier to create effects beyond the currently randomized billboards and mesh particles, for example mesh and texture based emission.

Then in the more distant future there's expanding Particle Field to cover more types of particle systems, its still early days but the gif below shows how the GPU concepts behind PA Particle Field look when applied to more regular systems.

​

 

Hi, I wanted to use this asset to put particles in my GUI pause menus, but usually particles are stopped during time scale 0, so I wanted to know if Particle fields has a way to run using a method like unscaled time?

and just to clarify, I mean something like this (in Update):

if (Time.timeScale < 0.01f)
{
particleSystem.Simulate(Time.unscaledDeltaTime, true, false);
}
Anyway, for any advice, thanks in advance.

 

Hi @Alverik,
Its a great suggestion and I'll include it in the next update, for now I've sent you a link to an updated version that has the function

 

@popupAsylum hi there, Shuriken Unity billboard renders only squares spritesheet. So, I wonder if your PA system supports tight packing atlas for particles animations?

 

@ikemen_blueD it's just grid based spritesheets currently, not necessarily square but not like what you'd get out of TexturePacker, the sprite selection is done by offsetting and scaling the UVs in the shader using uniform properties.

I can't think of a completely cross platform way of doing tight packed atlases (yet) but it could be done in a custom PAPF shader for most platforms by generating a grid texture from the atlas metadata where RG represent the sprites bottom left corner position and BA represent the sprites size, then in the shader, letting PAPF do its normal grid based UVs and using the resulting UV coord to read the metadata texture for the desired particle size and UVs.

I'm currently working up a library of prefabs and custom shaders for PAPF to put on the popup asylum website as a separate free download, these are little extra demos and aren't going to be very supported might not work on every platform but they'll show how the system can be extended, I could add something in there that uses the above method to support them

 

Grid based works in my case, better than squares. Btw, I just purchased your PA. I'm very impressed with your demos. PAPF is new to me. But, I definitely give it a try

 

For some reason I can only see the "Sine" option available in the turbulence section.


From PAParticleFieldInspector.cs (line 423):

string[] options = new string[] { "None", "Sine" };

Why aren't Simplex/Simplex2D among the listed values?

 

Hi @moatdd, it's a bit of a pain but for Unity 4 they have to be accessed in custom shaders.

Just to explain a little, in Unity 4 Particle Field seems to hit the the instruction limit for vertex shaders sooner, also it doesn't have the SHADER_TARGET shader define (that got added in 5) which helped to determine when hitting the limit would happen.
Because the built in shaders have to support all functionality, when compiling it would create a variant that used the simplex modes with directional and exclusion zones, this would pass the instruction limit and shader would fail to compile since if any variant of the shader doesn't compile Unity treats the whole shader as having not compiled.

So in Unity 4 the simplex modes are still there but not in the built in shaders. It's fairly easy to create a custom shader for PAPF, and for Unity 4 I'd highly recommend it since it allows you to fine tune the features you use and will reduce your final executable size.

To make a custom shader that uses Simplex turbulence, I'd duplicate one of the existing built in shaders e.g. "ParticleFieldTransparent.shader", rename it "PA/ParticleField/TransparentSimplex" (or a name you like) and change the line

#pragma multi_compile TURBULENCE_OFF TURBULENCE_SIN

to

#pragma multi_compile TURBULENCE_SIMPLEX

Then create a new material with this shader, change the Particle Field's material type to Custom and drop in the material. Leave the Turbulence Mode in the inspector on Sine so you can continue tweaking the frequency/amplitude variables.

Sorry its such a manual process, but currently without the built in SHADER_TARGET define I haven't been able to think of another way.

 

Thanks for such a fast response. Ah crap I should have mentioned that I'm using Unity 5. Is it still not possible to apply simplex noise to the particles via the originally intended way (through PA's interface)?

 

@moatdd You're completely right, line 423 in PAParticleFieldInspector.cs should be;

string[] options = new string[] { "None", "Simplex2D (Faster)", "Simplex (Nicer)" };

Must have been lost in a merge sorry, I'll push an update with the fix

 

I'm trying to use a custom material with PAParticleField and none of the particles are showing up.

It's a variant of the Standard shader, which I've adapted for drawing Normal-mapped sprites, and while it works fine on Sprite Renderers, it's incompatible with PAParticleField. What are the criteria for making these two things work together?

I intend upon using PAParticleField to use random sprites from a spritesheet for a heavily-populated debris field, and the sprites are generated from a utility that I made that renders 3D models onto 3 sprite sheet passes (RGBA, heightmap, normal).

When the sprites are applied to a SpriteRenderer, they react with lighting direction and also react to parallax perspective, but now I just need to put the two sticks together to get them to work with PAParticleField.

 

@moatdd using a custom shader is definitely a great idea, and its not too tricky to make a shader PAPF compatible, but not as simple as dropping any shader on.
This blog post http://popupasylum.co.uk/?p=683 exlpains a little of how to do it but it's a bit outdated in the number of keywords it uses, I'll update that tomorrow.

To make a shader PAPF compatible you must include the ParticleField cginc in your shader

Code (CSharp):

1. #include "Assets/PopupAsylum/PAParticleField/Shaders/ParticleField.cginc"

And a number of keywords depending on your requirements, this is the full feature set for 1.261

Code (CSharp):

1. #pragma shader_feature _ DIRECTIONAL_ON SPIN_ON
2. #pragma shader_feature _ WORLDSPACE_ON
3. #pragma shader_feature _ SHAPE_SPHERE SHAPE_CYLINDER
4. #pragma multi_compile _ EXCLUSION_ON
5. #pragma shader_feature _ TURBULENCE_SIMPLEX2D TURBULENCE_SIMPLEX

Then in the vertex program you'll need to call the PAParticleField function, which takes an appdata_full as its argument, for a basic surface shader the vertex program might look like this;

Code (CSharp):

1. void vert(inout appdata_full v, out Input o){
2.     UNITY_INITIALIZE_OUTPUT(Input, o);
3.     PAParticleField(v);
4.     v.vertex = PAPositionVertexSurf(v.vertex);
5. }

or for a vert/frag shader it could look like this

Code (CSharp):

1. v2fParticleField vert(appdata_full v) {
2.     v2fParticleField o;  
3.     UNITY_INITIALIZE_OUTPUT(v2fParticleField, o);
4.     PAParticleField(v);
5.     o.color = v.color;
6.     o.worldPos = float4(v.vertex.xyz, 1);
7.     o.tex = v.texcoord;
8.     o.pos = PAPositionVertex(o.worldPos);
9.     return o;
10. }

That's just an example, in your case you'd want to pass on the normals and tangents.

The important functions there are the PAParticleField(inout appdata_full v) which does the simulation, and the PAPositionVertex(float4 worldPos) of PAPositionVertexSurf(float4 worldPos) which positions the vertex in View-Projection or Model-View-Projection depending on the Simulation Space (the Surf suffixed version should only be used in surface shaders)

I hope that's enough to get you on the right track with it. I've tried to make it as simple as possible, as far as number of modifications go, to convert a regular shader to be PAPF compatible. And of course let me know if I've left anything unclear or you run into any problems

 

Thanks, popupAsylum for your speedy and thorough explanations.

Of course, as luck would have it I'm in an edge-case scenario where I'm trying to adapt the Unity 5 Standard Shader to PA ParticleField. It seems the Unity team really made the shader from scratch and it doesn't have any references to appdata_full, which leads me to believe that I have embarked on a fool's errand.



This is a shuriken particle field that I've made using a utility that captures 3D models from an ortho camera and generates albedo/opacity/normal/height info that is used to create enhanced sprites that respond to changes in lighting.

However, your last post will help me in terms of adapting any other custom shaders I make to PAPF.

 

@moatdd it seems the standard shader uses VertexInput defined in UnityStandardInput.cginc instead of appdata_full.

You should be able to create an appdata_full from a VertexInput but you'll be missing per particle color, below is all is untested code but it'd be something like this at the start of the Standard shader's vertex function

Code (CSharp):

1. appdata_full data;
2. UNITY_INITIALIZE_OUTPUT(appdata_full, data);
3. data.vertex = v.vertex;
4. data.normal = v.normal;
5. data.texcoord.xy = v.uv0;
6. data.texcoord1.xy = v.uv1;
7. #ifdef _TANGENT_TO_WORLD
8. data.tangent = v.tangent;
9. #endif

Where 'v' is your VertexInput, you'd then use the 'data' variable in the PAParticleField() function, then pass the vertex, normal and texcoords data back to the VertexInput 'v'. After that carry on with the rest of the Standard shaders vertex function as normal but replace

Code (CSharp):

1. o.pos = mul(UNITY_MATRIX_MVP, v.vertex);
2. with
3. o.pos = PAPositionVertex(v.vertex);

Sorry its untested and somewhat painful, really I'd recommend using a surface shader and replicating the Standard shaders inputs, or holding off because in an upcoming version there'll be more granular functions shader side, rather than just PAParticleField() doing everything (though that function will still work)

 

The settings that come in the bokeh demo cannot be overwritten. Meaning no matter what value I change, it remains the same. The only thing I can update is the size of the particle. What is going on?

 

Particle Field v1.27 is out

What's new:
Simulate Method allows the field to be updated manually, useful for when timescale = 0
Fixed Turbulence inspector not showing simplex modes in Unity 5

 

Hey @popupAsylum,

First off great product, it's a cool aproach

Just noticed this tho

Line 129 of PAExculsionZone List<PAExclusionZone> zonesInBounds = exclusionZones.FindAll >

is causing Garbage Collection every frame, could just loop through them manually
can you fix that in a future release?

Thanks Bro

 

@punk glad you're liking it, good call on the exclusion zone sorting, that's fixed now and will be in the next update

 

that's awesome, Thanks bro

 

Hi,

Can I access single particle?

 

@3d_Artsit1987 not in any friendly way, you could read every 4th vertex of the mesh but even that would only give you initial position, direction and speed values, this is because the particle positioning is done entirely on the GPU and the CPU/script side only updates time deltas.

From a custom shader you can access the particles properties by/after calling PAParticleField(inout appdata_full v) the returned float3 of that function is the particles position in world space, and after calling it 'v' will have the updated particles normal, color etc.

 

Thanks for reply.

 

Can I use this for 2D? I tried using the Snow prefab with 2D Toolkit orthographic camera and the particles are not showing. Is there a way to set the Sorting Layer/Sorting Order of the particles?

 

Hi @fxfx, sorry for not getting back to you sooner.
I've just tested, it does work with orthographic cameras but there's a bug with soft particles, I thought I'd fixed it but I must have reverted it inadvertently.
To make the particles show up in an orthographic camera set the Soft Particles mode to "Near Clip Only" and the Fade Offset to -1

 

It works!
Your instruction fixed the problem and now the snow particles are showing in my 2D Toolkit camera.
Thank you so much for the reply.

 

hi there.
have a problem. if i importing package to project, then all working just fine. but if i copy/paste folder with particles then nothing work.

we using that asset for project and placing all asset in SVN. but ppl who updated particles asset just dont see particles.
there is no errors or warnings. all options in script works... but we dont see particles.
any ideas?

edit:
all shaders that using .cginc cant find that cg includes

Shader error in 'PA/ParticleField/Additive': Can't find include file Assets/PopupAsylum/PAParticleField/Shaders/Turbulence/noise2D.cginc at line 21 (on )

 

Hi @zelmund,

Yes that's what I was expecting it to be, the shaders use project relative paths, if you've changed the folder structure they wont find the .cginc like you've said.
If you have to have a different structure you can edit the include lines, for the built in shaders just delete "Assets/PopupAsylum/PAParticleField/Shaders/" since they are in the same folder they will find it, for the shaders in the demos folders you'll have to put the new full path.

I found it easiest to put the full project relative path since when making a custom PAPF shader I usually duplicate one of the built in ones, then move it to my projects own shaders folder.

 

i didnt changed any folder structure.

to repeat problem:
1. import asset from asset store
2. open PopupAsylum folder in explorer
3. zip it or rar it.
4. go to unity and delete PopupAsylum folder
5. go to explorer and unzip/unrar it
6. go to unity and wait for compile
7. check shaders. they cant find any cginc files

what i did wrong ?

edit:
i think i found what i did wrong.
somehow shaders didnt saw cginc files. so i just restarted computer and all fine now

 

Hi,
is there some way to mimic leaves falling off a tree with this plugin? I didn't see any way of telling the particle system where to have the particles spawn from in world/local space.

 

Hi @Chuji

It's currently not something you can do easily out of the box sorry, you can create a class that extends PAParticleMeshGenerator, probably extending or starting with a duplicate of PABillboardParticle of PAMeshParticle, then in the UpdateDirection method you can put your particle start position instead, you'll have to bring the position into the fields "bounds" space which is a range between 0 and 1 or -1 and 1 depending on if its being used for position or direction.

Its an area that moving forward needs to be updated to add a lot more flexibility, for now I've attached an example custom generator that will generate billboard particles with positions based on vertex positions of an input mesh.

 

Hi!

PA Particle Field is great. I just have a tiny request. Could you amend the ParticleField.cginc file to use a relative path for it's #includes? I want to move the PopupAsylum folder from the root of my project, but it breaks the path.

I think you can change them to

Code (CSharp):

1. #include "Turbulence/noise2D.cginc"
2. #include "Turbulence/noise3D.cginc"

and they should still work, right?

Have been changing them myself, but have to change them back every time there's an update.

Really great asset, thanks for making it!!

 

Cool. I've been wanting something like this too! But pardon my noob question, but, how would I use this script? is it meant to replace one already there and work by itself or am I supposed to attach it to a Pa Particle field object?

 

Hi @flashframe, yep should do no harm, I'll get it in for the next update, I've been keeping it absolute to make it marginally quicker to create custom shaders by dupliating a built in one but it makes sense for situations like yours to keep it relative, since if your making custom shaders you'd be editing the file anyway.

Hi @Alverik, you add the component to an existing billboard particle field and it'll replace the generator on it, it requires a small change to the PAParticleField script which is documented in the script, basically just making the mesh generator property public. Once added you'll be able to drop a mesh into the inputMesh variable of the script, you may also need to change the field's seed to cause a complete mesh regeneration.

 

Hmm, sadly there are more limitations then that. Even though it starts right where you want it, once the particles exit the boundaries of the ParticleField, they then re enter from the opposite direction. As in, they do not re use the start position again, only first time for initialization. And then there is the emission speed. There is no way to have the "leaves" spawn at random times. They all seem to spawn within a fixed time rate since last particle spawn. This ends up with a certain amount of particles spawning in a cluster and then moving together, with no more spawns until that cluster exits the boundaries of the ParticleField.


I made a few edits to the extended class. I removed the overriden UpdateSpeed as I wanted to inherit the base function and still take advantage of the speed settings. I also changed the Mesh into a simple GameObject as a point. And take advantage of the Scale of the GameObject for size of the boundaries of where the leaves should spawn from. Obviously the code can be expanded into boundaries of spheres and so on, though cube sufficed for the test.

On the gameobject (StartPoint) I added a disabled PAExclusionZone component with Edge Thresholds of 1 just for the gizmo.

Edit: Ah yes, forgot to mention, the gameobject (StartPoint) needs to be a child of the PAParticleField gameobject so that the local position can be properly used in the script.

 

Query:

When you get a free moment, could you let me know what causes the arrays to be rebuilt (resulting in GC allocations)?

I need to know what to avoid doing, as PAPF is allocating quite a bit per frame for my use-case in the majority of frames. Now, I know that's because *I* changed something that forced the rebuild of the mesh. So to those reading this, it's me, not PAPF in general.

But yeah, the mesh generator's SetArraySizes() gets called too often for my desired result. What forces that? I think this also causes (?another?) PAPF.UpdateShader() call (there's one from OnWillRenderObject and one from PAPF.Update(), or maybe it's the same one and I'm reading the profiler wrongly).

Hints appreciated.

 

@CarpeFunSoftware it should just be getting called when the field starts, when the particle count changes or when the input mesh of a mesh particle field changes, or when the meshIsDirty flag is set to MeshFlags.All or MeshFlags.Count

UpdateShader() should get called in Update for fields that aren't using custom materials since it will have its own unique material that only needs to be updated once per frame, and OnWillRenderObject for fields with custom materials since the material can be shared between fields.

Changing the particle count is the main cause of the garbage currently, if its a billboard particle field then using the particle mask will produce the same visual result without allocations

 

@popupAsylum Thanks. Yeah, I (now) modify the material's color when I create or reuse a pooled PAPF.

-->> I also modified the particle count when fading out a field over time when "destroyed" before returning it to the pool. I think that was mostly the cause. I expected it on creation/reuse. OK, so I need to figure out how to use the particleCountMask "mask" instead. Is it more or less just clamping to min(count, countMask)? (no docs) So if I set the "mask" to the desired count <= field's particleCount it should work, right? Looks to be working. Thanks.

 

Hi, sorry to bother you, Chuji, but could you explain how to use your modified script? when I try to import it I just get a lot of compile errors... I don't know if I'm supposed to overwrite another file or just use it by itself.

 

Hello to dev team or current users.

Considering getting this particle system. Have a question though. Can more than one particle boundary box exist in the same space (not referring to exclusion zones in a particle field) and both work properly?

Thanks.

 

@toddheilmann that sounds like having multiple particle fields, which should be fine, they will work entirely independently of each other

 

Particle Field v1.3 is out

What's new:
Fog Support on all shaders
Custom Particle Mesh Generators are now supported without having to edit source files (this is still a little experimental)
Added Custom Rotation Axis for mesh particles
Added Per Axis Turbulence controls
All shaders now use relative paths
Minimum Unity version is now 5.0.1

Mesh and billboard particles now share more of the same back end which should make bug fixes quicker.

The way the shader works is more flexible for custom shaders, the vertex data is separated into structs for particle movement and particle shape, the particle movement data is then passed to the Simulate() function that outputs the simulated particle position and velocity, then this is used with the particle shape data to position the final vertex. This is more flexible since the data in the structs can be modified between function calls, and should lead the way to more generic particle effects.

An example of this update in action is the AnimatedMeshes demo, the mesh particles are now able to change their leg speed based on the speed of their movement.

 

This is going to absolutely fantastic when you are able to implement it. I really look forward to it.

 

Looking forward to the new features too.

Anyone else using this on the latest patch, 5.4.1p4?