Particle Playground

No problems!
Actually after v1.16 you shouldn't have to, it was due to a mistake I made from the scripted emission where forces set the same frame wouldn't be able to apply. The Update call is what's happening each frame on all active particle systems, that is where the calculation loop lives. So it's as expensive as one frame (not sure if that is a tolerable engineer oriented answer hehe, but it's the best I can do).
There's also a circle shot preset thanks to you and rxmarccall which is a bit more advanced than the posted code. More about that soon!

 

You're a demon with this! Updates aplenty. Well today I get a 'day off' because i'm reworking the presentation for a friends game, basically to turn the prettiness dials up to 12, so now i FINALLY get to try this out as part of the package I hope. Smorgasboard of pretty will hopefully result! Also great to see you on top of some of the lists in the asset store, hard work pays off!

As you asked a while ago about me doing a dev diary, i kinda did on another forum, but when i start talking about serious game stuff rather than waffling about intended features, ill put it somewhere on these forums and let you know, should you care aha

 

ALSO NEED I SAY IT, CEE SHARP! aha you must be getting tired of that by now but it only makes sense to do it now rather than later before the project becomes collossal, which it seems it could well do

 

I'm happy to hear you finally got onto it! Don't be shy to post some of your visual results in here if you want. Looking forward to that thread!

C# what's that? :-D

 

Along with a lot of improvements here and there, here's one of the new manipulator types coming up in 1.16. It'll target transforms in the scene, if you don't use a transition you can use it as a teleporter (bringing realism to PP...). ;-)

 

Do you find it funny that my intentions for pp at least to some large degree involve bringing realism to it, or at least not so bright and shiny. Get spooked.

 

That is rather spooky actually!

 

Ok I think I'm on to something useful which works well with the rest of all behaviors finally.
Finishing up the target manipulators, they now handle node pairing with a particle - which makes them able to wander off to their own nodes. A new transition is introduced as well where you can move towards target in a linear fashion over time instead of smoothing towards the end. The nodes are all live in the scene so there can only be endless possibilities to this. Thanks to Ian for persistence and great feedback to make this happen!

 

Trying to get the Playground to tag along Unity to GDC, in a boat. Thought I'd post it here to give some ideas of how to use it...

[video=youtube_share;q6BaPWZ8758]http://youtu.be/q6BaPWZ8758

 

Hi Save

Looks like you have some great updates on the way. Can those nodes change multiple properties such as size and colour as well or just position with one manipulator or is your intended workflow just going to to use the nodes to control positions? Also with your boat video example are those particles just floating freely in the air and then being pulled towards the boat only when it starts being drawn ? Is it possible to for example have a bunch of different objects explode at different locations with separate particles wait for their explosion effect to finish and then have all the particle embers from multiple systems pulled to one manipulator location with the particles only being destroyed after they reach that manipulator?

I have lots of objects that explode into particles at the moment. Originally I was just going to have those particles fade out and die over time but your video has got me into thinking it might be better to have those particles flow into the tail of my plasma spline and be destroyed a bit like your video.

Also is there a way of destroying particles when they move out of view of the camera or get a certain distance away from the player ? I'm thinking that in general with my game I would be better to have my particles destroyed or consumed by events rather than make them fade out over time ?

 

The nodes will only change target to reposition the particles over time. A particle will get paired with a manipulator's set target (which target is determined by a pointer which just iterates over all contained targets when a particle enters the manipulator space), then if a new manipulator with another target appears in its path it will overwrite the previous pair key. During repositioning you will be able to damp velocity, which can be used to create a smoother curve.
I understand the benefit in combining the behaviors to be able to skip a call to a manipulator and reuse the radius/box size. Let me see how I can evolve this, there might be a "combined" manipulator which can take multiple properties up ahead (which uses the same radius).

The particles in the video are emitted from a sphere and is floating freely, they live about 12 seconds and is then being re-emitted from the sphere's vertices. I'm using a local gravity manipulator which is enabling/disabling on interaction, with a high radius and high strength. Yes that's fully possible, it sounds like you could use separate manipulators for each explosion (if you don't like them to all be drawn at once towards target). When the explosion is finished just enable the manipulator and let the transform follow a specific target.

There will be a terrifying manipulator property called Death in next update, it should be able to suit your situation well.
I currently don't want to implement an "on screen" check as that would be a performance killer for sure, but you should be able to use the death manipulator. Let me see if I can implement "is within" or "is outside", that would be running much faster and do exactly what you're asking.

More info soon when update is ready!

 

Playground is now friends with Playmaker. Version 1.16 will mend the issue of Playground hindering Playmaker to save its values. Thanks for your patience all Playmaker users!

 

Whatever I say about my terribly serious game, i'm definitely putting that boat thing in, we need more of this kind of thing

 

More boats!
It's nice what the paint can do, just put up an invisible collider and go nuts.

 

1.16 on its way!

Some noteworthy features and fixes,

• Target property manipulator - make particles travel along nodes.
• Linear property transitions - ability to do property transitions in a strict linear fashion (without smoothing).
• Inverse manipulator bounds - turn a manipulator inside-out.
• Force constraints - Specially for everyone working with 2D, you can now make sure no particles wander off into another dimension.
• PlayMaker support - Playground made friends with PlayMaker.
• Script Mode fixes - Colors and velocities should now stick onto its scripted particle without issuing Update().

Had to hold on to Death manipulators, they would have pushed this update a couple of days, wouldn't want PlayMaker people have to wait.
Now we just wait for review and clearance!

 

Like this?

Yeah!

 

Very nice! My son really liked this, instant fan.

 

This looks awesome. I'm getting ready to begin a new game project that will center around music visualization. Because of this I will need particles that can be easily parameterized within scripts. Will particle playground be suitable for this?

Basically, I want to know how easily particle playground can be used with regard to music visualization?

Thanks in advance.

 

Happy you find it interesting! That's a very interesting question and usage. There are no features integrated for connecting to spectrum data (for instance), but you can always process a source mesh / control particle values / alter manipulators - using that data. I believe it would be suitable, but don't expect any direct input methods from audio, a good place to start is to look at some examples using the GetSpectrumData, such as http://answers.unity3d.com/questions/157940/getoutputdata-and-getspectrumdata-they-represent-t.html. Aldonaletto always has some great intel to share regarding audio.
Hope it makes sense!

 

Giving some thought to the requests on circular emission shapes, here's what's coming up in 1.17!

 

1.16 is out!

Tiny update on 1.17, adding ability to sort your own lifetime by curves as well. Control exponentially increasing.

 

Hi Save

Just a thought. How feasible would it be to add a particle grabber manipulator or function ? Basically it would be a manipulator or tool that could grab all unity particles within a certain range of it and create a new particle playground particle system out of them at runtime ? There's a power up in my game that I would love to be able to be able to blow all particles on the screen away in an explosion. It would be great if there was a feature that could simple let me manipulate particles irrespective of which system they were in.

 

Nice idea! Sounds like a great addition together with an event system, I'm about to jump on that in a little bit. On another note I'm trying to get the 'Death' manipulator in 1.17, it's a bit tricky due to the lifetime sorting abilities. Just thought I'd leave you a notification that it's still in the making. ;-)

 

Ah, here we go, finally got it to play without having to calculate lifetime sortings and has ability to transition. Also works well inverted which I believe would apply to your situation Ian. Moving this into 1.17 immediately!

 

Looks great

 

More good news in a bit.

 

@Save,
I am currently doing a "death" animation that shoots out tons of little read particles that collide with the terrain. Is there a way to make the particles "stick" to the terrain they collide with? Would be an awesome effect for "blood" splatting and sticking or slowly dripping on a surface.

Sorry kind of violent sounding topic...

 

Hehe that's ok, sounds intriguing! Did you try setting the Bounciness to 0? Otherwise if you need the particles to really get attached and have a new parent, I believe you can do this with ease when I get the event system together. Then you'll be able to execute events from one particle system to another (for instance paint at collision positions). It's not in its full layout yet but it'll be quite interesting I hope.

 

I suppose you could say it is for water, ink, or paint ... but since we're talking video games it would probably be mainly used for blood and vomit.

Edit: And venom and acid. And glue. And flaming liquid.

 

@Save, hi there ! Thanks for bringing up to the community this wonderful plugin !
I have a simple question:
I'm using your system with a skinned mesh (our main character), and I would like to "stick" particles to the skinned mesh, so when the player is moving it all particles are following movements. I know that with Shuriken we had the option of local or world, is this still possible to do with your plugin?

