Particle Playground

Sorry this is not yet possible due to going through the Shuriken component to render the particles. However Unity 5.3 will have support for this (so will Playground).
Currently as an alternative you can use the PlaygroundFollow.cs to make GameObjects follow your particles, where you can rotate them in any means you'd prefer.

There's two main approaches explained more in detail here: http://forum.unity3d.com/threads/particle-playground.215154/page-22#post-2295552

 

hmmm interesting I will give that a whirl as i have a rotation script already in place.

 

doesnt really work, just freezes up my unity. gonna try with 5.3 b5 see what i get.

 

same thing. maybe I am doing something wrong. what object do I apply my playgroundfollow.cs to? the blood cell? or the playground particle system or spline? Do I enable mesh on the particle instead of billboard? can you give me a step by step on how to do that? as of right now it just freezes up my unity.

 

nm i got it to work lol

 

okay a thing I noticed that while I got it to rotate now, I found that some pop into existence mid way through. how do I make the startng path be where they come from? Also how i prevent them from slowing down due to hitting the inside of the bloodvessel wall? I am getting there, but need a few more tips. again great software, my project is finally coming together well. Thanks again for all the professionalism you have displayed.

 

Hi just bought your asset and got a problem with splines.

What is the proper way to scale splines particles?
I put all my splines under one gameobject, and I scale it down by 0.5. The spline itself is scaled, but the particles emission follows the old scale.

 

Hey @sgtkoolaid! Nice to hear you got it running.
The popping in behavior would be if you have used the spline- or source offset and a particle births. Every particle will have their own starting point distributed over the spline depending on their Lifetime Sorting, where the offset will make the birth position shift. If you for example use a non-fading particle which starts and ends with the same visual appearance then you would never see this, but if you need that perhaps it would make sense to use a Spline Target Manipulator. Here's a setup you could try approaching:

The Target Strength and Manipulator Strength (has the effect in this case, if you were to use a Combined Manipulator the Manipulator Strength would be the overall) will determine the amount of slack the particles have to the target. If you want to induce a slight random movement behavior make sure to use a Transition method while applying Turbulence. The more important thing is to find the sweet spot for the strength applied for the particles to move along the spline then. In case they should always stick to the same route then you wouldn't need to use Transition (or any Velocity behaviors).

Quick steps for using Spline Target Manipulators (Manipulator Type: Property, Property Type: Spline Target) in your case,

For slack/randomness in movement:

• Target Method: Particle Time (makes the particles progress over their normalized lifetime).
• Find a good Target Strength / Manipulator Strength based on their visual movement behavior.
• Zero Velocity Strength will determine how much damping should be applied to each particle's overall velocity.
• Use Transition.
• Zero out the Distance Effect if this should not behave according to the Manipulator's distance towards the particles.
• Apply Forces > Turbulence. Find a good Strength and Scale which works for your scene.

For linear movement:

• Target Method: Particle Time.
• Set Transition to None.
• Velocity won't affect the particles.

 

Hi @ikazrima, sorry that's an issue in current version where they only compute their position based on the Local Scale. Next version will have Lossy Scale included as an option. A quick fix would be to select your Playground Spline GameObjects in the Hierarchy and scale them (not using the parent to scale them).

 

Okay cool, I found that workaround when I fiddled with it . One more question, what's the recommended number of particles on screen for mobiles? I tested on my android device (Galaxy Tab 10.1) and around 3000 particles it starts to lag. I have to drop around 500-1000 to get a smooth experience, but it affects the visual quite drastically.

 

Ok, great!
Mobile performance depends a lot on which features you're using (skinned mesh emission, turbulence and collisions is the more heavier features) and how big your particles are on screen (the amount of transparent pixels rendered). Overall you need to be careful with what works for the target platform, even though the particles can be simulated on a second thread on the Galaxy Tab there's only 1GHz available for the thread to consume a calculation call.

In current version 2.26 and below there's a general overhead of using the .NET Thread Pool which has a heavy impact on the performance, which becomes most noticeable on mobile. The issue is that it takes longer time to consume each thread the more particles you have, while this also generates garbage for the garbage collector to work through. In the upcoming version you'll see much better performance thanks to a custom thread pool adapted for Playground's functionality generating up to 6x less garbage while computation times are improved by around 1.5x. So this is a very noticeable improvement for mobile devices especially.

