Creative [Beta] Ultimate GPU Particle System

Hey look001,

the reaon why it's an editor extendion is, becuase the Unity EULA requires one license per seat.

 

@richardkettlewell @Ryiah Thank's for the tip! Will do with the next update.

 

I just want to confirm that it works in HDRP, right?

 

Hey jjobby,

At the moment the lit particle shader exceeds the shader keyword limit. I'm going to change the normal global keywords with local ones in the next update. Simply don't import or remove that shader to make it work. The update is coming soon.

 

Yeah, it's useless with this bug and didn't get updated in the latest push to unity store. Just a gentle reminder to fix it in world simulation space.

 

Hey, idavida. I'm sorry for the delay. The next release was in the making. The previous "update" only updated the price to normal. Nothing was submitted. Please hang on a bit longer. I'm working on it.

 

I just tried it out in the editor and the system is incredible. I want to build it for android and try it out on the phone. That was an hour ago. Since then it was compiling lots and lots of shaders and it still is. What can I do to speed this up? Do i need all the shaders?
I like simulations a lot from physics to particles, everything, and I am really excited to use such a system on mobile Also I am very curious about the future features of this asset. I imagine vertex coloring on collision, fluid simulations, mesh collider. (I have no idea if that is even possible to implement. It is already amazing)

 

Hey look001,

You're right the multi_compile on the shaders make it incredibly long to compile. The next update changes it to shader_feature, which has the advantage of only compiling the variant needed, but makes it impossible to change some settings on device. For now, you can remove the ParticlePositiinBillboardSurface.shader file to speed compilation up, if you don't need lit particles for now.

I'm currently also working on a skinned mesh emitter and depth collision. I have many more features planned, but it will just take a while to develop this. If you have a request, feel free to post it here. I'd be more than happy to discuss this.

 

<3 As an IT-Developer in the industry i know how long even simple systems take. Take your time

 

Any Update On This Issue????

 

I'm wrapping up and polishing the final fixes and features. You can now manually edit the AA bounding boxes. If everything goes well, it will be released by the start of next week.

 

Ya not working when not near the origin make this worthless atm. You should provide a download link with a hotfix for stuff like this for customers.

Also, I noticed that in the editor partiles start to deviate from the shape after a while for reasons unknown.

 

Just submitted the new update for review. Editable bounding boxes, skinned mesh emitter and improved compile time are the main features of this patch.

@snacktime If the particle shape deviates over time, that's probably a precision problem. Are you using half precision?
Please send me a screenshot so I can fix it.

 

I could have had it set to half? that test is deleted now when it happens again I'll post a screen of it and the settings.

So simple question most likely, what is the approach for creating smoke effects, similar to the one in standard assets. I've tried playing around with billboards and alpha textures but can't seem to find anything that gets close.

 

I'd recommend you start with downloading the VFX sequencer. It's a somewhat hidden tool that comes with a bunch of ready to use sprite sheets. Make billboards rise vertically up and then add a little bit of turbulence. Then add a constant force to it to simulate wind. It's easy to start but hard to master. Check out this website for references. If you look closely, you can see how those guys created their effects.

 

What I meant was the unity particle system has a specific approach to blending things. Like if I put in a texture sheet in your system it displays it and then just starts another cycle there is no blending. Which is what I'm assuming the alpha blended shader in the Unity system handles.

 

Something is odd with texture sheets. For one you have rows/columns reversed, assuming that's just the labeling though.

Sheets with different row/column sizes seem to reset at the shortest one, resulting in an obvious visual stutter. I tested this with a texture created in VFX tools where the default was 10x24. It had the visual stutter. I re exported it as 10x10 and it worked as expected.

 

I'll look into it.

 

You are right it was broken, but I fixed it already. You can replace these lines:

Code (CSharp):

1. #if TEXTURESHEET
2.                             float2 StepSize = float2(1 / _Columns, 1 / _Rows);
3.                             float ImgCount = _Rows * _Columns;
4.                             float Progress = (i.Progress * ImgCount) % (ImgCount);
5.                             float ProgressImg1 = floor(Progress);
6.  
7.                             float fromU1 = ProgressImg1 % _Columns;
8.                             fromU1 /= _Columns;
9.                             float fromV1 = _Rows - 1 - floor(ProgressImg1 / _Columns);
10.                             fromV1 /= _Rows;
11.  
12.                             float2 newUV = float2(Remap(i.uv2.x, 0, 1, fromU1, fromU1 + StepSize.x),
13.                                 Remap(i.uv2.y, 0, 1, fromV1, fromV1 + StepSize.y));
14.  
15.                             col = tex2D(_MainTex, newUV);
16.                             return col * i.color * _ColorIntensity;
17.                         #endif
18.              
19.                         #if TEXTURESHEET_MOTIONVECTORS
20.                             float2 StepSize = float2(1 / _Columns, 1 / _Rows);
21.                             float ImgCount = _Rows * _Columns - 1;
22.                             float Progress = (i.Progress * ImgCount) % (ImgCount);
23.  
24.                             float ProgressImg1 = floor(Progress);
25.                             float ProgressImg2 = ceil(Progress);
26.  
27.                             float SubProgress = Remap(Progress, ProgressImg1, ProgressImg2, 0, 1);
28.  
29.                             float fromU1 = ProgressImg1 % _Columns;
30.                             fromU1 /= _Columns;
31.                             float fromV1 = _Rows - 1 - floor(ProgressImg1 / _Columns);
32.                             fromV1 /= _Rows;
33.  
34.                             float fromU2 = ProgressImg2 % _Columns;
35.                             fromU2 /= _Columns;
36.                             float fromV2 = _Rows - 1 - floor(ProgressImg2 / _Columns);
37.                             fromV2 /= _Rows;
38.  
39.                             float2 newUV1 = float2(Remap(i.uv2.x, 0, 1, fromU1, fromU1 + StepSize.x),
40.                                                    Remap(i.uv2.y, 0, 1, fromV1, fromV1 + StepSize.y));
41.  
42.                             float2 newUV2 = float2(Remap(i.uv2.x, 0, 1, fromU2, fromU2 + StepSize.x),
43.                                                    Remap(i.uv2.y, 0, 1, fromV2, fromV2 + StepSize.y));
44.  
45.                             float2 mv1 = (tex2D(_MotionVectors, newUV1) * 2 - 1).rg * SubProgress;
46.                             float2 mv2 = (tex2D(_MotionVectors, newUV2) * 2 - 1).rg * (SubProgress-1);
47.  
48.                             newUV1 -= mv1 * _MotionVectorStrength;
49.                             newUV2 -= mv2 * _MotionVectorStrength;
50.  
51.                             col = tex2D(_MainTex, newUV1);
52.                             float4 col2 = tex2D(_MainTex, newUV2);
53.  
54.                             return lerp(col, col2, SubProgress) * i.color * _ColorIntensity;
55.                         #endif
56.  

Unfortunately it didn't make it in the latest update. Unity was simply to quick in releasing it. I'll probably push it again tonight. I'll also add a flipbook blendingmode just for you

 

Thanks for looking at that. I saw the notes about better to have fewer particle systems, but was wondering if there is some way to make it perform well with up to a couple hundred effects at once. There seems to be a fairly high main thread cpu cost per effect. Gpu usage is fine it's main thread time that we are very constrained on.

 

I keep coming back to look at this but then I keep seeing the price. I just honestly think raising the price to $60 is way too much considering the VFX Graph. Sure, if it didn't exist, absolutely, but it does. The argument has been "Unity takes a while to implement X and Y", well, the VFX graph is there and having seen the current/recent demo projects in action, it is much closer to being "ready" than people seem to think.

That being said, if at some point you decide to drop it back down to $20, I would gladly pick it up to play around with it, but at $60 it's hard to justify, especially when the VFX graph is "Done" sales may go down, your motivation to update may diminish, and it may just disappear.

Even though that is just my $0.02, don't get me wrong, this looks sweet and you did a great job and I definitely will keep watching this thread though and see how things go. Hopefully, they continue to go well, new features and whatnot that not even Unity have end up being put in here, etc.

 

Thanks for looking at that. I saw the notes about better to have fewer particle systems, but was wondering if there is some way to make it perform well with up to a couple hundred effects at once. There seems to be a fairly high main thread cpu cost per effect. Gpu usage is fine it's main thread time that we are very constrained on.​

I was looking at doing this by dynamically generating a mesh of multiple spots. So if I have 100 areas that are on fire, rather than having 100 particle systems, I generate one, and add/remove vertices in a dynamic mesh to make it emit particles from a triangle that matches the spot.

 

I'd be curious how that worked, I'm trying to think of how it would figure out where to emit from exactly on a triangle surface, and what it uses for the emit direction vector. Like world up would be what I think most would want vs the triangle surface normal.

 

Well, you generate the triangle; you can put the surface normal wherever you want.I think I'd be passing a transform and a radius, and generate the triangle based on transform up, transform center + radius. Simple enough.

There's still visibility issues on the 28th Feb build:
- Occasionally fails to render at start; switching the game object off and back on again brings it back to life.
- Dragging it back out from origo (say to 0,0,200) makes the visibility culling iffy (some angles culls the particles); Max mentioned you could now manually set up the bounding box, has anyone looked at that?

 

WOW i love it! Support for skinnedmeshrenderer is amazing!

 

Hi, thanks for making this. It seems force - random between 2 constants only uses one constant. Also Play on awake with loop off doesn't seem to work. Can you confirm? Thanks

 

No, I dont use any CPU time (except some render overhead). I duplicate the mesh, split the triangles and create a new UV set on enable. Then I sort and evenly distributes the trinagles over 0-1 UV space. When I render the object, I use the UVs as vertex positions (To fill the screen completely) and output the vertex positions as colors. Those colors are my positions, that I use to emit particles from.

