Particle Playground

Thanks for the advice and help save. Ive managed to get the local sapce to move fine in the game.

But I seem to be having different problems when it comes to instantiating the particle system prefabs. When the scen is played and a prefab containing a particle system seems to either flicker profusely before displaying correctly or a white big sphere is created for a few split seconds spoiling the effect. Dont know if this has something to do with the pooling or refreshing of the particles from within the scene.

Any help or advice on this situation would be greatly appreciated.

 

Glad to hear that you managed to straighten out local space! I'll be looking into adding a couple of features there as well, to give more control over what happens in global to local conversion.
The instant sphere flash does sound like something you could experience from pooling, but it shouldn't be visible during warmup. The flickering was something I saw back in the good old <1.1 days, but that should be cured. I'm curious about your scene setup as there seem to be some issues with how PP handles the global time, as well as the pooling. Feel free to mail me your scene and I'll try to see what we can do to relieve you from this unfortunate Playground curse.

 

I think I managed to fix the flickering issue it only occurs when I make changes to the prefab and then leav an instance of it on in edit mode. It also only occurs once and then the next time that I run (while making sure any extra instances of that same prefab placed previously from within editor mode are disabled) it runs perfectly fine. So I think it is just a matter of refreshing once after a change is made to the prefab, relieved that it isnt anything too major.

Im still having trouble with my projectiles though whenever I shoot out a projectile (about once every 0.5 seconds) the instance created still creates the big white sphere. Is there anyways that I can combat this, like better pooling perhaps? Im using UFPS for my FPS needs so the projectiles are firing via their mechanincs, Im wondering if my pooling isnt properly set up with their system.

Edit: I'll try and send through a test project when I get really stuck, but there has been quite a few stuff that I have been able to figure out with a bit of extra tweaking and experimenting, I dont want to waste any effort or time if the problem is my fault so I will send over a test project if I get really stuck. In the meantime I will talk with the guys on the UFPS forums as well for some pooling tips.

 

Alright, almost there then!
I'm gonna spend some time try to reproduce what you've experienced and see if there's something I can do. There is always something that can be done, figure I can move things into previous step inside OnEnable/Awake->Start and might be able to skip one yield to sort things for instance, which should be much more clean. Pooling should never happen on screen, that's something I have to make sure.
I'll get back to you about this when I've had time to dig a bit. Thanks Machina for the detailed explanations in your steps, that's perfect for me!

UFPS looks like a superb product! But I haven't had time to try it out yet unfortunately. I'm not sure if there's something that can be done there in terms of pooling together with PP. I could imagine it would differ greatly upon implementation for your project. I think for FPS and projectiles, PP's upcoming event system would be a great fit - but it's a bit till we're there. By the way, did you see http://www.protoolsforunity3d.com/linked_files/webplayers/E1M1/E1M1_Pixelicious/ - really nice remake. (sorry getting a bit off topic)

 

Thanks for all the help save! Wow there really arent a lot of Unity Asset Store developers with as much dedication and perseverance as you. Hopefully you can figure something out, if you need any more info just let me know. In the meantime I am still trying to figure out UFPS itself as it is and amazingly extensive plugin but has a bit of a leraning curve especially for a non-programmer like me and trying to integrate it with Playmaker.

Wow that Doom level remake is amazing! That was such a treat, seeing as it is one of our main inspirations for our game. Some of the probuilder users are extremely talented another amazing Unity plugin that we are glad that we purchased. Thanks for the awesome share save will share it with some of the other ppl in the team, pretty sure they will appreciate seeing this classic in a new light again as well.

 

Thanks for kind words Machina! It would seem like a missed opportunity considering all dedicated users and all great feedback. Oh yes Probuilders, really inspiring stuff!
I'll get back to you as soon as I've had time to get wiser in your particular situation.

 

Day is here, C# ready and available! https://www.assetstore.unity3d.com/#/content/13325

It's recommended to remove previous installation when updating from a version prior to 1.18. There's no catastrophe if you don't, but you'll have to move the Playground Manager.prefab, Particle Playground System.prefab, the presets, brushes and scripts into their corresponding JavaScript folder. Just ask and I'll try to assist if you bump into troubles updating of course.
If you choose to reinstall, remember to make a backup, especially if you have created your own presets or brushes.

Have fun!

 

Cool, congratulations on the C# release.

A quick inspection reveals some small bugs. You can see it for yourself by removing any JS files that have a C# counterpart and trying to build in VisualStudio.

