Particle Playground

Hi Save is there any way of making the changes that manipulators make to particle properties permanent for them until they die ? I've got my dynamic plasma spline working quite well with particle playground except for the colour change I want. I'm attaching a particle emitter to the spline , moving it along it and setting the particle lifetime based on the length of the spline so that they disappear at the end of the spline. In my game the user can pick up powerups that set fire to the spline and make it change colour. To do this I want to be be able to send a colour manipulator backwards down the spine and colour all the particles. I can get it to change the colours when the manipulator moves over them but as soon as the manipulator moves past them they return to their normal colour.

Also if there is any beta stuff you want tested I am happy to test it out.

By the way, are you still planning on making your own gpu accelerated particle system ? If so you might want to either wait for unity to release whatever cross platform computer option they decide on or make your own opencl dll and use that rather than just directx 11 compute shaders. You might want to do what the fluidsim plugin does and have a cpu based version that anything can use and then add additional support for opengl acceleration and directx11 support with them being used if available on the platform. It will be interesting to see what unity does in this regard as apparently even mac os mavericks doesn't support Opengl computer shaders , only opencl .

 

Can't seem to figure out how to spawn a particle system on a prefab at runtime. ie shooting objects with a system attached. Tried various ways of setting it as a child of an object, but to no avail. Also tried to create the system in the scene and then set the source object as the prefab, but the particle doesn't like that much either. Could someone please explain how you can attach the system to a prefab? Or at least help me to understand why that's not so simple as I would have thought it would be?

 

You are a beautiful man Save!!

did I say you are a beautiful man?

oh let me say more clearly ..

You are a beautiful man Save!!

 

Hi Ian!
I'm happy to hear that you're using it in your game! Let's try to figure out what could be the issue. It sounds like you could use a larger size of your manipulator (unsure about how it will work with your implementation), either a box-shaped where you resize the extents or a spherical where you change the size. It's possible to color in range of the manipulator and set the new color during the lifetime by enabling or disabling Only Color In Range (see attached image), this should also work with lerp transitions both ways.


It sounds a bit though like what you would experience if new particles would emit after the manipulator has passed, but having a larger manipulator always covering the entire area during its period of fire should solve it (if you move it from start to end while scaling you should be able to simulate the moment of combustion as well). If you feel like I missed something please get back to me, preferably with an image if you can.

Happy you're onboard the beta! I'll get back to you with the details later on. I need to implement it directly into PP, figure it's the best way to get user feedback and data from machine hardware at the same time.

Still planing on going with GPU acceleration, but first I want to try to take another route which involves threading. I've been in contact with David Helgason a bit about it and it looks like Unity devs can give some (limited) input around that area, which would be a great help in the first steps.
I'm not there as a programer yet with the GPU, so I figure I stick to areas I can evolve better right now. I agree, OpenCL would be the choice, Dx11 is far too limited of a platform. Thanks for the tip, Fluidsim is an interesting plugin!

Thanks luthor, you just spotted a bug! The issue seem to be connected with the particle system not initiating in correct order which makes it unable to attach onto the Manager. Here's a solution before I release an update,

1. Make sure that you already have the Playground Manager in the scene (use the Playground Wizard and press Create under Playground Manager).

2. Add the particle system to the Manager on creation:

Code (csharp):

1.  
2. var prefab : GameObject;
3.  
4. function Start () {
5.     var particles : PlaygroundParticles = Instantiate(prefab, Vector3.zero, Quaternion.identity).GetComponentInChildren(PlaygroundParticles);
6.     Playground.reference.particleSystems.Add(particles);
7. }
8.  

Let me know how it works out!

Haha why thank you ZJP and MoHoe! Let's hope all plans works out, it's a win-win(-win) for everyone involved.

 

Hmmm, not sure I understand. Is that supposed to be a new script attached to the object prefab that gets spawned at runtime? I ask that b/c i'm not that familiar with js or monodevelop, so I can't tell if that code is calling to the manager to tell it to attach the particle system named to the prefab on creation, or what. Additionally could you explain if this will allow me to reference the same effect for multiple prefabs at a time? I would assume it would work that way, but again, my javascript is pretty weak.