Thanks !

 

I'm not sure what this is, but it's made with a single particle system and one manipulator.
A lot has happened the last couple of days where 1.17 is about to introduce some real icing on the cake. Right before we jump onto events and threading, should be interesting!

 

Hi Cayou! Thanks for kind words!
I'm not sure if this applies to what you had in mind, but did you try Forces > "Only Source Positions". That will make all particles stick onto the character on all vertices positions. Was that what you had in mind?

Edit: Ah sorry, to answer your question fully, local/world space isn't entirely implemented. Let me see what I can do before 1.17 comes out!

 

That s a demolecularizer with hypermatter compression of course. I was just looking for one .

 

Kinda great if you want to start your own black hole.

 

Excellent, I'm gonna try it ! Thanks for this very quick answer.

 

Some good news, local space simulation will be ready in 1.17 - taking all manipulators and global to local calculations into account (as expected). You'll be able to find it in Advanced > Simulation Space. Thanks for reminding me about this! It's one of those things that has fallen out of the roadmap notes for some reason.

 

I know this is an older part of the thread, however...

I love everything in the editor functionality but no matter what folder I place either the C# or JS scripts in I am not able to access the Playground classes from C#. I have searched every Google/Forum reference and still no dice. Please tell me that others have struggled with this JS to C# integration and solved it, because the pre-compile special folder scenario is not working for me! Help Please!

 

Hi again! If anyone else is experiencing the same issue, here's the answer from the support errand,

---------

You should be able to script towards it by placing the Playground.js and PlaygroundParticles.js in a folder called ”Plugins” within the root of your Assets folder (see attached image). You won’t be able to get any intellisense though which is one of the limitations in MonoDevelop while using different languages in your project. Please see the available wrapper functions in Playground.js and available variables in PlaygroundParticles.js if you don’t find the manual detailed enough, I’ve tried to structure it to be easily readable with comments as well.



Then you should be able to run the Playground from C#, as an example:

Code (csharp):

1.  
2.     using UnityEngine;
3.     using System.Collections;
4.  
5.     public class Example : MonoBehaviour {
6.  
7.         private PlaygroundParticles particles;    // The PlaygroundParticles object
8.  
9.         void Start () {
10.  
11.             // Get a reference of the particle system
12.             particles = GetComponent<PlaygroundParticles>();
13.  
14.             // Set to not emit, just as an example
15.             particles.emit = false;
16.  
17.         }
18.     }
19.  

---------

Thanks for great feedback as well!

 

Glad to hear that !

 

Personally, I've moved scripts into the Standard Assets (except the Editor part), so I can access with C# to all Js scripts. The problem, as save said, is that intellisense won't work, but that's "ok".
First I was disappointed to found all scripts written in UniScript, but as I can access using C#, it's alright.

 

@save,

My game has a "rail gun" type weapon similar to the one found in quake 3 arena. I'm wanting to have a line of particles drip down after a rail gun shot is fired. I'm unsure of where to start to have particle playground create a particle effect that would follow a dynamically sized line.

I am currently shooting a raycast because i want the shot to be instantanious, but I would like to add awesome particle effect to the shot instead of just showing a boring debug raycast. Any tips on what I might try?

 

Hey Guys,
sorry but i need to ask, im working since two days, to make an exhaust system for my vehicle.

The normal smoke works fine, but i have some misfires, like an little explosion.
But if i drive really fast, the particle is far away from my exhaust.

What do i wrong?

 

There's probably many ways to approach this, but I think the most controlled and optimized would be to run in script mode. Here's an example of rendering the particles in a line from a transform towards a set distance with collision checking, put this on a transform at the tip of the railgun:

Code (csharp):