1) PlaygroundBrushPresetInspectorC.cs:4 [CustomEditor(typeof(PlaygroundBrushPreset))] refers to a JS class
2) PlaygroundC.cs:595 returns false, but an object of type IEnumerator is expected
3) PlaygroundPresetCircleShotC.cs:71 returns false, but an object of type IEnumerator is expected
4) PlaygroundParticlesC.cs:14 [HideInInspector] public PlaygroundC PlaygroundC.reference; contains a dot in the field name (but seems not to be used anyway).

 

Thanks movra! Really thought I'd checked every single bit. Is it by any chance more safe to run Visual Studio than MonoDevelop on debugging for C#? I'll make sure to get an update out ASAP!

 

In this case MonoDevelop shows the same errors as Visual Studio when building. It's just that I use Visual Studio for everything except debugging.

I begrudgingly use MonoDevelop for debugging. Visual Studio has no out of the box debugging for Unity3D. You'd need the commercial 3rd party plugin called UnityVS, which requires Visual Studio Professional or higher. I have never used UnityVS so I don't know how stable it is.

Besides debugging there is code analysis in the form of the open source Genderme for Unity, but I find Visual Studio Pro's built-in Code Analysis more comfortable. Note that the Code Analyzer in the Express edition is not as advanced.

Finally there is the equivalent of a real-time spelling/grammar checker plugin in the form of Resharper. You can try it 30 days for free.

In the end I am not sure any of the software above would have caught the unintended reference from the C# class to the JS class. Maybe a combination of a build automation tool with unit tests would have.

 

Is the doom level included in the pack ?

 

Ah perfect, thanks! Still have some bits to get familiar with and this bumps it up faster. Update sent to the store addressing these minor issues!

Edit: I'll also provide examples in C# next update, currently all example scenes is running JS.

 

Just noticed that the poolling problem only occurs in the editor. If you build out the game, no white spheres appear, so it isnt that much of a biggie for us right now to fix in editor, unless it turns out to be problem with pooling and chows too much resources, but I hope that isnt the case.

Thanks again for all the help save and congrats on the C# version will wait untill you have all the bugs smoothed out with it before I upgrade. Right now our proeject just needs a reasonably stable particle solution before we start thinking about upgrading, looking forward to future updates though keep up the amazing work.

 

That is good news! I'll visit this tho to perhaps fix the editor issue you've seen, as clean experience as possible. It should be safe to run 1.18, but to be on the extra safe side I think you're doing the right thing as your setup seems to be quite advanced. Many thanks!

 

No need a 'soft hijacking' here. We're aware about your tool.

 

Hi,
Is it possible to emit particles based on an animated alpha mask in a shader? So that the particles emit from non transparent areas in a material, but that the alpha map is procedurally genertated in the shader itself, and is not a static transparency map? If so, which source mode would be most appropriate for this?
Thank you!

 

Hi Jiraiya!
It's a very interesting concept. I'm not fully read up on the subject but here's my two cents.
One approach I can find would be to read the screen pixels through the UNITY_MATRIX_MVP in the shader.
Please see http://answers.unity3d.com/questions/448711/getting-a-pixels-screen-space-coordinate-in-a-frag.html and http://answers.unity3d.com/questions/39803/how-to-get-an-objects-position-in-screen-space-in.html.

Another way would be to raycast if you can read the output as a normal texture. This would be much similar to how the Projection works in PP, where you'd extract the texture's pixels from the returning hit using the textureCoord. I can add this as an option in a future update to the Playground's projection abilities, I think that would be a highly valuable addition!
Please see this answer: http://answers.unity3d.com/questions/372047/find-world-position-of-a-texture2d.html

Then the only mode Playground could run this from is in its Script mode where you'd emit based upon the returned value:

Code (csharp):

1.  
2. playgroundParticles.Emit(extractedCoordinate, velocity, color, parent);
3.  

Where you'd have your own method to iterate through all the returned values. Hope it helps somehow, would be interesting to hear others point of view in this!

 

Update 1.19 is available, fixing the minor issues in the C# version. Thanks for having patience guys!

 

C# is a nice addon. Hope this move will increase your solds.

 

Hah well thanks I appreciate it! There's no notable change yet, but that actually feels really good at the moment. I'm working on some changes to increase performance, movra sent me some general tips which has proven today to run much better. Gotta try to make it pretty before we jump on to the next step, great challenges on the horizon!

 

Hi again save,
Thanks for updating the plugin, having the C# version of it is a real nice to have, so I decided to update it (changing all PlaygroundParticles to PlaygroundParticlesC was a bit painful but yeah, now it's working).
But I'm still having issues when I enable particles, there is some "visual artifacts" one or two frames for one of my particle system.
A pic is better than a thousand words:



It's supposed to create particles like the yellow box (cubes at edges) but when I decide to enable particle only the first time this big cube appears (at least one frame), which is really annoying.
I tried to Clear and Rebuild pool at run time, doesn't change anything.
The particle system is set to WorldObject (simple cube mesh), with an attractor (set at run time too, because it's the character).

And another issue is with my other playground particles on this game. I have particles attached to the player (skinned mesh source), and when I enable it, for like 2 sec all particles are blinking before showing properly. Sometimes they are invisible while this delay.
Do you have any clues/tips about what's going on here?

We need to make a demo before next Tuesday, it will be cool to have theses issues fixed

Thanks again for the support (past and future).

 

Woho pics! Looks interesting, hope to see the demo later!
Ah yes, I believe this is the very same issue that XMachinaX had. This might be an Editor issue only, but I'm not sure yet. Still it should always behave the same in build and in Editor so this have to be fixed.
I'm looking at this right now but it will be a couple of days before this gets sent to the store, with easter holidays in mind I'm not sure if that update will make it in time to next week. But to not leave you empty handed, here's a quick workaround I've found:

In PlaygroundParticlesC add this line of code as the last thing that happens in OnEnable (around line 2560):

Code (csharp):

1.  
2. public void OnEnable () {
3.     // ... all OnEnable stuff above ...
4.  
5.     this.shurikenParticleSystem.startSize = 0f;
6.     SetParticleTimeNow(this);
7. }
8.  

Hope this helps, otherwise you're always welcome to send your project to support@polyfied.com and I'll try to assist as soon as I can!

Edit: I figured as you're going into the Playground script, it'll be easier to address the first frame flash through script. Then you won't have to edit your prefabs through Shuriken which could have been really cumbersome if you have many of them.

 

Awesome support, as always !
About the demo, yeah for sure you'll know more about this game, when we'll finished it (the demo, not the final game )!
I'm gonna try this fix right now, thanks again save.

Edit: I tried to build the game, and behavior was the same, I'm afraid.

 

Ah great! I'm looking to cross-promote games and assets so fire them at will (at me).
Did you add the two lines into OnEnable? I'll send you a PM, the behavior is gone on my machines from todays work.

 

Alright, If I let the particles enabled all the time (I was disabling them for performance reasons), the big white cube has disappeared.
I tried your fix on the Enable function, was changing nothing, I tried to build again with this fix, same issue.

I can live with the fact that particles are always enabled, but I have this strange blinking when I turn on Emitting (using emit = true or Emit(true)). It blinks for like a second before showing properly.

I can record you a video if you don't get it, but basically it's just a very fast blink (I suppose it's one frame visible one frame not) while 1 second and then after the particle system is doing well.

One workaround maybe is to change the particles count while always emitting (from 0 to max), it's not elegant, but yeah, if it works...

 

Oh, that's interesting !

 

That's ok you don't have to give it more time, I'm on to the chain of reaction that caused this behavior and upcoming release will have this fixed.
It's really troubling that you guys have had this issue for some time and I haven't seen it in the latest tests on my machines. After todays work it's a different scenario tho, Editor and builds show the same promising results! Again, improvements coming...

 

Hello,

Was wondering, does assigning a mesh to a mesh based emitter at run-time will have any impact on performance?

Thanks

 

Hi Rosevelt!
It can have a noticeable impact if you have this running on a device where the action need to free up memory, and where the mesh itself have many vertices. What happens when you assign a new World Object (the name is to minimize confusion of a State mesh which functions differently) is that two built-in arrays are filled with the mesh vertices and normals, which then iterates through upon every calculation loop. Good to know is that if the mesh is marked as procedural (better control and optimizations of that in upcoming 1.20 update) or if this is a skinned mesh, new array data will be created every loop - which also generates a bit of garbage to collect at some point.

If you experience a slight lag when changing World Object, which would be a common thing on low-end devices, you could cache them before the game itself starts.

Here's a basic example of caching World Objects in C#:

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4. using System.Collections.Generic;
5.  
6. public class SwitchCachedWorldObjectsC : MonoBehaviour {
7.  
8.     public Transform[] worldObjects;                        // The objects in scene you wish to create World Objects from
9.     public PlaygroundParticlesC particles;                  // The Particle Playground system that will change World Object
10.     List<WorldObject> cachedWorldObjects;                   // List of cached World Objects
11.    
12.     void Start () {
13.        
14.         // Cache the World Objects
15.         cachedWorldObjects = new List<WorldObject>();
16.         foreach (Transform wo in worldObjects)
17.             cachedWorldObjects.Add(PlaygroundC.WorldObject(particles, wo));
18.        
19.         // Assign a World Object by list number (example)
20.         SwitchWorldObject(0);
21.     }
22.    
23.     // Call SwitchWorldObject (int) to assign a new World Object to your particles
24.     void SwitchWorldObject (int switchTo) {
25.         particles.worldObject = cachedWorldObjects[switchTo];
26.     }
27. }
28.  

and in JavaScript:

Code (csharp):

1.  
2. #pragma strict
3. import System.Collections.Generic;
4.  
5. var worldObjects : Transform[];                             // The objects in scene you wish to create World Objects from
6. var particles : PlaygroundParticles;                        // The Particle Playground system that will change World Object
7. private var cachedWorldObjects : List.<WorldObject>;        // List of cached World Objects
8.  
9. function Start () {
10.    
11.     // Cache the World Objects
12.     cachedWorldObjects = new List.<WorldObject>();
13.     for (var wo : Transform in worldObjects)
14.         cachedWorldObjects.Add(Playground.WorldObject(particles, wo));
15.        
16.     // Assign a World Object by list number (example)
17.     SwitchWorldObject(0);
18. }
19.  
20. // Call SwitchWorldObject (int) to assign a new World Object to your particles
21. function SwitchWorldObject (switchTo : int) {
22.     particles.worldObject = cachedWorldObjects[switchTo];
23. }
24.  

 

Just a reminder - If you are a PlayMaker user, remember to show your interest and up-vote the Playground for Action support here https://trello.com/c/j3bQRpCJ/63-particle-playground. Based on feedback I know there are plenty who would like to see this soon.

 

Update 1.20 is out, and this time with a limited reduced price.



The update is mainly addressing some important optimizations regarding generated garbage, procedural support and fixes regarding initiation and time catchup flickering, so make sure to get this one.

A new preset called "Flowerbed" is also added, showing how to get different textures on particles using a texture sheet (this is done through the Shuriken component). What you could try is to change the source mode to projection, set a readable projection texture and project them onto the ground for instance. It's an easy way to set scattered details onto objects, which can move/emit.

I'm currently working on some new manipulator abilities, more performance improvements and trying to layout a good event system. More about that a bit later!

 

Hi,
Got the latest version, and I keep getting these errors after importing to the project:
Assets/Particle Playground/Scripts/Csharp/Editor/PlaygroundInspectorC.cs(112,164): error CS0117: `PivotRotation' does not contain a definition for `Global'

Assets/Particle Playground/Scripts/Csharp/Editor/PlaygroundInspectorC.cs(112,78): error CS1502: The best overloaded method match for `UnityEditor.Handles.PositionHandle(UnityEngine.Vector3, UnityEngine.Quaternion)' has some invalid arguments

Assets/Particle Playground/Scripts/Csharp/Editor/PlaygroundInspectorC.cs(112,78): error CS1503: Argument `#2' cannot convert `object' expression to type `UnityEngine.Quaternion'

Deleting all the c sharp references seems to allow it to compile just the javascript version fine, but Id rather use the c sharp version.
Any help would be appreciated.
Thank you!

 

Hi Jiraiya!
I had a similar support errand a couple of days ago, turned out it was due to another asset in the project which was colliding with any scripts trying to address some namespaces in the UnityEditor class. I can assure you that it does contain a definition for Global for instance. In that case it was the name Tools, where the user renamed the class in the other asset and Playground kicked off. Could this be the case for you as well?

 

That reminds me... save, how about adding namespaces to Playground itself? It's not unthinkable someone has a Playground class in his game as well.

 

Fortunately yes but unfortunately not before sending 1.20 on its way, will be in next update. Thanks for looking out for my C#, making it sharper (hah). Much of your feedback in this one.

 

Of course as a Playground customer and user I have a vested interest in the quality of the code

 

Exactly the way it should be. If I didn't get all this constructive feedback the framework wouldn't improve much, so thanks a bunch!

 

I've been flirting with this plugin since it's release and i finally got it today on discount. Haven't tried anything yet but considering the examples alone this will come handy in the project i'm starting now.

I have one question though, is it possible to create a turbulence effect? (sorry if this was answered before)

 

Thanks kebrus for the interest!
Sorry there's no turbulence implemented, and I don't mind repeated questions, the higher repetition the higher demand. The closest to turbulence is Forces > Velocity Bending, which can create some movement stir. Turbulence is something I'm looking into adding onto manipulators, and I think that will happen rather soon as I'm extending them a lot at the moment.
I'll let you know more on the details when it's closer to release.

 

Thanks for answering,

By the way I'm curious why are you duplicating the mesh vertex array instead of iterating on the original,
Is there any manipulation you're doing afterward?

I'm currently using the legacy PS for changing mesh at runtime which works pretty well within a pooling mechanism.
My game is PC only, just wanted to be sure I'll get the same performance with you system

Thanks

 

Speaking out of a version 1.20+ perspective (make sure to update), the caching of the mesh array is done to not extract duplicates upon each calculation loop. Every time a mesh vertices is called for a duplicate of the mesh is returned, which by itself causes some garbage to collect at some point. This would be severely extreme for each particle to extract inside the for-loop, therefore a cached version is needed every single Update, even if it's a procedural mesh. Instead it uses the cached version to calculate each vertex seen by the transform point. The short and simple answer would be that it's a really good place to gain a lot of performance in caching.

 

Hi,

Just got a little chance to check the demo scenes.
Image State on my computer(i7 GF670) runs at 45 FPS with an avg of 22 ms on Main Thread.

The Features demo scene when pushed to about 10K particles also drops to 45 FPS.

Any idea what might slowing it down so much?

 

Hi!
Thanks for bringing in some data! This is one of the things I'm currently working on. I've seen some weird behaviors lately inside the calculation loop, and I'm quite sure the issues stem from addressing TransformPoints and also how color is set. These are places where caching also has to get a lot better! It's not acceptable as is and this has to be fixed ASAP - especially before we move on to other performance parts. 1.21 will be another bump up, sorry for not delivering the best in performance yet, it will get better really soon.

 

I'm not sure how you perform your calculations but I guess you're doing it on a single thread.
Loom as a great demo scene where you can see a good usage of multiple threading in a particles situation.
probably you already aware of it but Vector3 is not bound to main thread.

I believe you should aim to sub 1-2ms of main thread time per frame otherwise it'll not be practice using in a real world game scenario where 10K particles is easily being rendered in many gameplay situations.

Do you have a time frame for this fix? as of as it is now its not usable for my game at all.

Thanks

 

That's correct, multithreading is on the roadmap and set to next up right after some sweeping and restructuring. There are many angles to this tool, being able to run great quantity of particles is an important goal but not yet reached in a good way. Current behavior could be described as a bug but it's really some serious brain damaged coding.

Edit:
Please see http://forum.unity3d.com/threads/215154-Particle-Playground?p=1608994&viewfull=1#post1608994

 

Definitely check out Loom Multithreading. He has a demo particle scene that solves exactly this problem.

 

+1 for Loom and BTW, nice new Avatar(s)

 

If he was to use Loom directly, that would mean Particle Playground would require Loom (users buying it), right? You guys were probably just saying to look at how it works though?

What about Thread Ninja instead, which is free?
https://www.assetstore.unity3d.com/#/content/15717

Has anyone compared the two?

Thanks!
Jacob

 

Loom is nice, but, you're right. Better use a free package and Thread Ninja seem good.

 

Thanks guys! Sorry about releasing non fully profiled code lately, first framework and still learning to swim I guess. I think I really need longer production cycles to keep this at certain quality. I'm on it though, and been for some time.

Regarding implementing 3rd-party, I'm getting really great info from you guys so that's super. I've been on a couple of RND rounds on the multithreading issue and found that Mike Talbot's UnityGems implementation is completely free to snitch and continue upon. He's one amazing guy to start with, I've already learned so much from his examples. A couple of things concerns me using an existing Asset Store solution. This would most likely be setup as a business to business deal, which require a good legal foundation and dividing shares/earnings which is far from where I'm at and want to be right now in my own company with this tool. Having forced download of 3rd party in the package would make the end-user have to take action after installing PP, I'd love to keep offering an instant ready solution. We can never know if a solution remains free either, which would be unfortunate if it changes. Based on this I'd like to keep rolling my own solutions and be the only responsible for what happens with the framework at this point. I'd love to expand further down the road when every bit is more stable, then it will be another situation. Hope it makes sense!