Thanks

 

No worries! Let's go through it more thoroughly.
The essence of the solution is to get a reference to the particle system that you're spawning and then attach that reference to the Playground Manager.

Code (csharp):

1.  
2. var prefab : GameObject;
3. /* The object you're instantiating (in your case I assume it's the parent where the particle system is childed). I added this just to show you the example, so change "prefab" in the code below to the GameObject variable name you're instantiating. */
4.  

Code (csharp):

1.  
2. var particles : PlaygroundParticles = Instantiate(prefab, Vector3.zero, Quaternion.identity).GetComponentInChildren(PlaygroundParticles);
3. /* This creates a reference to the particle system that is instantiated along with your prefab. The variable "particles" can now be seen as the particle system itself - you could use this to script towards it for instance. */
4.  

Code (csharp):

1.  
2. Playground.reference.particleSystems.Add(particles);
3. /* Here we add the particle system reference to the Playground Manager's list of particle systems. "Playground.reference" is the reference to the actual Playground Manager in the scene, where "particleSystems" is the list which controls all particle systems within the scene. */
4.  

Every instantiated prefab with an attached particle system will need to execute the code above to run. However, instantiating a preset should run fine without having to add anything else than the instantiation code.

Code (csharp):

1.  
2. var particlePreset : PlaygroundParticles = Playground.InstantiatePreset("Name");
3.  

But then you would have to set the positioning and any parenting by hand. This is however quite quickly executed as every particle system is adapted to cache things about itself. For instance:

Code (csharp):

1.  
2. particlePreset.particleSystemTransform.parent = yourPrefab.transform;
3. particlePreset.particleSystemTransform.localPosition = Vector3.zero;
4.  

Keep in mind that this will be fixed in next update, where you at that point can remove "Playground.reference.particleSystems.Add(particles);". I'll implement a check for duplicates as well but just to be on the safe side.

Hope it helps!

 

As an update to previous post, I feel like I might have complicated things if you're unfamiliar with scripting. You could of course create a script and attach to every particle system that is instantiated within a prefab. Please follow these steps if you had troubles with the previous,

1. Create a Javascript somewhere in your Project (does not matter what you name it).

2. Copy-Paste this:

Code (csharp):

1.  
2. #pragma strict
3.  
4. function Start () {
5.     if (Playground.reference) {
6.         var particles : PlaygroundParticles = GetComponent(PlaygroundParticles);
7.         if (!Playground.reference.particleSystems.Contains(particles))
8.             Playground.reference.particleSystems.Add(particles);
9.     } else Debug.Log("Please create a Playground Manager in your scene from Window > Playground Wizard > Playground Manager > Create.");
10. }
11.  

3. Drag and drop the script to your particle systems that are within a prefab.

Alright, let me know how it works out!

 

Sharing your own particles is soon ready, being tested right now and it's working swell.
Along with that I'm throwing in a filter search so you won't go crazy amongst all presets. Looking forward to blow up the Asset Store with you guys!

 

So, you never sleep? Seriously, what time is it in Stockholm?

 

Haha, same goes to you I suppose. It was closing in on 4am. I wrote about 400 lines of code approaching a method which appeared to not work in the end so I obsessively rewrote it. Having trouble with letting unfinished stuff go, the bigger the project, the bigger obsession. :-D

 

Another feature coming up next version is Lifetime Offset. This is handy to set particle systems in sequences with each other or to force instant appearance on first frame without fade-ins. Think of it like a time scrubber which goes from negative max lifetime to positive max lifetime for the first lifetime cycle, which affects all later cycles as well.

For instance, having a +0.1 offset on 10 Playground Runways:


One thing I forgot to mention more detailed last update was the Overflow Mode: Source Point. This enables you to offset the overflow of source points with the source point's normal direction in account. This makes you able to for instance create several beams from several source points within a single particle system.

Using the method on the Playground Light Sphere and offsetting 0.1 units each overflow step:

 