There's possibly workarounds, perhaps make it look like more particles are simulated in their texture, using a texture atlas to random them up a bit visually.

 

When I use a WorldObject as my particle source and have a particle count n that is less than the number of points on that object, it appears that the first n points (whatever "first" means in this context) of the object are used for emitting particles and not randomly chosen points. This leads to large parts of my source mesh not being used for particle emission and other parts being crowded with particles. Is there a way to achieve a more uniform particle emission from a mesh source?

Interestingly a mesh attractor appears to attract the particles to random points on the mesh and not the "first n points" of the mesh. So as a workaround I can emit my particles from a single point and have them be almost instantly attracted to the mesh to achieve a somewhat uniform distribution, but this feels like an ugly hack.

 

I'll give that a whirl later today and let you know my results. but gotta atlas bake a texture for a combined molecule so i can use the model as a particle lol. grrrr pain in the tookus.

 

Could you please suggest how to make torch flame that player can move around using Particle Playground? All the fire assets I tried unfortunately looks ugly in movement.

 

Yes sorry, that's a shortage of the World Object's functionality (a live down-resolution is available for skinned meshes though). This is on the todo list for regular meshes, available soon.

The effects in the package are not by any means artistic, but there to show functionality. What you could try though is using Advanced > Simulation Space: Local and enable Movement Compensation, then set the Compensation Lifetime Strength.


The strength is a normalized Animation Curve where 1 on the x-axis means a particle's lifetime and 1 on the y-axis means full strength of following the Source locally. What it does is to let the particle system transition between local to global space depending on the Animation Curve.

A typical curve could look like this:


That would make the particles follow the Source's translation at birth, then over their lifetime transition fully over to world space before their death.

Visually it could make sense to use several particle systems if this is a key component, acting as flames, smoke and embers.

 

I saw you saying about spline or source offset. the particle is a blood cell mesh that needs to travel down the length of the blood vessel in a turbulent manner as you would imagine in a blood vessel. However the issue I am having currently is what option do I use or disable to allow the meshes to stay "alive" the entire length. As no matter what life time sorting I use, they always pop in and out of existence. thoughts?

 

Thank you for your example. I didn't notice much difference turning on/off movement compensation, but I will experiment more.

 

Hello!

How much memory does Playground particles take for you? I have run the memory profiler and each Particle Playground system is taking at least 2.9 MB (up to 3.8 MB). Unity Shuriken systems take at most 12.6 KB.

Attached is screenshot from memory profiler (sample taken from Editor mode, in the Play mode usage is the same).

Memory usage seems to be per-instance, so in one of our scenes where there are hundreds of particle instances in scene the memory usage of "Scene Memory/ParticleSystem" is around 1 GB.

Is there something that can be done to reduce the memory usage?

 

another thing I noticed it bunches up at the near a big turn in my spline.

here you will notice what i am talking about. How do I get it to float randomly around inside the blood vessel, and still not pop in and out of existence?
here's my settings.

https://www.dropbox.com/s/bc5b8id72q1r4tj/2015-11-16_194104.jpg?dl=0

https://www.dropbox.com/s/0l4h30kfk7tdw88/2015-11-16_194311.jpg?dl=0

https://www.dropbox.com/s/ba353pewpe2z65g/2015-11-16_194226.jpg?dl=0

here is my spline path set up..
https://www.dropbox.com/s/repnpdorzkgnkz7/2015-11-16_194528.jpg?dl=0

 

Hey,

Have had Particle playground 2 for a while and used it quite a bit.
A new project I am working on uses a lot of text that I want to turn into particle effects much like your logo example.
The logo example uses a texture which I have recreated with the text I want to use.
But having a texture for each word is not really feasible (there will be hundreds of words) and not that good for performance having so many different textures.
Is there a way or any plan to have the particles attach themselves to UI texts or 3d texts?

Cheers

 

as per my post above, I am struggling on getting my blood cells to follow the path properly, they only work when they are right on the path. otherwise I get some positional jittering, and I am unsure what i can do to get them to flow through the vessel properly. Look at my screenshots I provided and let me know what I am doing wrong. thank you.

**edit- I fixed the path traffic jam, by widening the curves a bit more. so that is fixed. but as before I need them to flow and rotate randomly throughout the length of the blood vessel.

edit* seems when it goes along the path that blood cells animate going back to the beginning.

k got the cells to go along the path. but i use turbulence and mix of target strength and manipulator strength and nothing happens, even when I use source offset.

 

