Particle Playground

That would make a lot of sense, something to look out for in the future. I'm looking into implementing the rather tricky control of the particle system sorting layers as they aren't fully exposed to the editor. It's a really missing piece tho for 2D users so improvements will come for sure as soon as I can give it more time.

That is very interesting, no other changes were made than the if (distance) check, let's see - try this file instead. Here's what I get in 2D,



Another approach of doing this would be to use the "laser"-preset, then activate/inactivate the GameObject (which is a far more simple approach). But I thought you wanted to use this in addition to for instance a linerenderer, having particles around or after your drawn line when it fades out (similar to the Railgun). That's when the scripted approach becomes much more handy as you can draw several particle lines unrelated to each other with the same system as it's running as a pool.

When all else fails you're always welcome to send me your scene to support@polyfied.com and I'll have an extra monocular look at it.

 

@save,
Ok I finally did get it working. Needs some work but is a very good start. Thanks for your help in getting that working for me.

PS - I saw the post earlier talking about accessing particle playground via C#.... Is there any documentation on using particle playground with C#? We only use C# in our game so I would like to stick with it if possible but it seems like it would be hard to use if all the documentation is in JavaScript.

 

Great! Happy to be of help, it's a bit tricky to jump right into a project solution so I figured it would be better from my end with an example to build from. Let me know how that works out, I'm always eager to see what you guys are up to.

The function/variable calls are the same when running from C# -> US, where the documentation covers the (most) functions and variables available. I'm looking into improving the documentation in the future, to make something much more explanatory and easy to use.
I've also understood that a C# version is much more critical on the roadmap than I've previously estimated. So this is something I'll launch right away after 1.17 has hit the store, which hopefully is good news to the many users and speculators out there.

This means that threading gets a secondary place, which only is a good thing in this case. As previously stated, improvements on their way, finally with a priority that makes more sense.

 

Version 1.17 is submitted and waiting for review.
As I usually like to destroy the element of surprise (and I might not be in office when this hits the store) - here's what's waiting for you,

Project particles onto surfaces
Project particle positions from a transform in your scene using a texture. The projected positions can be updated live each frame or manually when needed. Use this to for instance create dust/smoke/fog on top of your landscape, rain splashes, gunshot effects on walls, you name it. Find it in Source > Projection.

Local simulation space
Yes! This was a real handful. All type of source positions, collisions, manipulators and lifetime behaviors can now cope with a particle system living in local simulation space. You will find it in Advanced > Simulation Space.

Manipulators
New manipulators Death, Lifetime Color and Combined has been added. Using a Combined will make you able to add several behaviors onto one manipulator call, using its range, position and strength. Attractor, Gravitational and Repellent is moving in to the properties to be able to combine. Each property now has its own strength as well so you can fine tune properties inside a Combined. All can make use of transitions to blend towards their property.

Mold your own Initial Velocity Shape
Initial Velocity Shaping is introduced where you can determine the shape of your force by Playground's Vector3 Animation Curves. This makes it possible to do spheres, ovals, crosses, shaped in the way you want them. A good addition to you who likes to make explosions.

Customize your own Lifetime Sorting
For you who felt like the existing possibilities weren't accurate enough you can now set your own particle lifetime distribution. This is done by an Animation Curve where you can determine exactly how many particles of existing pool will be spawned at an exact point in the set lifetime.

Live down-resolution skinned meshes
Skinned World Object just got a real boost, now you can choose to distribute particles along the complete mesh and determine how many of those vertices should be used. This will amp performance a lot if your mesh has many vertices and you don't want to create a source position for every vertex.

Scatter source positions
Spread out the source positions randomly by minimum to maximum Vector3 to efface previous vertex/pixel structure.


I think that's it for now, feedback has been awesome guys! Thanks for having patience with my mistake of running everything in US, C# is a high priority, just a little bit more patience and we'll get there. ;-)

 

Nice picture. You're a very talented designer.. and, of course, nice update.

 

Oh you, Thanks ZJP! Practicing on that isometry. I think 1.17 is the most advanced update yet, there's so much crazy stuff happening under the hood now.

 

Hmmm, while testing this asset I bought a while ago (to finish off my day ;-)) I noticed something I can't fully grasp.
The issue was to have particles form the outline of a mesh (like a chest) but when I set the offset property of the chest it is 'reset' when going into play mode or when pressing the 'Refresh' button.
In edit mode:


When clicking the 'Refresh' button or entering play mode:



