Particle Playground

@save: Thanks for all the help! Just want to check in order to set the animation to loop infinitely I just set Cycles to -1 right?

 

No problem! You would have to set the animation by the curve as it's the only way to tell the internal speed (multiplied by Cycles) and direction of the animation. X 0.0 is the birth and x 1.0 is the death where y 0 is first frame on the atlas. Hope it makes sense!

 

@save: Thanks for the advice, yes after you explained it and I took another look at the curve it made a lot more sense thanks!

 

Ok perfect! Glad it could be sorted out.

 

Is it possible to emit meshes or gameobjects with the system, like an animated butterfly ?

Also can i get particles to flow on any surface with a collider ? Like water flowing down a slope (a collider that is dynamic and not pre-defined for the system)

Or a flamethrower that interacts with the player ?

Also a suggestion, the addition of some cool preset spell effects would be both wellcome and a huge advertisement for the system, a very big selling point imo and would show how this system could be used for such effects with all its features so we could get started faster.

 

Looks good ! i am thinking about purchasing, can you please let me know if it is possible to color the particles emitted from a mesh according to the vertex map or texture map of the mesh
thanks

[Edit]
purchased !
please let me know anyways
thanks

 

i was just about to purchase this in the todays deal but recognized with big dissapointment that all code is in js. as this has been discussed before no need to justify you again. just want to tell that you have lost a sale because of this.

 

Thanks, great feedback and questions!
You can emit meshes to the same extent of what the Shuriken particle system can handle. The system only handles particles (billboarded/stretched/meshes).

Particles interacting with surfaces is possible, and a great magnitude of them in most cases. It's designed to calculate collisions from a non-framerate-dependent point of view where particles can have high speeds. The collisions doesn't handle different types of friction at the moment, I'm hoping to improve this soon. Flamethrower is a big yes. If you're ok to wait a couple of weeks you'll be able to get a separate pack which involves fire (without having to own the framework). I'm currently working on (quite extensive) extensions to the framework which is all about dynamic presets. Spell effects would be a perfect match so I'll definitely look into it when time is right!

Thanks for the interest! When using the source mode "State" you can construct particles from meshes where you can apply a texture to get the color at vertex position from the UV mapping. There's no support (at least not yet) for texture mapped skinned meshes. Using a state like this with a transform attached will however let you move it around, rotate and scale it freely, but never animate.

Hope it answers your question, otherwise feel free to ask for more details of course!

 

I totally understand, it can be a mess working with both languages if you need to script towards it. I'll be looking into this further down the road, I'm not quite there yet but I'm sure there will be a great deal when there's a C# version available as well. I'll let you know.

 

Thanks for the clarifications

Will this flame related pack be a standalone ? If i buy the framework now, will it come with it in an update later or i would have to buy the new pack independently ?

 

Same feeling here, when I read "higly optimized" I expected it to be in C#, I was kind of disappointed when I saw a few JS files.
I'm considering to buy it, but only if a C# port is planned... sometime soon.
Which priority has the porting, how far is on the roadmap?

 

Can you support 3.5.7? I was about to purchase when I noticed 4.3 required.

Gigi

PS - And agree with others, a massively awesome plugin like this should use C#.

 

I'd prefer that the asset is in C#, but I bought it anyway because it is a good asset on an awesome sale today.

 

Hello SAVE I have just purchased your product and I was wondering - could you maybe make some videos showing us how to use the editor to make some cool stuff, sometimes a visual presentation can really help

Thank you dude!

 

It will be in a standalone, these presets are a bit special with many hours of work behind them with focus on quality and interactivity. There is a simple fire preset in the pack you could start off from though.

Understandable! The part of highly optimized is regarding the performance, I'm sorry if it was misleading in any way. It is considered where it will tag along the package, I'm thinking in a zip (if no better alternatives is present at the time from an Asset Store point of view). I'm hoping to jump on this after April, the roadmap for April is mostly set regarding CPU threading with balance load.

