![]() ![]() I believe what kind of data that has to be sent is a little bit different depending on how often you send it and what your particle system looks like. ![]() However it would be a waste of bandwidth sending that whole chunk of particle data. 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.
0 Comments
Leave a Reply. |