1.  
2. #pragma strict
3.  
4. var simulationAmount : int = 1000;
5. var particleSpacing : float = .2;
6. var maxDistance : float = 100;
7. var collisionLayer : LayerMask = -1;
8. var color : Color32 = Color.white;
9. private var particles : PlaygroundParticles;
10. private var thisTransform : Transform;
11.  
12. function Start () {
13.    
14.     // Create a particle system
15.     particles = Playground.Particle();
16.    
17.     // Switch to scripted mode
18.     particles.source = SOURCE.Script;
19.    
20.     // Set amount of particles
21.     particles.particleCount = simulationAmount;
22.    
23.     // Zero gravity
24.     particles.gravity = Vector3.zero;
25.    
26.     // Set particles to use lifetime alpha
27.     particles.sourceUsesLifetimeAlpha = true;
28.    
29.     // Set to disable when done (to not calculate when not needed)
30.     particles.loop = false;
31.     particles.disableOnDone = true;
32.    
33.     // Cache this transform
34.     thisTransform = transform;
35. }
36.  
37. function Update () {
38.  
39.     // Fire on input
40.     if (Input.GetMouseButtonDown(0))
41.         Fire();
42. }
43.  
44. function Fire () {
45.    
46.     // We need to activate the particle system again (not needed in 1.17+)
47.     Emit();
48.    
49.     // Set distance to max (this will change if a collider is in the way)
50.     var distance : float = maxDistance;
51.    
52.     // Send a Raycast from particle system's source transform forward to possibly change distance if wall/ceil/floor is hit
53.     var hit : RaycastHit;
54.     if (Physics.Raycast(thisTransform.position, thisTransform.forward, hit, maxDistance, collisionLayer)) {
55.        
56.         // Set new distance if a collider was hit
57.         distance = Vector3.Distance(particles.sourceTransform.position, hit.point);
58.     }
59.    
60.     // Distribute particles in forward direction
61.     if (particleSpacing>0)
62.         for (; distance>0; distance-=particleSpacing) {
63.             particles.Emit(
64.                 thisTransform.position+thisTransform.forward*distance,
65.                 Vector3.zero,
66.                 color,
67.                 null
68.             );
69.         }
70. }
71.  
72. // Turn on emission (needed for particle systems prior to 1.17)
73. function Emit () {
74.     particles.emit = true;
75.     particles.simulationStarted = Playground.globalTime;
76.     particles.loopExceeded = false;
77.     particles.loopExceededOnParticle = -1;
78.     particles.particleSystemGameObject.SetActive(true);
79. }
80.  

You could do a lot to improve the presentation of course, but hopefully that's a start to something great.
We need more script examples as well, I'll try to get better at doing some of those when I've caught up with the framework dev.

Just for the sake of meta/explanation, using a particle system like this will turn the whole playground- and particle cache into a pool for you to address at any time. PlaygroundParticles.Emit() will also return the current particle pointer as an integer, that way you can give it extra properties during its lifetime if you want. Manipulators, collisions, velocities, and lifetime behaviors is still calculated during their lifetime. The things that won't be available is calculations regarding their source position (as this isn't applicable when you determine your own source behavior).

That's ok, it's why this thread is here. If I understand correctly I think you'd benefit in running the simulation in local space. What I think your implementation suffers from is that you actually drive away from your particle system, could this be the case?
Version 1.17 (hopefully available late this week or early next week) will have full support for global to local calculations, you will find it in Advanced > Simulation Space.

 

@Save,
Thanks for the code snippet. For whatever reason, I'm only seeing a single white particle be created when I fire. Are the particles perhaps colliding with the first particle created and just stopping at the first particle created?

 

Try switching collisionLayer to "Nothing", if you get a line then you have a collider the raycast collides immediately with. Otherwise check the particle spacing (but don't set it to 0 as that will enter an infinite loop, quick/bad programming by me... I updated with an if-check before the for-loop).
Did that work?

 

Hmm,
So set collisionLayer to "Nothing" and was still just getting the 1 particle (or so it appears). Then updated my code to your updated above and now I'm not seeing any particle. Changed spacing to 0.8 and still nothing.

Oh, I probably should mention that this is a 2D game.... I forgot this tool is mainly aimed at 3D games.... I'm guessing that really changes things?

 

Interesting, which way are you pointing the transform? Try changing it to iterate on another transform axis than forward (right for instance) in the raycast and for loop. Being in 2D shouldn't matter for the PP framework, but it does for which direction your axes are pointed.

 

I think you are right about changing to transform.right, however I have no particles showing up now since you updated your script above, and don't have access to your script before...

 

Could it be that since Rxmarccall is running in 2d, that he needs to set the 2d sorting layer of the particle system renderer?

 

I have a preset that I built for the death of a player that I am able to instantiate when a player dies and that particle effect does display correctly.