Is there something I'm missing? Probably there is as they are a bunch of settings in your asset

 

Second image for previous post:

 

Looks a bit suspicious for sure, might be a bug that has crawled in. Until it's fixed it looks like you could as well use a World Object instead of State as Source. I'll work on more visual explanatory stuff for the future to better grasp many of the different settings available, it takes a lot of playing around to learn it today I think.

 

To clarify, what i plan to make is something like this exhaust system: YouTube DiRT 3 Example

And here is my exhaust: My Example

May i ask, when will be Version 1.17 released?

 

Great, that was what I imagined (small bursts from the exhaust), they're a must when making racing games. I'm not sure yet about how you intend to implement it, but it sounds like using Particle Playground for the task is a bit overkill. Have you considered using a quad and a texture? You could have a sprite sheet which you offset randomly for instance.

It looks like your example video is set to private, could you set it to public?

I'm not sure when it will be approved by the Asset Store team (and that it hopefully will be approved), all I know is that they have a lot to do after GDC. I uploaded 1.17 last wednesday so hopefully early this week.

 

Okay thank you very much. I set the video to public.

 

Update available! Here's a little cheat sheet to get to know your manipulators a bit better,



Let me know how it plays for you.

 

Thanks! It looks like it suffers from global calculations, update to 1.17 and try the Advanced > Simulation Space > Local. You might also want to un-tick Forces > Delta Movement (moved into Forces in 1.17). However I believe you could win a bit of performance just using a quad which you at some random accelerations/decelerations show for a couple of milliseconds (just a thought!). PP would be more suitable when it comes to smoke/sparks/explosions, hope it makes sense.

 

Just some awareness meta!

Currently known issues being handled,

• Lifetime Sorting: Burst (or similar when in Custom) and non-loop emission may not always restart on first sorted particle when choosing to emit again.
• Keep Color Alphas when Only Color In Range is disabled in Property Manipulators broke on 1.17 update.
• State offset is wrongly calculated on re-initiation.
• Framework is not written in C#.

Improvements on their way.

 

Cross promotion time!



Burning Skulls - First product on the Asset Store utilizing the Playground framework, by the super-talented artist behind BRAiNBOX.

Get creative people and earn some well deserved pennies!

 

http://kotaku.com/game-made-out-of-nothing-but-light-looks-terrific-1557292242

 

It's a really interesting concept, and without exaggerating too much it would actually be kind of easy to construct right away with PP. I'm seeing one thing which the Playground could need to bump performance and that is source position -> object distance measuring, where the object could be the main camera. Especially if you have large/far structures covering vast areas (buildings, roads). I'm thinking perhaps with ability to both turn off single source points and entire sources. I'll have a look into that soon, please comment on this if you get any more ideas around this area. Another thing is that it could really use multi-threading, which is near on the roadmap (repeating myself for anyone who missed that previously).

Anyhow, will be interesting to see if more studios find inspiration in this sort of style!

 

Interesting. As simple as the scene was, I just assumed the 2 authors were using PP since the effect is nearly identical to what I've seen in your demos. Not found any developer information about the project yet, but if they're using Unity I'm fairly certain they are using PP.

 

I would be very happy if that was the case! I'm not sure yet either which engine and method they are using, I was fumbling around Google this morning on the matter but couldn't find any info.

 

Same. I'll keep looking and report back if I find anything.

 

Super lod3!


I have a question to the existing users regarding the transition from UnityScript to C#. Please chip in if you have any thoughts around this (user or not).
I've done a couple of tests outside the framework where variable serialization seem to work well and does not get lost in translation, this was one of my greatest concerns. As there are big editor scripts involved I need to rewrite the complete package to not enforce a standard "Plugins" structure, that would just look bad (to me at least) and I'd like to keep everything structured from "Assets/Particle Playground" - it's just not pretty to bloat someones project in any other way.

Keeping support for both languages is something I've previously had in mind but I figure it will be extremely redundant for the forthcoming of the framework, push release dates, and just getting things done intuitively from a dev perspective. Especially with upcoming threading and events logic.

So - all current UnityScript users (who wants to script towards PP) would have to roll this into a Plugins folder and all current C# users can go back to a standardized project structure. How can I make this as painless as possible for existing users - and would it be OK to just change language over night?

I get the feeling there's something I'm overlooking in the matter, and last thing I want is to screw up existing projects out there. Thoughts around this?

 

Hi Save

I'm not sure switching from UnityScript to c# is entirely a good idea. For starters I get the impression you are far more familiar with Javascript than c# so you should use the language you are more familiar with. Also under certain circumstances UnityScript is faster than c# in Unity because it has native access to certain unity calls unlike C# that always has to go through mono. Unityscript is faster at iterating through arrays in Unity for example.

The only reason that a c# version would be useful would be for people that want to edit the code and only know c# or to make it easier for people to call the functions from c#. If you switch it to C# you will be making c# users lives easier but at the same time making unity script users lives harder.

I think a lot of the people are only requesting c# code because they are using Visual Studio as their environment where I think interfacing with javascript is more difficult. If that's the case they can either work around the issue by switching to another environment or wait for the fix that microsoft is currently working on. According to their road map you will soon even be able to build an xbox one application in javascript if you wantted so they must be updating it. They even got a question about what was the best way of making applications for microsoft platforms which would still be cross platform to which they responded unity.

The other thing to bear in mind is that I think Web gl only supports javascript although I'm not sure if unity 5 will convert c# code on the fly for it.

I don't mind which language you use as long as you are doing it for good reasons. If there are some new features that you have planned that need code reflection then go ahead with changing it to c#.

If you are only changing it because a few people asked for it then it might be more sensible to keep it as unity script but provide a dll they could link to more easily in visual studio or perhaps a bridging api or virtual class that can be seen by intellisense. It is more important that you find particle playground easier to update than they do as you will be the one adding new features to it. If you are able to port it to c# fairly easily then you could also provide an optional unity asset package that contained the source code in c# for those that wanted it. If you aren't that familiar with c# though I would have though that was more trouble than it was worth. Your time would be better spent working on threading or opengles 3.1 compute shaders to take advantage of Unity 5.

 

Thanks Ian! This is amazing for me to get such comprehensive feedback. As I'm previously inexperienced in controlling a complete product pipeline it really makes a difference to open a dialogue, already you've mentioned things I've never had time to consider - perfect!

There are a couple of things which makes this lean more towards a rewrite, and even multi language-support the more I try to grasp the issue. Rolling two versions (in the same package) might be more of an obstacle now before I've setup a good pipeline, not really sure yet how to see it.

1) There has been a great number of support errands regarding JS->C#. We are around thousand users (active/inactive) to date and GROWING where I'd say 50-60% of the users giving feedback, mostly over email, is eager to see C# support. This is amazing of course, where I want to lay foundation to where the user trend is pointing, I figure it's the best way for the framework to survive in the long run.

2) I don't want to break another promise, previous roadmap with early support for compute shaders quickly turned into a failure. I'm very happy how the people here has been supportive and overlooked the sudden change. Now it even makes much more sense to grow slowly and make friends with threading instead (where I'd like to revisit this later when I have help in development).

3) I can't ever release a framework based on JavaScript again, it makes sense to really get into C# this time of year. There are plans to roll another framework by the end of the year, which will be something really extra hopefully, and nothing the community has seen yet. ;-) With that in mind there's a good timing in running C#, it's not a big difference in working with the syntaxes.


Please don't get me wrong, I really understand what you're saying and it makes much sense. Based on user request, personal interest and just for the sake of keeping promises, I'd better roll C# support in some way. After taking the weekend to think about this, I think the conclusion is pointing towards supporting both JS and C# within the same package. In that case I'll try to structure it neatly so it's a pleasant environment to switch between the languages, and hope for approvals yet having UnityPackages in the submission (seems to differ a bit on who is approving). It would be nice to have a "JS C# support"-stamp on the package, that would be much more in line with how I like to structure solutions, even if it's the longer road. I'd like to stay away from packaging code into dlls, it makes it much harder to work with from the Source: Script perspective, and of course letting users rewrite to their needs.

All thoughts are welcome! Still haven't decided before I've tried this out from a user perspective, which hopefully is quite soon as rewrite is going well.

 

I would like to chime in with a reminder that since I bought the package, I'm not able to use it because mobile performance is still really bad. With all of the C# and JS support, please don't forget better support for mobile, particularly Iphone 4. This is a good test base because if works on Iphone 4, then it will rock on the rest.

Cheers.

 

The request of having mobile examples is not forgotten rocki. There's not much I can do about performance more than implement threading, it's already greatly optimized as every single bit is cached and runs in built-in arrays. The limitations will always be the same, for instance that you can't simulate high amounts of particles on low-end devices.

It would be interesting to know what your particular user case is, what are you expecting to do? Perhaps I could guide you into a good start.

 

Absolutely and definitely agree. Maybe the only way for you to give us a good and stable product.
BTW, I code in C #, so

 

I think it would be a great start if on the next update there are examples that are specifically made for mobile. This was our original idea and I think it's still the best because for most people who buy the package, having pre-made examples is so much easier to learn and modify to our own use cases. So please make these examples.

 

Hi Save,

I'm on the other side of the fence I'm afraid. When submitting a project to Windows Store Microsoft is declining projects containing unityscript and Boo http://msdn.microsoft.com/en-us/library/dn178465%28v=pandp.30%29.aspx. Because the convertion to C# was on the roadmap convinced me for buying this asset. Nevertheless if you don't seem comfortable in porting it to c# we will have to make a cutoff on a version (fi 1.7) and convert it our self.

 

cygnusprojects microsoft anounced at their build conference that they are making improvements to Windows store. You might want to watch the keynote. For starters they are making a new universal app type that will work across pc , windows phone and xbox one. They also announced javascript support and explicitly mentioned unity and that you will be able to use multiple languages. I don't think they are going to support boo though and I think some dlls might cause issues with their compiler. If you wait though I don't think javascript will be an issue though I guess it depends when you need to release it.

 

No worries, the quality of the product will remain. I think what's crucial is to find the right angle into the dev pipeline and have an intuitive baseline after installation which is easy to work with from distribution and upon updates.

I agree with you, I'll try to get a mobile preset package in the making - it can only be a good thing.

Hi Cygnus!
You will not have to convert it yourself. C# support is coming one way or another and is in the works right now. Ditching C# was never a question for me, and I realize converting from JS to C# and stop support for JS was really an erroneous stream of thought from my end.


Hope I'm not making you guys worried, I just needed some food for thought and figured where best than directly from the users. Everything is pointing towards multi-support, the release dates will be a bit pushed but we should all win in the long run. I'll layout a tidy "install and update"-plan and present to you guys when I'm ready.

 

@Save,
Is it possible to get builds of Particle Playground that work on older versions of Unity? My team and I are constrained to develop with Unity 4.2.2 at the moment, and I realized that Particle Playground requires Unity 4.3 or newer. Any suggestions of what we might be able to do?

 

C# is the quasi standard language for assets. ignoring this can hardly benefit.

i apreciate this. if you do i'll purchase your package. as long as its US only i'll do not. and i mean C# sourcecode not the dll "hack" .

 

Fortunately yes! You can "wash" the Playground a bit. From previous experience you will most likely bump into trouble regarding the Unity Editor's meta files trying to manually downgrade from finder/explorer. Please try this method:

1) Export "Assets/Particle Playground" to a UnityPackage from Unity 4.3.4.
2) Import your UnityPackage into your project in 4.2.2.
3) Search and replace the 4.3 specific code. Basically it's this:
a) Editor scripts uses ToggleLeft, change these to Toggle.
b) Remove the line around 232 regarding RecordObjects in PlaygroundCreatePresetWindow.cs.

If you continue to have trouble regarding meta files, you can try to grab only the specific script files and the "Playground Manager"- and the Particle Playground System prefab when you're making the UnityPackage. Exporting it as a package is always your best bet.
It's not ideal, but it's a good shot in making it play nice with your project hopefully. When updates are available, you will always need to repeat on updating the Playground. Let me know how this works out!

Edit: Now built in C#!

 

I already own Particle Playground but haven't had a chance to use it yet (though I'm excited to try it out). Does it support any kind of turbulence? I'm looking and comparing to Hayate 2.0, who's main thing seems to turbulence (almost looks like a fluid physics simulation).

Thanks!
Jacob

 

Hi Jacob!
Sorry, no turbulence in there! I'm looking into adding this to manipulators in the future, but focus is currently elsewhere inside the framework. I'd suggest to try Hayate out, it seems to be exceptionally good.

 

Today was the first day I saw particles again for some time, finally in C#.
Everything is rewritten by hand, I couldn't trust existing translator solutions on such magnitude (you might also call it being a control freak).


I've been exploring some different setups but it all comes down to the most simple layout. At first I was into having configuration files and UnityPackages within the package, but I think that would have been a bit messy down the road. The necessity of being able to run PP in JS and C# within the same project while also being able to stand alone (crucial for external presets for instance) in all readable scripts, with easy updates for you, turned into this:

• You will launch the Wizard from Window > Particle Playground > Playground Wizard (language).
• Scripts and presets are separated into "JavaScript" and "Csharp" folders. Removing a language from your project would be as easy as removing those few folders within "Assets/Particle Playground".
• All C# classes is ending with "C". For instance to access the wrapper you'd call PlaygroundC.SomeFunction(). Doing the regular namespaces magic just wouldn't cut it for JS.
• JS and C# systems/presets will not be able to convert between, they are living in separate worlds within a project.

There are a couple of things left before this gets packaged but you can expect C# support very soon.

Important!
I'm looking into increasing prices with $10 in this update, good to know for you who are waiting to purchase. The current price just isn't following the complexity of the package. Although I hope that this new pricing still feels like a good bargain in terms of what you get in return.

The work continues throughout the year on improving this along its multi language support, calendar is booked. And a little bird whispered that more assets utilizing Playground is coming to the Asset Store. This is extremely amazing!

Questions/thoughts are always welcome of course!

 

Happy to hear C# will be here very soon! I think you are justified adding $10 bucks, its a very powerful tool.

 

Thanks I'm glad to hear! I had no idea we would be able to take it this far, honestly it is thanks to the active and supportive users. All that is left is repeating the mantra, improvements coming! :-D

 

Hi save,

I upgraded to the latest version of PP as I desperately need the Local Space support in the latest version. Howevere it still seems to be a bit buggy. I cant seem to preview a particle system in the editor when it is in Local Space and has a Local manipulator attached to it. As soon as I close the manipulators tab the particle system previews again, but as soon as I open it again to make changes the particle system disappears again.

Also the rules for the particles spawinging and behaviour seem to be a bit different in Local Space and this coupled with glitch not being able to view my local manipulators on local space particle systems is making it nigh on impossible for me to create our spell projectile effects.

Is there any advice that you can give me when working in Local Space in getting similiar effects as one would get in World Space. Alos any help on the Local Space Local manipulator bug would be extremely appreciated as it is holding us quite a bit back. Thanks in advance for any help and advice.

 

Hi Machina!

The preview when using a manipulator in local space does sound very odd, it's nothing I've seen yet. It might be combined with some specific setting, but I cant seem to reproduce what you're seeing.
Could you send a stripped down version of your project to support@polyfied.com? Or just a preset of the particle system that behaves this way with a small scenario description in what you want to achieve, that would be of great help trying to reproduce this.

Edit:
Are you using a target manipulator by any chance? I just noticed that I've missed global to local calculations on them. Fixed in next update!

 

Grats on the c#! Good work and must make it more attractive to many

 

Thanks lazygunn! I sure hope! Today all presets, brushes, documentation and graphic profile got done. A couple of minor fixes in the code for both languages and some profiling yet to be done, then this bird shall liftoff.

 

Thanks save, will try to get a small project setup by tomorrow and send it through to you.

Apologies Im not quite sure what a target manipulator is, but they are all local manipulators using the particle transform as a source and only effects that particular particle system (all of them either reppellents, attractors or gravitational attractors, some of them with inverse bounds as well). Hope this info helps clarify a bit more on the manipulator types Im using.

Also all of my particles are using World objects as a source (simple meshes).

Also one thing that I noticed is that the Local Space still doesnt want to work properly even though my particles are set to local space and I got the m set up correctly as I want them as soon as the Parent obeject moves (containing all the particle systems and the mesh source for the particular effect) then the particles still seems to move in world space as they make large tails or fly all over the place and dont stay intact inside their confines.

Hope that the info helps, will try and get the test preject to you asap. Also just want to check could it maybe be something to do with my import of the latest version? Are there significant changes in v1.17 that I might need to delete the current PP folder and reimport it completely, or is a simple import and replace good enough? Cause that what I did and Im not too sure if that might have effected the new updates (specifically the local space as I can imagine that being something more than minor).

Thanks again for all the help and advice.

Edit: Anotther weird thing that I noticed is that performance slows down to a cripple when I have the manipulators tab open and there are mulptiple local space particle systems in the scene. Not sure if this is significant in any sense. Hopefully I can reproduce this in a small sproject.

Ive also tested the local space preview bug with global manipulators and it still gives me that same results as soon as the global manipulators tab is open all local space particle systems disappear and as soon as I close the tab they re-appear again.

 

Hmm, I think I found a solution towards the preview as well as the crippling performance bug. As soon as you change the Transform object of the manipulators to an empty reference game object instead of its default of being set to the particle system object then both the preview bug and the slow performance issue fixes themselves which is a big relief.

If Im not mistaken this is probably what you meant by a target manipulator right save? A manipulator whose transform is set to the particle system istelf. Correct me if Im wrong though as I am a bit of a noob, hehe.

I just need to test my current discovery with the actual in game motion now and confirm that it keeps the particles in local space. Thanks again for all the help and hope the info helps.

 

It sounds like you have a quite advanced manipulator setup going on.
I wonder if there are any quick ways around what you're experiencing. One thing I pickup is that attractor manipulators with a bit of strength that is at close transform position of your particle system will most likely make them unable to get any momentum in velocity.
There might also be an issue with using Forces > Delta Velocity in your case, at high speeds and strength you might get particles flying all over the place.
Another issue could be that you have given Forces > Velocity Bending a bit too much power.

It sounds like you use high velocities, when a particle ends up outside of the confined manipulator area you will "loose" that particle. Either experiment with larger manipulators, or try to find alternatives to your current setup. If you're using attractors to set particles towards a specific goal, you might get even better control with Property Manipulator: Target, as they will work together with particle velocities if you have a transition - to finally zero out the original particle velocity. This would be a much more secure way of moving a particle from A to B, if you really want to set a particle at B that is.

I will go through all the manipulators global to local calculations before I update, now that I found one erroneous there could be another bit of code that isn't entirely friends with the local space yet.

Updating to 1.17 was a simple overwrite, so there shouldn't be any conflicts in the versions (all particle code is happening within the Playground- and PlaygroundParticles script, to make the best of when you want to export a preset to a project without the complete framework installed).

I'd gladly take a look at your setup, perhaps I can give some advice, or even better try to improve the areas in what you guys want to achieve.

Thanks Machina!

 

Oh, ok I think I see what's going on. A manipulator will always start with the particle system's transform, you're expected to change this to the GameObject's transform you want to manipulate in your scene. Having a manipulator which alters forces at the exact same position as a particle system might result in the loss of velocity momentum I previously mentioned. But as you use World Objects that particular issue shouldn't apply, it's a different thing if you have a single source point (or very close points). The reason I set the particle system transform per default as a manipulator transform is that you should see immediate result on screen (handles and that particles get affected), and that it's uncertain what other transform you'd actually want.

The target is a type of manipulator property. Have it a go, I think you will find great use for it if you want particles to travel A > B or A > B,C,D (or even A again).

Perfect Machina! I'm happy we were able to find that bug as well before next update rolls out.

Edit:
Also, don't feel like a noob (to quote you) It's my responsibility to give a better foundation in learning the tool. There are many out there asking for vids/tutorials to make the best out of it. Haven't had the time yet to dig into that, but it's really lacking at the moment. Now when there are so many settings, where pre-installed presets only cover a tiny area, we really need some info I think (especially as docs doesn't cover much combination of settings). I'll get into that in a bit, there's been so many areas to evolve up till now so tutorials might have become a bit obsolete quickly.

 

Hi save,

Thansk for the advice. Unfortunately my discovery didnt seem to fix the movement of the particles from outside their bounds (glad that it settles the other errors though).

I will try your advice on samller forces and/or stronger manipulators and check if I can get it to work. This might be the best solutions as I managed to to do this and succesfully prevent the particles from exiting their confines at high speeds with two other effects. There is just one more effect that is still a bit of a problem as it is small and will move very fast so it will be a bit more tricky than the other effects to get to stay in its bounds.

Just to clarify my problem isnt making particles move from one space to another, but rather just to have them stay in their World Objects shape's bounds as well as within the bounds of its manipulators. But your right I think the main culprit is a combination of too strong forces on my particles as well as slightly too weak manipulators. I will adjust them accordingly and inform you if I can get it fixed.

Thanks again for all the help and advice.

 

Alright! Ah, thanks I understand the issue better now. When all else fails you could setup an inverse bounds Death property manipulator, kinda harsh but that would really tell particles that doesn't behave.

There's probably something in here that we could evolve as well. Currently there's a Velocity property manipulator which can apply new velocities in a transition from current velocity, but that will occur without calculating any strength based on position/distance (which the attractors and repellents do). I'm starting to think that maybe all properties could have a strength scaling as well, which would apply differently based on distance.

You're always welcome to send your scene if you get more troubles with it and we'll take it from there of course.