Hey!

This is being addressed in the upcoming version of Playground, the issue is that it uses a big amount of particles cached up on the Shuriken component. Why this is layout like this is because the Shuriken component doesn't have its own Max Particles as a public member exposed through script, however I’ve learned that this is accessible through using SerializedObject in Editor as a workaround.

To fix this at the moment you need to go through Playground Manager > Advanced > Show Shuriken, then on the Shuriken component set Max Particles to your Particle Playground’s particle count. This should dramatically lower the memory usage (ex: ~13.1k based on 100 particles).

However, automatic improvements coming!

Thanks for the shots and the description! I'm testing this from your description, I'm trying out a Spline Target and using a Manipulator to simulate Turbulence after the target is calculated. I get a fairly good result using something similar to this setup:



However, I'm also seeing your last edit when not having the particle fully transparent their last frame alive, this will be addressed in the upcoming version (hang in there!).

 

Don't miss the Unity blog post about particle systems.
http://blogs.unity3d.com/2015/11/18/editors-picks-the-particulars-of-particles/

 

I dont seem to have infinite in my version? I need to be able to have this addressed by the weekend. as we are going down to Orlando for a show very soon. did you put up a new update? I have 2.26

 

right now they are going in a line, with no particular speed, no way to actually make them go faster, or randomize within a given area from the spline.

 

Yes sorry that's based on another version, still having the same outcome tho. I'll PM you soon with some info and a quick-fix.

 

thank you sir. i really appreciate it, as the bloodvessel scene is a very important part of our project. i am going to michigan friday to saturday to tweak some final stuff with my client so definitely want to nip this in the bud before I leave.

edit* as it is now it goes alone the spline doesn't disappear, while I can't make it go any faster, it doesn't disappear, and only issue is when It does go away to 'restart"( that one u said is being fixed so its a sort of a non-issue as it seems not to be viewable if we get the speed just right and keep ahead of the camera.

 

Please explain how to do that????????

I nead arrows along patch.

nothing happens.

 

The fix worked and memory usage of Playground systems has been dramatically decreased. Thank you!

 

The image uses Manipulators to send particles in different directions. Nowadays you could do this a bit more intuitive with Playground Splines, see this answer for basic setup: http://forum.unity3d.com/threads/particle-playground.215154/page-24#post-2373519
Here's more info on working with splines: http://polyfied.com/products/partic...es/playground-video-guides/playground-spline/

