Particle sync
Moderator: Moderators
Particle sync
I propose nonessential particles such as smoke and nanospray no longer be synced as they're out of place, and it's just a waste of resources keeping a green blob in the same place on every computer despite it being a purely graphical effect.
What if it doesn't have that state, because we haven't been able to see the other guy's stuff yet? Surely that is why, when playing an AI, my CPU load jumps by a huge margin when I can see the AI's base in NanoBlobs- all of a sudden, I can now observe the nanostreams! It's why CPU jumps through the roof, even with the AI base off-screen... it's getting sent to both "clients"... it's gotta be... zomg...
I'm sorry, but I just can't see a single reason why syncing this stuff makes sense. It's just a special effect- it doesn't matter. Particles for weapons, yeah, they should be synced. Particles due to explosions, or due to nanospray, or smoke... naw... why do we care? The worst that would happen, with a laggy connection, is that occasionally you'd see smoke/nano emerging from faulty positions, I'd think. With explosions, we shouldn't ever see that, because the last position of the weapon particle is known by all parties...
Tobi, I'm sure you know the real answer to this... am I just completely off-base here? What kind've load are we talking about?
I'm sorry, but I just can't see a single reason why syncing this stuff makes sense. It's just a special effect- it doesn't matter. Particles for weapons, yeah, they should be synced. Particles due to explosions, or due to nanospray, or smoke... naw... why do we care? The worst that would happen, with a laggy connection, is that occasionally you'd see smoke/nano emerging from faulty positions, I'd think. With explosions, we shouldn't ever see that, because the last position of the weapon particle is known by all parties...
Tobi, I'm sure you know the real answer to this... am I just completely off-base here? What kind've load are we talking about?
Synced means it's deterministic. Only commands are sent over the network if I understand the Wiki right. I do agree that it's nonsense to sync particles that don't interact with the game world, especially since the dev guidelines say that unsynced code is to be used for graphical effects. If particles are unsynced you could add client options to reduce them. E.g. only every fifth nanospray particle is shown or something like that.
Yep, KDR_11k is right.
For load it doesn't matter at all. Synced or unsynced code runs both on the same CPU without any advantage/disadvantage. Also, synced does not mean anything is sent over the network. (Nothing, I repeat nothing particle or projectile related is ever sent over the network)
At the same time, this is already planned for quite some time, as I need it to properly define unsynced particles as being unsynced and synced projectiles as being synced. (For the sync debugger, FYI).
E: to directly answer the OP: it is not a waste of resources at all to keep these things synced. The only difference between keeping them synced or having them unsynced is whether their simulation is deterministic or not (ie. whether they use the unsynced random number generator or the synced random number generator...).
E 2: to clarify a little bit more, there is no chance whatsoever that this causes lag (because of the aforementioned reasons).
E 3: on another note, things like smoke, dirt, wakes, bubbles, etc. aren't synced (don't know about nano particles).
The problem with sync debugger is just that the synced code & unsynced code uses the same class hence I can't mark that class as either being synced or being unsynced.
For load it doesn't matter at all. Synced or unsynced code runs both on the same CPU without any advantage/disadvantage. Also, synced does not mean anything is sent over the network. (Nothing, I repeat nothing particle or projectile related is ever sent over the network)
At the same time, this is already planned for quite some time, as I need it to properly define unsynced particles as being unsynced and synced projectiles as being synced. (For the sync debugger, FYI).
E: to directly answer the OP: it is not a waste of resources at all to keep these things synced. The only difference between keeping them synced or having them unsynced is whether their simulation is deterministic or not (ie. whether they use the unsynced random number generator or the synced random number generator...).
E 2: to clarify a little bit more, there is no chance whatsoever that this causes lag (because of the aforementioned reasons).
E 3: on another note, things like smoke, dirt, wakes, bubbles, etc. aren't synced (don't know about nano particles).
The problem with sync debugger is just that the synced code & unsynced code uses the same class hence I can't mark that class as either being synced or being unsynced.
If spring ever becomes a "serious" game it's good to have a completely level playing field. It's also fun. One part of it is having completely identical stuff to be seen for both players. That means identical particles. What if the enemy comm is just beyond los, but you walk with your comm and see one nano-particle? You know that he's there. But if you had used some other particle model, you would not have seen it. Or if it was random-generated or something. What about your ally, did he see it?
It's been done in quakeworld, where some new fancy teleporter effects added for just for cool graphics actually were a millimeter bigger than the originals and you could see people coming out of teleports where you necessarily didn't see them before. It was a real mind opener, such very unobvious stuff can unlevel the playing field forcing everybody to use the most "tuned" stuff just inside the limits of rules.
Therefore I'm all for very strict deterministic simulation of all particles, that they are in the exact same coordinates for all players. You don't need to submit that much data, since the particles flow deterministically.
It's been done in quakeworld, where some new fancy teleporter effects added for just for cool graphics actually were a millimeter bigger than the originals and you could see people coming out of teleports where you necessarily didn't see them before. It was a real mind opener, such very unobvious stuff can unlevel the playing field forcing everybody to use the most "tuned" stuff just inside the limits of rules.
Therefore I'm all for very strict deterministic simulation of all particles, that they are in the exact same coordinates for all players. You don't need to submit that much data, since the particles flow deterministically.
-
unpossible
- Posts: 871
- Joined: 10 May 2005, 19:24
surely if an effect like nano works in a cone/determined track the track will be the same for both players regardless of sync, once you take into account how many particles there are. the odds of someone seeing a nanobit flying at an extreme angle where there are no other nanobits would be very smallbamb wrote:If spring ever becomes a "serious" game it's good to have a completely level playing field. It's also fun. One part of it is having completely identical stuff to be seen for both players. That means identical particles. What if the enemy comm is just beyond los, but you walk with your comm and see one nano-particle? You know that he's there. But if you had used some other particle model, you would not have seen it. Or if it was random-generated or something. What about your ally, did he see it?
It's been done in quakeworld, where some new fancy teleporter effects added for just for cool graphics actually were a millimeter bigger than the originals and you could see people coming out of teleports where you necessarily didn't see them before. It was a real mind opener, such very unobvious stuff can unlevel the playing field forcing everybody to use the most "tuned" stuff just inside the limits of rules.
Therefore I'm all for very strict deterministic simulation of all particles, that they are in the exact same coordinates for all players. You don't need to submit that much data, since the particles flow deterministically.
Ok, so that was a completely blind alley... it's just the fact that nanoparticles aren't getting culled like other particles, and so are massively over-drawing during full-load situations.
I dunno why I'm even whining about this, honestly. As soon as it's possible, I'm getting rid of nanoparticles entirely.
I dunno why I'm even whining about this, honestly. As soon as it's possible, I'm getting rid of nanoparticles entirely.
I used to run on a different wifi connection that was much weaker, so i had stages where spring would have temporary outages of a second or two. During this units continued to move as if in space and through walls then they'd be synced back into position.
The same was true of nanoparticles and smokenand any other particle, even flames, and they all got put back into palce when the connection came back again.....
Also bamb, what about people who've turned on nanospray effects to max with the max particles vs those who've set them it the minimum setting? Arent the latter thus at a disadvantage.
The same was true of nanoparticles and smokenand any other particle, even flames, and they all got put back into palce when the connection came back again.....
Also bamb, what about people who've turned on nanospray effects to max with the max particles vs those who've set them it the minimum setting? Arent the latter thus at a disadvantage.
It's because the animation interpolator (or whatever you want to call it) starts extrapolating if the current frame takes extraordinary long compared to the previous frame (e.g. if your PC suddenly starts lagging).
Once a MSG_NEWFRAME is received and a new simulation frame is calculated, the animation interpolator is pulled back into it's interpolating domain (hence so everything jumps back).
In short, if you see all these things floating around when you're lagging, that's just a visual effect: the real (synced) simulation still keeps the correct position of the stuff.
Once a MSG_NEWFRAME is received and a new simulation frame is calculated, the animation interpolator is pulled back into it's interpolating domain (hence so everything jumps back).
In short, if you see all these things floating around when you're lagging, that's just a visual effect: the real (synced) simulation still keeps the correct position of the stuff.