I'm sorry there's no 3.5.7 availability, any prior to 4.3 requires rewriting parts of the framework where it's hard to give good support. You have to use Unity 4.3, if there are license issues I can recommend Unity's monthly subscription, it has been amazing!

Well great thanks, you can look forward to using C# later on then!

 

Hi there XCO! Many thanks! I really should, I'll have a go at it after next version update, it's one of those lost parts during development. The manual will explain most of the functionality available (but not really what happens in combination of actions) - and the presets cover some areas, hope this will do for a bit.

 

Hey save!

I have an arcade game with lots of enemies, each with their own color. Upon being killed, I want each to explode with their own color. I've tried two approaches so far:

• Call Emit() always on the same particle system. I guess that replaces the scriptedEmissionColor though, as the on-screen particles also change color.
• Instantiate a new instance of the particle system prefab, then call Emit() on that. That only works if I do it in a coroutine and call "yield return null;" between particle system prefab instantiation and Emit() which is a bit of a bother. Also I'd need a lot of particle systems for that which reflects negatively on performance.

What do you think would be the best way to achieve the effect I describe above?

Cheers!
Tobias

 

Does this run in dx11 mode? Compatible with the rift?
Thanks

Edit: Dx11 works well

 

Well, I suppose I'll take this as a "yes, I'm definitely going to port it to C#, don't worry, just be patient", so I'll make my decision
EDIT: I'm in, waiting for updates! ^_^