It is that fantastic obsession you have that has led you to create an awesome package!

 

Haha Thanks!

 

Got it working. Thanks for the explanation of everything. works great.

 

Perfect! Happy to be of help.

 

Finally, version 1.13 sent to review!

Opening up for this:


What it basically means is that you're encouraged to create particle presets and publish to the Asset Store.
There has been a lot of back and forth with this how to tackle what technically can be done vs not distributing the entire PP-framework in a single preset package. I've learned that serialization and dependencies can be really confusing, but as long as you manage to keep inside the AssetDatabase and do very few of your own fileIO stuff you're kind of in a safe spot...
Anyhow my first solution was to stump the exported package with a non-running version of a preset, where the full PP-framework was required for it to run - meaning you would probably have to tackle a lot of "this doesn't work" from customers. This actually made me sleepless haha. I reworked that model thank god and came up with a solution where your published preset will always run, no matter if the customer has PP installed or not. If a customer doesn't have PP he or she cannot edit the preset (at least in an intuitive way) where they'll lack the editor scripts. Keep in mind that if you do any scripted presets you have to think of the customers that won't have the ability to customize the particle system. A good way of determining how a preset will be like for a customer that doesn't own PP is to enable debug mode on the Inspector (in v1.13+) - where PP's editor scripts will stop the layout for the particle systems and the manager.

So now you can go crazy with extending the framework, giving presets new abilities through your own scripts (look at the Laser preset for an example), or just come up with new combinations of settings. And best of all you can make money in doing so thanks to the Super Amazing Asset Store Team.

More information on the official site on preset publishing, please get familiar with it before you start your publishing career.

Next up I'm gonna try some CPU related solutions along with building a new particle system... I'll try to go out once in a while as well.

Please let me know your thoughts around the preset publishing after reading the guide!

 

Hi is there anyway of having the systems under a different manager or something, or at least a way to separate each particle system so that they dont all interact with each others settings and manipulators (I know you can use layers, but it still seems to influence other particle systems in some way as when I bring in one of the preset together into the Manager I already have containing 2 different particle systems and a manipulator affecting one of them I cant get the preset to show at all).

The current setup also seems like it could get messy when making prefabs that contains mulitiple layers of particle systems and then having all those layers piled up under one Manager. If there was at least a system in place that when you save a preset with multiple layers that it at least groups all the different particle systems of that particular preset under a unified parent object or a way to manually group systems yourself, as to not clutter up the the manager too quickly.

 

Hi!

Sorry there's no current way of running several managers in the scene. I like the idea of being able to group particle systems, let me see what I can do there! Do you think auto-grouping in regards to their current parent would be a solution? That way we wouldn't have to manage things so much. Perhaps being able to group by sources would be something as well.

It sounds like your issue is related to the known bug in v1.125 where having particle systems in prefabs won't kick off, v1.13 is currently under review. I'll send you a pm so I can help you get things up and running more quickly.

 

Well currently I have an inner core effect for my spell that is running off of a World Object as its Source (a simple sphere). Then I have the forces and velocities as well as a repellant manipulator set up as to create a white core sphere with a green particle Vortex. Then I have another particle system for the outer core of the spell that is set to a different World Object as it's source (also a simple sphere just slightly bigger), this particle system still retains the ball shape but has the particles floating a little bit up with a low negative gravitational force and a additive velocity property manipulator makes the movement a bit more randomized.

The problem is I want to be able to create empty objects, place the particle layers and source objects underneath the empty game object and then be able to save the whole empty game object as a prefab, even if I cant use the Particle Playground Wizard's preset saver and have to drag them to my project window and manually make it a prefab .

We are going to have multiple different spells all with different layers that have to be spawned into our FPS player's hand when switching spells. Then we are going to have different multi-layered projectiles for each spell so it can become quite intricate if we need to load different presets via script to load the correct presets and then still place them under a parent object or organizing different layers for forces and collisions (especially in terms of the projectiles). So ultimately the easiest would be if I could just place all the different particle layers and source object under one empty game object and drag that into my project view to create a normal prefab.

 

Also it seems that manipulators relating to specific particles systems and layers dont seems to save over properly in the preset and there also seems to be some occasional glitches (after an extended period of time) when having more than one particle system present and each of them having their own respective layer and manipulator (the particles seem to glitch in these rapid repetitive pulses and dont follow their settings or manipulators anymore, when I remove the manipulators the gltich goes away after the particle systems refresh but then I lost all my manipulators).

 

First of all, interesting use of PP, feel free to showcase later!
Having several particle systems within a hierarchy will be possible in v1.13. Just tested and it should be fully functional to stack several particle systems into a prefab then just drag that into the scene where all source objects should remain connected.

It sounds a bit odd, I haven't experienced anything like this during development. You're always welcome to send your scene (preferably as stripped down as possible) to support@polyfied.com if you want me to take a look at it. Otherwise I'll try to see if I can reproduce what you're experiencing.

I'm starting to wonder if a local/global take on manipulators would be good, then you could save them in your hierarchy within a prefab so they could be connected to a certain particle system preset immediately on instantiation.
You have some really good points here, I can see the shortcomings in the current layout for sure with how you'd like to use PP. Let me see what I can do, it's these type of user case scenarios that is really improving the framework.

Edit: Bug found on property manipulators - additive velocity when set to use "Local Rotation". They're not frame dependent so please don't rely on their current strength. This will be fixed in v1.14 currently in the cooking...

 

@save: The glitch doesnt seem to be a problem and it only happens in the editor, when I hit play it fixes itself (in the game and the editor after stopping the game), so thats nothing major luckily, probably just a minor refreshing bug.

In terms of the grouping, it actually already seems fine when taking the particle systems out of the Playground Manager parent and placing them under a new empty game object and making it a regular prefab (just dragging it into the assets/project window). Im also able to delete the original and then place the prefab as a child following the player and that also works (it seems there was a problem with my colission set ups for each particular particle system layer).

The main problem stems from the manipulators though, I was able to get the basic look that I want but I can see this being a problem for more intricate stuff. The problem with the manipulators is that they are attached to the Playground Manager and not the particular particle system it is set to manipulate, this causes a disconnection when making a prefab and then bringing it in again. I can just reattach the source transforms manually in the editor to their respective manipulators to reset this but Im not sure how to do this during runtime when switching to a spell making it spawn and then setting the correct manipulators (I dont really know much about programming so I am using Playmaker for all m coding needs but I cant seem to find a way to access the manipulators and their properties via any playmaker actions, might need custom Particle Playground Playmaker actions).

The problem goes deeper though, as it becomes even more complicated when having more than one instance of the same grouped multi-layered particle prefab as then the two different prefabs get effected by the same manipulators.

The best solution would be to have both global and local manipulators. The global manipulators being the manipulators that exist now that are connected to the Play ground manger object, because these are layer based they are great for global effects affecting multiple particle systems (like a vortex portal or a gust of wind in a certain area of the level) but for manipulators that define the actual shape you would need local manipulators that are connected to and affect only the particle system and source they are set up to affect (preferably not layer based and natively only controlling that specific particle system).

Thanks for the heads up on the local rotation bug on the additive velocity manipulator I noticed that particular layer/manipulator is still bugging out from time to time, I will switch it off and check if it helps.

Oh yeah sure, I will definitely post some pics/vids when I have some stuff properly set up.

EDIT: Holy crap just read your whole post and only realised now that you made the same suggestion for global/local manipulators, I agree fully it will be the best approach and make Particle Playground an even more monster of a particle plugin for Unity. And no need to apologise I understand completely that it takes time to perfect the framework of a plugin especially one as extensive as Particle Playground. Really amazing plugin and I know it will just get better.

 

Big Thanks XMachinaX for detailed feedback!

Glitch
That's good and a relief, I wonder if it derives from how I run everything through the update delegate. I'd still like to address the issue, even if it's a minor one that only applies to working in the editor - let me see what I can do.

Playmaker
Sadly I'm not too familiar with any of the visual scripting tools out there and how PP is working together with them. I would guess that they use some great bits of reflection to manage to reach into scripts. This is something I could look into later, I realize that PP, being the visual tool it is, it would be good if it were cooperating with other tools intended to visualize logic.

Local manipulators
I started working on local/global manipulators yesterday, they're soon done and will be tagging along the v1.14 update. I'm glad we were synced in what we wanted to happen with the manipulators. Thanks for all kind words!

Vids shots
Please feel free to cross promote into this thread, or just let me know. I'm looking to improve the playground site in the future with user cases and promote other peoples presets as well.

 

Version 1.13 is out!

Sorry for repeating myself (to be fair this is a new page... ) - but now you're able to create your own presets and publish to the Asset Store. If you wait for 1.14 you'll be able to bake in manipulators into a preset as well. I'm looking forward to see what you guys come up with! And as I said earlier, let me know about your stuff, I'd be happy to promote well made assets on the playground site. You'll find the Publish Guide there as well.

 

Next update just sent to review. Adding this:

Improved collisions
The whole collision system is reworked, you should no longer suffer from leakage at lower frame rates/higher particle speeds (non frame dependent collisions). You can add infinite collision planes, to make sure that your particles are contained within a certain space. Another feature is to randomly offset bounce normal's direction within a Vector3-range (which is great if you want to simulate an uneven surface).
One great thing is that the collision model is much faster to calculate, which makes you able to collide much more particles at the same performance cost as before.

Local and Global Manipulators
Ability to work with manipulators secluded within a particle system - and serializable along with it. What this basically means is that you can create prefabs/presets with baked in manipulators. The manager's manipulator list is renamed to "Global Manipulators" - but is working the same way as before.

Max Velocity
Ability to clamp the velocity magnitude to a maximum speed limit.

 

Nice work Save

 

Thanks MoHoe!

 

@save:

Damn you work fast! Haha, glad that we could both be tuned in on the global/local manipulators idea, I just know it will be an amazing addition to the plugin.

As for Playmaker support I posted a request on the Playmaker forums but the Playmaker team is quite busy. It would be great to even just have playmaker actions that do the same functions as the ones described in the Particle Playground documentation for procedural script manipulations.

I will wait for the v1.14 update before I work on my particles again, although Im quite busy with my menu setups at the moment and Im trying to get that done first.

Again, thanks for an amazing plugin, your dedication and ability to listen to your customers will make Particle Playground more than just a 5 star Unity plugin. Keep up the amazing work.

 

It was exactly what was missing, it's good to have someone else with fresh thoughts into the project.
I'm sure there'll be some sort of Playmaker integration in the future, I can hopefully have time to look at it when PP has matured enough.
Well thanks! It's great to have supportive and idea-rich users as well.


I've been thinking a lot about mine and Ian Stanbridge's conversation earlier. He has some excellent points in there which I just recently understood that in order for my company and PP's future to keep floating I need to change a bit of perspective. I've been too busy with reaching for the perfect tool in development and overlooked some extremely useful facts with Shuriken. As previously stated it's a great particle system and I've come to learn that there are many ways to make it cope with where I think PP needs to evolve. So building my own particle system is put on hold for now - This can however come to change later, I'm just out of resources currently to boot up another big project inside PP.
I'll keep trying to improve the framework of course, so please let me know your feedback.

So, instead of reinventing the wheel, let's find ways to improve the road...

 

Speaking of improving the road, here's what's coming up next corner.

 

Version 1.142 is up! Have a nice weekend people!
http://u3d.as/content/polyfied/particle-playground

 

I'm glad that you are taking Ian Stanbridge's opinions into account his stance on Unity plugins and cross platform support reflects my own, and I also agree it is better for a plugin to build and add on top of Unity's existing structure rather than replacing it, that way if Unity updates it, the plugin can take a hold of the update as well and it also usually allows for better multi-platform support. Cant wait until Unity has proper OpenCL supportm DirectX11 is not a solution at all especially when you are planning support for non-Microsoft platform. I say great call.

Thanks for the update will download and try soon.

 

I agree, would love to see OpenCL support soon as well. If PP gets enough users and has enough voices I think we can make a difference in the forthcoming of the built in methods and access levels of the current particle system. I honestly didn't think we'd be able to extend to the level of control PP has today when I started out with the pixel to particle stuff though.

Great! Let me know how things are running for you!

 

Oh Yeah forgot to ask, how do I assign a sprite sheet to a particle system?

 

I've focused a lot on the rendering part in version 1.5, it'll be ready during next week where texture sheet animation is supported finally. I'll let you know when it's out!

 

Awesum, cant wait! Again amazing work and stellar support Save, Im so glad that I invested into Particle Playground.

 

@Save
Why not with an external multithreading librairie like Loom or UnityThreadHelper. Just choose one. Pretty sure most of your customers will follow you. I'm in.

 

Thank you! I'm happy to have awesome users as well!

It's an excellent idea! So good that it actually is on the long term product plan. ;-) Let's see what I can do, it's still a bit early to invest in 3rd party but I'm looking into other ways. I can say that it will happen, just not when.

 

Hi Save, If you want to do threading you might want to look at load balancer on the asset store. For starters it's free and because it load balances it will scale better across different platforms. If you are looking for performance improvements with particle playground it would be great if it threaded itself to run on the least utilized core's in a system for example.

Would it be possible to make particle playground be able to control and possibly spawn gameobject prefabs as well as just particles ? The reason I ask is that it would make it more flexible. I would love to be able to send a few lights down my plasma trails at the same time as the particles for example or even have particles that spawned new short lived particle systems as the traveled along so that you could chain effects together.

Also would it be possible to add a manipulator that destroyed particles within range of it ? For performance reasons in my game it is better to have my spline object that is longer than necessary and then tell the game how far along it objects can travel rather than trimming it all the time. I would like to be able to add a destroy manipulator a set distance along this spline rather than have to destroy them with particle lifetime calculations.

I discovered the issues I was having controlling the colours was actually to do with the customer shaders I was using for the particles. If a shader has multiple colour channels for example "Emmisive Color" as well as just "Color" it will only change the one labeled "Color" . Would it be possible to add an option so you could set what shader property the manipulator controlled ? Ideally allow it to set multiple colour shader chanels at the same time because I am assuming that it would be more efficient to have one manipulator that changed multiple properties rather than use multiple manipulators.

Speaking of manipulators are you planning to create a node manipulator controller like I mentioned a while ago ? It would be great for example if you had an advanced type of manipulator that for starters could change multiple properties at the same time but could also reference other manipulators in a node hierachy with basic logic functions attached to those nodes. You could attach 3 manipulators to a manipulator controller for example and have them at different positions in the scene. You could then put logic that when particles came in range of manipulator 1 that 50 percent of them were sent towards manipulator 2 and changed to blue while the others were sent towards the positions of manipulator 3 and changed to green. You could then very easily create some very powerful manipulator interactions.

The reason I ask is that I am wondering with my game whether it is best to use multiple manipulators at certain points along my splines to change multiple properties and also to make my own scripts to create velocity manipulators that constantly updated there velocity values so that they always directed the particles in the direction of the next manipulator or whether I am better waiting for you to implement your own system while I focus on other parts of my game.

Thanks and keep up the good work, Ian

 

Hi Ian! Superb feedback and interesting ideas. Thanks, Load Balancer looks like a great tool. It's perfect to have projects to learn the layout from for sure. Cant promise any time frames yet though but I'll get there.

This is something I've also considered and been trying to find the right angle to for a while. I'm thinking some sort of event system. First off in that case I'd want to implement particle-bound events, later with "easy to access"-data to apply to other objects. Then you could tie an object to a certain particle in the lifetime sorting chain for instance. I'll get back to events a bit later, project is still a bit immature to head towards this. I'm currently implementing a higher control where you can decide where and when a particle should be from script. Along with it some useful data can be extracted in return - so I'm somewhat closing in on the area. Later binding an event to that type of "EmitNext" zombie particle system would open up for some really interesting things. Great ideas Ian, just not fully there yet. ;-)

Understand the issue, sounds like something very useful! Let me see what I can do.

I'll have a look into this and what could be reasonably done with connecting into current shader in use. Haven't thought of this at all actually so thanks for bringing it up!

I still really like this idea. I haven't jumped to it yet because of the extra data arrays and nested logic that it needs. It sounds like you can make great use of the local rotation ability of velocity manipulators and rotate them towards target. I would suggest to not wait for this as I don't know when or to what extent I can implement it. However feel free to ask if you run into any technical issues with current functionality of course. All I can say really is that manipulators will evolve and I'll come back to handle this.

Thanks for great thoughts into the project!


The nearest after 1.5 I will launch an extensive preset production. Basically get my own hands dirty in testing the usability of PP, which I'm hoping will lead to further improvements of the framework and a couple of interesting assets as well. This will turn the regular update-cycle a bit on hold a couple of weeks but I'll be grateful for all feedback during of course - and just to be clear I'm still available for support etc. as usual.

 

Version 1.15 sent for review!

This is kind of a big update for all of you who wants to get more control over particles through script and get more control over the rendering parts of particles. (And when I said 1.5 earlier in the thread I meant 1.15, rounding up a bit too much)

Stretch, Scale, Mesh, H/V Billboard
 - Everything that sounds like a gymnastic exercise basically
Playground will now run together with all the different types of particle render techniques available in Shuriken. Finally you can stretch particles based on their direction or render them as meshes. Texture Sheet Animation compatibility is also introduced, but due to the restricted access level you need to enable and edit this directly in the Shuriken particle system. Enable the visibility of the Shuriken component in Playground Manager > Advanced > Show Shuriken.

Reworked Source Mode - Script - Kickstart approach
I think the whole Script as source mode has been proven more confusing than useful. The 1.15 update will lift the core features and present them in the Inspector. It will make you able to script your own source positions using an Emit() call, which gives you control over particles when they appear and how they act.
This can be used in many ways, for instance turning a Particle Playground System into a particle pool where you have great control over when and where a particle exists, at what speed and color. For instance - high speed projectiles with precise collisions, voxel-like objects/landscapes and any kind of predetermined data.

Example:
playgroundParticleSystem.Emit(position, velocity, color, parent);

• Position is set in world coordinates by a Vector3.
• Velocity is set in units by a Vector3. This overrides the Initial Local Velocity.
• Color is set by Color. Use Rendering > Color Source > Source to enable this color.
• Parent is set by a Transform. This tells which object in the scene this particle belongs to when using transform-specific features such as ”Only Source Positions”. This can be used to attach particles to specified objects.

The sweet part is that collisions and manipulators are still available when emitting and controlling a particle like this.

Loop or one-shot
You can now tell the particle system to loop or to do a one-shot (and if it should disable when done).

Set scale on top of minimum- and maximum size
Apply a scaling to minimum and maximum size without having to rebuild the size-array.

Vertex Lit Color shader
A new single colored shader of type vertex lit is introduced. This can for instance be used to give particles a single-colored voxel-like look (especially with meshes) - or to let light affect each particle pixel in a state.


I think that's about it for now! Would be nice to see how you're using PP, feel free to post some pics!

 

Amazing update cant wait to sink my teeth into the Animated Sprite Sheet feature, along with the stretch and scale features I think some real insane stuff can be made. Also that new emit function sounds very intriguing.

Im quite curious what do you have in mind for the next update?

I think maybe Image Effect integration could be quite awesome, either in the form of a manipulator area or a shader, both would be beyond fantastic. Especially for an effect like refraction or a nice blur.

 

Hopefully it'll run well! I had to send another update yesterday as I found some small screwups I made in 1.15 so it might not make it into review during this week. I've been working on some advanced presets lately which will come as a separate pack, I'm really glad I started working with the framework in real scenarios cause I find small things that needs improvements much faster now.