Optimizations can be done by the user, by reducing the amount of vertices and using a dedicated skinned mesh for emission. I think I'll add a feature , that allows a simple mesh reduction for that purpose in the future. When I render the mesh, it looks like the attached image.

 

At the moment, the whole system needs to render a lot of textures and keep them in memory all of the time to work. That makes it inefficient when using many emitters with few particles.

I think I'll add an emitter, that consists of multiple emitters and uses the same particle pool. I don't know when I'll have the time to do this however. Im currently working on scene depth collision and fixing bugs.

 

I think that's the correct approach. I'll try to deliver this feature out of the box in a future update.

 

What's the performance impact of running a system with no active particles rendering? I'm currently using the emission rate to control generation of particles (so when the fire is off, it's not generating any particles). The system still appears to be doing a lot of work, and OnEnable() / OnDisable() seems quite intrusive in terms of resource allocation and deallocation.

Great work on the system so far, and looking forward to the multiple emitters.and worldspace collisions

 

@simonsen That's true, it has to allocate a lot of memory, because some buffers need to be double buffered. I think only DX11+ devices can read/write into the same buffer simultaneously. Also all the geometry has to be there. That's why optimising your effect is very important. If you need 10k particles, reduce the buffer size accordingly or else thousands of particles are not used.

You should also check, if half precision works with your effect, because it reduces the memory allocated by 50%! Mobile games default to half precision anyways, which sometimes can lead to jittery movement, odd spacing and less randomness (lifetime, color, speed, etc). Usually you won't notice this on devices with smaller screens and/ or fast moving particles.

 

Thanks. The fire's working nicely now, and I've got some additional optimizations set up (early out if I know nothing's been on fire for a while, etc). I'm really enjoying the plugin so far, good performance and beautiful visuals.

One thing I'm looking at is rendering a duplicate of an animating particle system at a different world-space. I assumed it would boil down to grabbing the GameObject[] particleMeshes objects, extracting meshes and materials, then doing a Graphics.DrawMesh or Graphics.DrawMeshNow with an updated matrix. So far that's not rendering anything at all; any ideas for a better solution there?

 

I haven't tried that yet, but I assume that it doesn't work is, because in worldspace the transform position is ignored and the world position is being reconstructed in the shader that constructs the billboards/ etc. If you want to make it work, you would have to add another vector, that functions as an offset. When rendering the original it's (0,0,0), but if you use graphics.drawmesh(), you set it to your new position. it will be more tricky if you also need rotation.
I haven't tested this, but this would be my first shot if I had to integrate this feature.

 

Yeah, already looked at setting a material block with
matBlock.SetVector("_PositionOffset", t._transform.position);

No love so far, but I'll go dig into the shaders and see what's happening

 

You mentioned the latest version supports setting a manual Bounding box. How's that done?

 

The general tab now has a button at the bottom. You can show and edit the axis aligned bounds. Hit edit, change the settings and apply.

 

I just updated the demo.

It now contains all the demo scenes + the 2 new features:
1. Skinned mesh emitters
2. Scene depth collision

Everything works fine except for some minor things, but it needs some testing before I submit it.

 

Thank you! I realy like scene depth collision! Keep it up!

 

Just bought and testing whole days.
Overall, it's potential plugin for 3rd party particle system.
The result also is promised ( very stunning for million particle emitted ).
No conflict for me by using X-particle before.

Just request Trail Function at next update.

Any way, worth for purchased and learning.

 

Im glad, that you like it. I've been looking into trails, but they're not on the list of new features for the next update. I'll soon push better collision and a lot of fixes. Maybe next update?!

 

I glad to see it (trail function) on roadmap. No problem, I can wait.
By now, I'm doing this stuff how it act with timeline and create a stunning animation.
Such a slowing-up the particle movement when camera zooming.

I try and share up after I study deep

 

Hello!
I have some questions about this system.
I am making a game with massive soldiers and need to play thousands of particles effects. So I am very interested in this asset.

But, there are some questions, could you explain these to me?

1. Is it handled like particles system in Unity? I just create it in Unity Editor and move the transform and just call Play function in runtime?
2. Can I use it to make some blood effect? Just like a minion hit by Player or something.

Thanks!

 

I just got this asset and can't seem to get it to publish to Magic Leap, any suggestions?

 

Was just about to drop $60, but there is no trail function.

 

i try to download the package and import. but i dont see any scene depth collision. May i know why?

 

no update yet ... will be soon?

 

Yeah, currently the trail is just a simple triangle polygon, is not a ribbon trail. But i think they are working on it,but with all the feature they had. it's worth that $60.

 

According to package review, i thought it already updated or my cache problem. Btw thanks for the infor.

 

Can we get some examples packaged in an apk so I can test performance on android?