Other products in the store that wanted to ship 2 different versions of the package usually submitted a .unitypackage containing both the documentation and 2 other .unitypackage ready to unpack, one for Unityscript and one for C# (or even a DLL as third choice).
Speaking of performance comparison (C# vs Unityscript with or without #pragmastrict), I suppose this has been already covered elsewhere, much depends on the coding.

Concluding, please add C# support asap, I personally prefer having less features but being able to extend the package without having to do some ugly criss-cross scripting in future projects
(sorry for the extra emphasys on this, I believe it's a great package, it just needs to be more C#-user friendly )

An unrelated suggestion: I think it would be a nice idea to add an interactive Webplayer demo to the entry in the asset store - I personally love to touch the product with hands before buying, and I'm quite sure I'm not alone

 

He has, but he hid them well: Go to his page. See the videos? There are tabs above them: "Videos", "Images" and "Demo"

 

I totally missed that tab when I looked, thanks for pointing that out

 

yeah c# is the way to go

 

Hi Tobias!

Interesting, I think your first approach is good. You definitely should be able to emit different colors from there so current behavior is a misshap by me, let me work on it for next update. Sorry and thanks for finding that one! Improvements coming.

Both should run well. There are no compute shaders involved though to utilize the GPU in the Playground - you would have to go with TC Particles for instance, PP is waiting for the Shuriken to evolve as it is now (I just don't have the necessary manpower to launch that extensive project).

Ah, great thing! Your assumption is absolutely correct, just be patient and I'll try to make it happen asap.
Thanks for tips, that will be good to have when I hit that spot. As stated there are two demos available on the official site, feature demo isn't exactly up to date but shows many of the techniques available. That scene is also available (with script examples) in the package, along with a couple of other examples.

 

@Save,
Brand new user here, love the plugin thus far.
How can I do a 360 degree burst type spray effect? Like an explosion type effect. Can't seem to get one working. I also am using a plugin called Ferr 2D, its a 2D terrain creation tool and I can't seem to get the particles to collide with it although, they collide fine with a standard box collider. Not sure why it wouldn't collide, the terrain just has a collider on it...

 

Happy to hear!
To make an explosion in all directions you could set the lifetime sorting to burst, this will force all particles to spawn at once. Then for the explosion direction set initial velocity to negative and positive min and max in all directions (see image),



Another way of doing it is to use a sphere, for instance the Starburst preset is constructed that way where every particle inherits its direction from each normal on the sphere. To utilize a mesh's normals you use the Initial Local Velocity (which also applies to transform directions).

I'm not aware of how the colliders in Ferr2D works, are they generated as regular mesh colliders which can be calculated by the physics engine (and applies to standard rigidbodies?). If it does, you could first check the layers they belong to, (PP's collision mask should by default be set to "Everything" though), second check the collision matrix found in Edit > Project Settings > Physics so all layers are set to collide with each other. If Ferr2D uses its own collision solutions we'd have to investigate further, I'll try to connect with Nick in that case.

Hope it helps, otherwise feel free to ask for more details of course!

 

Thank you for the detailed response. I should be able to create the effect i'm going for with those details.

As far as Ferr 2D, I believe it generates as mesh colliders but does not have a rigidbody ever. I checked all your suggestions in regards to the Collision Layer Matrix and made sure the layers were set up to collide and I still cannot get them to collide. I think ill send a tweet at Nick and see if he owns your plugin by chance, then he could take a look at it maybe.

 

Ok great! Get back to me if you experience issues.
I've sent a query to Nick addressing the issue, will get back with more detailed info as soon as possible.

 

Great! Looking forward to the next update then!

Some more features I'd be interested in, if they aren't possible yet:

• Being able to use Emit() on a particle system right after instantiation
• Knowing when a particle system has no more active particles.
• Using sub systems

Also: Is there any easy way to release particles in a circle (for a 2d game) or do I have to make a mesh for that? If I use -10..10 forces for x and y, the diagonal axes are longer than the horizontal/vertical axes, making it look more like a box: http://puu.sh/7mWY2/e5fa5c6003.jpg

 

I'm pretty sure I just asked the same question and Save responded to me. Take a look a few posts up!

EDIT: I think I see what you mean TobiasW. I'm using a sphere to shoot my particles, but it does do a square shape like in your example instead of a circle. Strange.

 

@rxmarccall:
My question is slightly more specific. -10..10 doesn't do a circle and a sphere is not 2D. If particles also fly in z direction, I can't have anything in front of it safely.

 

Ah yes, sorry silly me! The negative/positive method can work in some cases but not for a 2d circle of that magnitude. You could setup your circle using the AngleAxis function in the Quaternion class. I'm out of office (and computer) right now, but please see this for an example http://answers.unity3d.com/questions/27365/radialomni-directional-shooting-problem.html
Thanks for suggestions!! I'll update the package with some emission shapes further on as well.

 

Hmm I'm having some massive performance issues when using particle playground systems in playmode. (I looked at the profiler and is indeed using up 60 m/s CPU time, on a CoRoutine... digging deeper to see which one now).

My use case:

I created two systems. One using the paint tool, another is a simple burst emitter. I then grabbed those made them children of an object in my scene, then grabbed that object and made it into a prefab.

This prefab is then spawned at runtime (its a procedural level), this is when the performance slows to a crawl.

Any ideas on what could be happening here? I'm liking the asset, but this is a pretty huge problem since it makes the game unplayable :-/

 

Couldn't dig deeper into it with profiler.

I did do a quick test and found that if I disable the playground manager object that gets instantiated, the performance issues are fixed. Though this isn't exactly a great solution for me since I'd rather not have to write extra code on my end to address it, plus I'm not sure what the manager is doing on it's end atm.

 

This sounds really unusual, I think we have to dig a bit to find out what could be the issue. I'm seeing around 15 ms on older hardware (Macbook from 2011) in editor with 10 systems simulating 1000 particles each. How many prefabs are you spawning and how many particles are you trying to simulate on those?



I'm sorry you experience this in your project, feel free to send the scene to support@polyfied.com if you want me to have a deeper look into what could cause this.

The Playground Manager is the object driving all the particle systems in the scene, it also manages the global manipulators, contain some general settings and is serving as a wrapper for many of the Playground functions. It's needed in the scene to be able to utilize the framework.

 

Here we go Tobias, hated to leave you hanging with that half solution. Here's a way of doing it with very little math going on as well, just using the rotation of the transform. The trick is to call Update on a Playground system between emissions when working with emitting several particles the same frame.

Code (csharp):

1.  
2. #pragma strict
3.  
4. var numberOfParticles : int = 30;                   // The number of particles to emit
5. var force : float = 10.0;                           // The force to emit in forward direction
6. var yieldBetweenShots : float = .0;                 // The seconds between shots (if any)
7. var rotationNormal : Vector3 = Vector3(0,0,1);      // The axis you want to rotate around
8. var color : Color = Color.white;                    // The color of particle
9. var parent : Transform;                             // The parent to particle (can be null)
10.  
11. private var particles : PlaygroundParticles;
12.  
13. function Start () {
14.     particles = GetComponent(PlaygroundParticles);
15.     var thisTransform : Transform = transform;
16.     var rotationSpeed : float = 360/numberOfParticles;
17.     for (var i : int = 0; i<numberOfParticles; i++) {
18.        
19.         // Emit a particle in rotated direction
20.         particles.Emit(thisTransform.position, thisTransform.right*force, color, parent);
21.        
22.         // Rotate towards direction
23.         thisTransform.Rotate(rotationNormal*rotationSpeed);
24.  
25.         // Update this particle system between shots
26.         Playground.Update(particles);
27.        
28.         // Wait for next (if applicable)
29.         if (yieldBetweenShots>0)
30.             yield WaitForSeconds(yieldBetweenShots);
31.     }
32. }
33.  

Hope it helps, or at least is a start to something you can work with!

Anyhow you can expect some improvements further on as the Script mode isn't fully in its ace yet. We'll get there!

 

@Save,

I'm mainly on Mobile,

Very excited to try out the project and ran the example Manipulator on an iphone 4 and got a FPS of 2 to 3.
This makes it totally not useable for Mobile.

Is there a setting that I'm missing ?

Edit: Tried the other examples:

Features - 1-2 fps.
Image State 2 fps.
Paint 12 fps.
Procedural Mesh - hanged at unity start up screen.
Thunder 3 fps.

cheers.

 

Doesn't sound quite right, wonder if it's connected with the same thing Rico is experiencing. I'm testing it on mobile during development, it's running well on an iPhone 4S where you even should be able to extract particles from skinned meshes with ok results. So something is terribly wrong.
Is this in an empty scene with only PP running? What settings are you using and how many particles are you simulating? You're always welcome to send the project (preferably as stripped down as possible) to support@polyfied.com so I can run some tests.

Edit:
Let's see,
-Which 4 generation is this?
-What OS version?
-Which version of Unity?

I'm about to run some profilings on upcoming update, so let's start at that to see if we see the same thing. I'll get back to you ASAP cause this isn't acceptable behavior, but it's hard to tell what could be wrong right now.

 

What I did:

Imported the asset into the project, ran the example scenes as-is , not modifications at all.
Publish to iphone 4.

Build settings:
.Net 2.0 Subset
Device SDK
Target 6.0
Stripping Disabled
Slow and safe.

btw, I think iphone 4 and iphone 4s there is a big difference in graphics performance.

 

Ah perfect! Hmm yes there's a great difference using particles on phones prior to 4S, a previous iOS project I had to remove all particles (vanilla Shuriken back then) to make the project run. All of the example scenes use a heck of amount of particles, you won't be able to run those as-is on a phone prior to iPhone 5 I think. I actually don't think this has to do with PP but how phones handle computing thousands of particles in any framework environment.
Having a project for mobile you'd use as little particles as possible (around 100 maybe), there's only so much particle pooling can do to performance.
Anyhow, will make sure to profile upcoming version to see if there are any mishaps by me or if this is just standard behavior for old mobile devices.

 

Just tested some of the examples on Iphone 4s.

Using CodeStage Advanced FPS Counter from asset store to measure run time fps.

Manipulator 5 fps.
Paint 30 fps.
Procedural Mesh - works, 6 fps.

Edit:

Features - seems to be running but fps is showing only 4 fps.
Image State 4 fps

 

Thanks rocki it's good to have some data to measure with.

Keep in mind that the example scenes isn't intended for mobile, I'm surprised they even start. You can't expect to simulate thousands of particles on mobile hardware. When working with mobile try to keep Particle Count as low as possible and try to use as few manipulators as you can. Best approach as with any device with tight memory and CPU, use scripted mode where you make sure you only have one particle system for many of the visuals happening at the same time. The PP's particle pool will help a lot in this case as the particles won't need to address fresh memory on instantiation, but as previously stated there's only so much that can help get things running on low-end devices.

I think it would be a good thing to have a couple of mobile ready presets, and a mobile adapted example scene. It's understandable that you expect it to run immediately out of the box with the presets and examples, I get that. Let me work on some mobile examples where I can show some script examples as well. The framework is so new so I haven't had the time for these things. ;-)

 

Would you consider a request to create Demo Scenes specifically for Mobile.

It would make it much easier for those publishing to Mobile to learn from.
These demos can show case how to best get the most out of PP for mobile for various effects.

At the moment, there are too many factors and variables to take into account of. With a focused set of Mobile demos, it will help us to make the best use of PP for mobile.

 

Will definitely do, it's a great approach I think. I understand the expectation to get a kick start with using the framework, and this should apply to all platforms. Will take some time to get things in place but hopefully have an update addressing this in a couple of weeks. Thanks for understanding! I really appreciate that you help out with testing it as well.

 

Not a problem,

I understand that it's quite a bit of work to make demos for both desktop and mobile. As for me, I was excited to try your package because it was advertised as great performance on mobile. This was why I expected that the demos should have worked for mobile. Looking forward to the demos when you get them ready.

Cheers.

 

How far is DX11 support on the roadmap?

 

Totally understand! The reason I've pushed the iOS/Android availability a bit extra is that I got so many questions if this is available for mobiles. Generally it has been proven having better performance on mobile than vanilla Shuriken thanks to the reuse of particles in built-in arrays.
I'll let you know when the update is out addressing this! Great feedback btw!

It's very far. This is something that has been a high priority during early development but has come to change recently. I just don't have the resources to make it happen and the framework needs to evolve in many other directions on beforehand. I honestly didn't think it would get this big and have so many users so quickly, where much of the feedback is pointing towards making the existing tools better and increasing performance in a multi-platform perspective. This is much more in line with what I'm capable of at the moment and what the general user wants as it seems. Hope you understand my choice of path for the roadmap.

There is a great framework available though, I'd jump on to that and never look back if Dx11 is needed in the project.

 

Hi save,

It seems that Particle Playground is causing some issues with Playmaker as I (as well as a few other Playmaker users on the forums) have experienced.

With Particle Playground and Playmaker both in the same project Playmaker seems to not save any changes made to FSMs when deselecting/reselecting FSMs or when returning to edit mode from play mode.

It seems to be common issue with Particle Playground in particular as Playmaker had a similar issue a while back when locking an FSM, but this bug has been fixed a while back and none of the people struggling with the problem seem to be using locks on their FSMs either (including myself), lastly it seems almost all of the people still sitting with this problem have Particle Playground installed and wen deleting it from the project the problem gets fixed.

Here is the link to the Playmaker forum thread:
http://hutonggames.com/playmakerforum/index.php?topic=6109.0

Hopefully this wont be too difficult to figure out and fix as both plugins are integral parts to our game and probably to most people who are customers of both plugins as well.

 

Thanks for the thorough info, perfect start for us to sort things out. I'm not sure yet what could cause this but I've reached out to Hutong to see if they have a clue of what's going on. I'll get back to you about this as soon as I know more. Thanks!

 

Thanks a lot!

Why do I have to call Playground.Update though? Because of the rotation? And how expensive is that call?