So nearest there's still a bit of work on improvements before I would dare to introduce something new. Then I'd like to go for core features, like events (similar to OnParticleCollision for instance, and if I can I'd like to integrate it visually as well) and some new and extended functionality to manipulators. At the meantime work on a threaded solution as previously mentioned.
I like the idea of image effects, I'm hoping to be able to add things like this later and make presets even more "drop and play" ready. But there are some highly needed things before I can add icing. I think you might be able to find some solutions out there which you can build on top of, for instance: http://forum.unity3d.com/threads/50132-Heat-Distortion

 

Is there a way to emit particles randomly inside a shape like in shuriken ? Also is there a prewarm option ?

I have scenes with some environnemental / ambient particles effects. Using a plane or a picture for the source doesn't seems to be random enough (more like a grid) and then waiting for the particles to move around is too noticable.

Do you have any suggestion for this kind of stuff or should i stick with shuriken for those effects ?


Also i don't know if its possible, but do you think you could add some sort of manipulator that would push particles along a path or spline, with something like : http://pixelplacement.com/2010/12/03/visual-editor-for-itween-motion-paths/
They would'nt need to be exactly on the spline but more like an area of effect around it, same like your manipulators.

 

Thanks Elzean for great suggestions!

There's no direct functionality to emit inside a shape, but you can use the Overflow Offset and scramble the Lifetime Sorting to emit from an offset position from a shape (for instance the preset Matrix Cube where you could set the Lifetime Sorting to something else than Nearest Neighbor to get a different appearance). If you move the source object (rotate/translate) during emission, does that give you a better result? I understand the grid look issue from static positions, let me see if I can do something about that, something like a scrambled offset from source position.
Sorry there's only a limited option similar to prewarming where you can offset to negative lifetime, but this doesn't apply to positions (as they are far too complicated to predict).

I really like the spline idea and there are great ways of using it I'm sure. We've been at that functionality previously in the thread and I understand there's a need for it - it's just that the logic requires some nesting, so I have to wait a bit until the right puzzle pieces is there.
You can shoot a particle in a property (velocity) manipulator's local direction, but it's nothing more fancy than being able to do stuff like this,


Feel free to ask of course if you need more guidance, it's hard to tell exactly what would be a good solution from case to case.

 

Here we go, version 1.15.3 is up! Kudos to the reviewer who did that in the speed of light!

 

Really Awesome Framework.

Great work.

 

Thank you rocki! Many improvements coming up in the nearest as well

 

Sounds amazing especially the event handler, could do some amazing stuff with that feature.

I just wanted to check how do I set up a Texture Sheet Animation? It doesnt seem to be mentioned or explained in the latest manual and I tried to attach a material containing a sprite sheet but even with the Texture sheet animation function eneabled and changing the tiling values doesnt seem to help. I either just get multiple tiny versions of the entire sheet or these ugle bilboard squares that squash parts of the different cells in the sheet but doesnt animate at all.

Any help on the matter would be greatly appreciated.

 

Indeed!

Let's see, the Texture Sheet Animation features are outside of PP's general area, that's why you won't find any info in the manual. The latest update simply sends the life information of each particle to enable animation through the Shuriken. If there were a better access level on some parts of the Shuriken component I would have implemented it more intuitively of course. Anyhow, here's the things to consider when working with atlases:

1. Just for the sake of the step by step, first off enable the visibility of the Shuriken component through Playground Manager > Advanced > Show Shuriken. You will have to deselect and reselect the Particle Playground system's GameObject in Hierarchy to activate.



2. Make sure that you've filled in the X and Y tiles, for instance having a sequence of 16 square images on a square sheet would mean 4x4 tiles. Set Animation type (Single Row/Whole Sheet) and Cycles. The most important thing of all is to edit the Frame over Time with the Particle System Curve. For a simple frame-by-frame animation with constant speed you'd set the normalized zero time on 0.0 at frame 0, then the normalized full time on 1.0 at your max frame (for instance 16).



Let me know how things works out!