Then to have the arrows rotate in their movement direction you enable Particle Settings > Rotation > Rotate Towards Direction. The Rotation Normal will determine the direction they rotate around (keep in mind < Unity 5.3 there's still just rotations on two axes).

Great! Soon you won't have to manually edit that.

 

Thanks, Save, for your reply! I appreciate you taking the time to answer. I'll try out your suggestions.

 

No worries, a bit off topic but thanks for iVidCapPro, it's an amazing plugin.

 

Yes, I understand. But do not turn the arrow in the right direction.
I tried all the options Rotatin Normal, but the correct result I was not able to achieve.

 

Just a quick question: I'm on Unity 5.3.0f2 and currently can't seem to make Emit(number) work. [EDIT: That part is fixed - I thought I could call Emit(number) and have the particle system emit particles where its transform is, like with Shuriken ... but Particle Playground requires adding the position]

5.3 introduced a lot of new APIs for the particle system, I probably there's a lot of awesome stuff in Unity 5.3 that Particle Playground could use.

Do you already have an alpha or beta version that is optimized for Unity 5.3?

That should also solve the warnings (currently, I get 53 from Particle Playground).

 

Sorry it's a bit difficult to see what could be the issue, are they moving over time along the spline? The rotation normal needs to be set accordingly to the camera. You can see an example in the Lifetime Positioning scene found in Example Scenes/Interactive/, which uses a script called PlaygroundRotationNormal.cs. As the rotation still is only around a 2D plane the correct rotation along with the perspective can sometimes be difficult achieve. If you keep having troubles setting it up you're welcome to get in touch over at support@polyfied.com and we could have a closer look.

Indeed you need to assign them a position first, the scripted emission works a bit differently overall for Playground. Before calling the overload Emit (int) it expects that scriptedEmissionPosition is set (which happens during the emission procedure afterwards or through the Inspector when you test the emission). Using Emit (Vector3) for example will also set the position.

The Unity 5.3 update is in the making, not fully ready yet though. Feel free to send me your email through a PM to join in on the beta.

 

Hello This was told in July 2015 that it would be released soon, and I do not know if this is available or not, or when would it be possible

I want that it can be able to take the colors from the source objects and disintegrate it in dots light particles.

Thanks and I wish you best with the other new features you want to put that look very good

 

Hi!
This is one of the extension components which next version comes with called Playground Recorder. It ables you to record, playback and time scrub particles in an asynchronous environment. The recordings can be stored in Editor and loaded back into any Playground Recorder. It can also be used to improve simulation times for looping particle systems which constantly does the same thing as playback will take over the calculation loop.

The release date is this Tuesday (December 8th) along with the Unity 5.3 release.

You could however do the effect you mention already in the current version by using a Source: Skinned / World Object, set the particle system to not loop in its emission and enable the particle system whenever you want to disintegrate the mesh.

 

Oh yeah !!!

 

Robot is still burning

 

Holy sh!t Save, that new burning effect looks amazing! Any quick explanation of what was changed? (Looks like the new one is a completely new effect with flipbook textures?) Is the new effect using features of the 5.3 release?

Really looking forward to all the updates Shuriken is getting over the next few months, and even more so to the awesome ways that Playground seems to be taking advantage of those updates.

I have a question about garbage collection -- not the most exciting thing, hopefully not annoying/ something you've been asked about too many times before. (I looked through the past pages of this thread, but didn't find a discussion of what I'm looking for.)

I see that you've said that the .net thread pooling used in Particle Playground up until unity 5.3 pretty much requires there be some garbage generated every frame, and even the new custom thread pool solution in 5.3 will generate some (much smaller) amount of garbage. My question is, why does Particle Playground generate garbage even when not using multithreading? Is this garbage generation also impossible to avoid? I'm mainly asking because I'm curious, but I might also try to refactor for zero allocations at runtime at some point. If you have the time to explan where in the code the allocations are happening when multithreading is set to no threads in the playground manager, I'd love to read it! If you're too busy getting the latest update ready, feel free to ignore this

 

Hey Alic,
Nice that you like it! It's a simple texture sheet, not much animation going on but what does the trick is how particles move in the turbulence field. I felt some things really needed to be looked over and set a higher 'blueprint' standard due to previous demands. Not using anything extra really to disappoint.

About threads and memory allocations. Playground itself in a standard setup particle system allocates 12 bytes per calculation cycle measuring with Unity 4, otherwise all GC values are shown doubled in Unity 5 (I'm still investigating that part if it's incorrect values in relation to what happens at runtime).
Using the .NET Thread Pool allocates 305 bytes per thread by itself. You can try it with:

Code (CSharp):

1.     void Update ()
2.     {
3.         PlaygroundC.RunAsync (()=> {
4.             int test = 100;
5.             for (int i = 0; i<test; i++)
6.             {
7.                 test--;
8.             }
9.         }, ThreadPoolMethod.ThreadPool);
10.     }

Using the new Playground Pool which is a self managed thread pool allocates 0 bytes. You can try it in Playground 3 with:

Code (CSharp):

1.     void Update ()
2.     {
3.         PlaygroundC.RunAsync (()=> {
4.             int test = 100;
5.             for (int i = 0; i<test; i++)
6.             {
7.                 test--;
8.             }
9.         }, ThreadPoolMethod.PlaygroundPool);
10.     }

The interesting part happens when you reference anything between the main and asynchronous thread (which is unfortunately not feasible working around as far as I know, but would love to be proven wrong!). So now let's try it with this, putting our test integer outside the asynchronous call:

Code (CSharp):

1.     void Update ()
2.     {
3.         int test = 100;
4.         PlaygroundC.RunAsync (()=> {
5.             for (int i = 0; i<test; i++)
6.             {
7.                 test--;
8.             }
9.         }, ThreadPoolMethod.ThreadPool);
10.     }

Which gives us 369 bytes, meaning we bumped up 64 bytes in allocation. Trying the same approach with the Playground Pool:

Code (CSharp):

1.     void Update ()
2.     {
3.         int test = 100;
4.         PlaygroundC.RunAsync (()=> {
5.             for (int i = 0; i<test; i++)
6.             {
7.                 test--;
8.             }
9.         }, ThreadPoolMethod.PlaygroundPool);
10.     }

Gives us an allocation of 64 bytes, so the 64 bytes is generated between the main and the second thread. Exactly why that is I'm still a bit unclear of, but the best take is that it needs to allocate memory to pass information between the two. Sometimes I really wish I was a better engineer to give more thorough answers.

 

Particle Playground 3 is out! This is the strongest release ever and sets a new standard for our Playground.

Here's the outline:

• Updated Shuriken component (Unity 5.3 support)
  
• Increased performance through the Playground Thread Pool
• Playground Trails – Draw mesh trails after particles
• Playground Recorder – Particle recording and playback
• More particle effects and preset categories in the Playground Wizard
• Improved preset search pattern
• Custom Mask Sorting
• Particle Lifetime Strength for Manipulators
• Infinite Manipulator Shape
• WebGL support
• Memory improvements
• Increased color calculation speed
• Lossy- or Local Scale option
• Particle Position, Color, Scale and Velocity functions
• Playground Components Menu
• Improved Editor functionality for finding assets
• Global or Local Time Scale
• (Bonus) A simpler and faster alternative to Playground Follow
• (Bonus) Spline Meshes w. Perlin Noise

Read more about the update here.

Good to know:
1. Particle Playground 3 is backwards compatible with any Particle Playground 2 version, but make sure to backup your project before installing version 3 over a previous version.

2. The 3.0 version has a small hickup where alt+tab out and back to the Editor the Playground Manager can sometimes set particles to not calculate by itself (Playground Manager > Advanced > Calculate Particles). Make sure you have the latest version 3.0.1 to mend that grumpy behavior.

3. The preset categories are set by the project folder structure in Particle Playground/Playground Assets/Presets/. Add a folder there to create a new category. This will soon be possible through the Playground Wizard. The Preset Wizard can although send particle systems into these categories, where you'll also find two additional categories called 'Uncategorized' and 'Resources'. Uncategorized means that the preset isn't living inside a folder in Particle Playground/Playground Assets/Presets/. Resources means that the preset will end up in Particle Playground/Resources/Presets/ and will always be compiled along with its dependencies to builds. (Paths are relative to what you have specified in the Playground Wizard's settings)

In the near future:
- Extending further upon the new Shuriken system (Vector3 rotations).
- Extending upon the Playground Trails functionality (point creation smoothing).
- Local / Global Snapshot transition support & nearest position transitioning.
- Investigate if we can go full SerializedObject on the entire particle system Inspector to give better Editor functionality.
- Handling preset categories through the Playground Wizard.

I'm also looking forward in extending the effects database over time with some improved standard effects. Have fun in the new Playground!

 

Congratulations, Save! The new effects look absolutely awesome and there's lots of lovely feature goodness to boot. I'm especially loving the Playground Trails addition and the manipulator enhancements. I know I've got uses for those right out of the box!

Thanks for creating and continuing to improve this amazing asset.

Cheers,
James

 

Thanks a bunch James!
The video in itself is not really informative but more videos are coming to show what's possible. The more technical stuff like the Playground Recorder needs proper video guides.

 

dude thanks so much for your continuing hard work and dedication. glad I could help iron out some issues. by the way the conference at ASH2015 in Orlando was a resounding success, everyone absolutely loved the bloodvessel scene. this is where I used your plug in.

 

Playground Trails – Draw mesh trails after particles. Love it.

 

Hey Save,

Really cool stuff with PP3. Awesome work!

I'm having an issue with the Playground Trails though, in edit mode the hierarchy root is going crazy with almost 400 "Playground Trail" objects. If I try to delete them they come back. Any way to clean this up?

Additionally *sometimes* I'm getting rendering issues when the trails are recycled, and are drawn between the end point and start point. Any fix?

 

Awesome! Glad it finally got put together. Feel free to showcase!

Thank you! That sounds awful, could you provide some steps to reproduce that behavior? They parent themselves to a GameObject in the root in OnEnable, then upon OnDisable the intended behavior is that they clean up.
I didn't dare to hide them yet due to unexpected issues like this.

Second issue, does it make a difference if you disable multithreading on the trails and on the particle system? Is it during Play Mode and/or during preview? Does it happen on all particle systems with trails or just this one?

If possible feel free to send me the particle system with the trail component in a prefab and I'll have a closer look. It should be a quick fix which can go out live quite fast.

 

Updating the release video due to very valid feedback of it not being informative enough. I hope this emphasize the update better: