Var particleData : PlaygroundCache = particles. The essential data to transfer lives in the PlaygroundCache which you can access in every PlaygroundParticles object: The most efficient way of doing it is though to let each client interpret its own particle system - which doesn't require the server to send data into the PlaygroundParticles objects.

What you probably would want in that case is to have one PlaygroundParticles object server side which calculates all particle positions - then each client side you have a 'zombie' or, a little more advanced a lightweight prediction model, which inherits all/or parts of the particle data from the server. Particle Playground can do what you're asking and to run this into a networked solution I would recommend to run the entire particle simulation server side - if every particle need to appear exactly the same. I'm not sure how this has turned out for you but I thought I'd jump on trying to give some input from my development perspective of Particle Playground. It's also not really suited to large particles, and large particles are what you need if you want to fill volume. A small number of those won't be a big deal, but applying it to all of your particles will just suck. Keep particles that need to collide with the world to a minimum. If you want to obscure a specific part of someone's field of vision or a particular area, whack a billboard on it, then just dress the billboard up with particles. You also don't have to do all of the work with particles. You can also use post-processing effects to your advantage. I'd consider some priority system for the systems on each client, possibly based on how far away a system is and how likely it is occluded by other particles, and how many systems are in a given priority group.

So nearby effects can be done in detail, you use some heuristic to determine how visible distant effects are and change their quality accordingly. Something else to consider is that if particles are being used to obscure vision you don't need to simulate all of them all of the time, because you've got a built in assumption that the nearby particles will obscure the more distant ones. (Of course those 'complex' behaviours are built up of a number of pretty-simple-to-calculate things for the sake of the CPU.) I agree that fill rate will be an issue, and typically this is managed by having a smaller number of larger, more dense particles as opposed to the opposite. One of my current projects involves a particle system with tens of thousands of particles with complex behaviours. 'Hundreds of calculations' isn't an issue. Battlefield 3 and 4 (and possibly Bad Company 2) definitely use smoke, fiog, haze and other visual effects for this kind of gameplay mechanic. Plenty of games do similar things to this on a more local scale. Any in-house tricks that might apply here?.Are there any third-party assets that will help?.How can I achieve that result as a networkable and efficient solution.Drawcalls aren't so much the issue as the hundreds of calculations your CPU will be making. The must be wind effected, sparks must collide and so on. We need to simulate multiple 'dynamic' particle sources in quick succession. Perhaps a little specific but you get the point. He charges through a loose section of wall and hoses the surrounding clutter but due to dust both on bullet collision with surfaces and blowback from his weapon he is unable to see anything and shot. He can't take the entrance as they are covered, he has no tools or other weapons at his disposal save surprise. For example our player is attempting to clear a warehouse of a hostile. We want to use visually obstructive particles as a mechanic to be used/abused by the player. As a solution to the issue of shifting particles from the 'Atmospheric Effect' camp to the 'Gameplay Mechanic' camp lets take a look at this one: Achieving up to 100 temporary textured particle emitters in a scene without a significant performance hit.įor the sake of simplicity lets say we're building a shooter.

Unity particle playground unity forum