I have a gun system where when player A fires a bullet, player B, C, D, etc. render the bullets on their own. On a bullet hitting a humanoid, only player A would request damage calculation on the server.
Server’s initial shot replication and hit validation (excl. hit damage application) currently run in parallel, and there haven’t been issues. Theoretically speaking, it would alleviate some delay for a massive amount of bullets being fired.
In that case:
Would each client be safe while rendering others’ bullets (bullet paths, tracer fx, etc.) in parallel? Would the client themselves be safe while rendering their own bullets in parallel? Will there be desyncs, both in theory and in practice?
Would rendering others’ bullets in parallel be a smart & performant thing to do in general?
Is there a particular reason to “spam actor per each gun/player”? Not sure if it’s on topic with improving client performance in regards to my OP, but still interested to hear about your two cents
The expensive calculations that are caused from shooting a bullet, such as updating the bullets position or checking for collisions / impacts are all serial operations, and as such converting such systems to parallel would have minimal benefits, if not none.
If you were to calculate some large mathematical computation, or a computation in which could be parallelized, perhaps like calculating an arching path that your bullet follows, to simulate drag and gravity, and such calculation was computationally expensive - you could make an argument to make this calculation parallel.
tldr; no not worth the time, prob no real benefits
Thanks.
And so in that case, is it more worthwhile to decrease the number of bullets that are replicated to a client to be rendered?
I.e. if the origin and predicted hit point with the given direction are too far from the player, then just don’t render the bullet? Client will still receive instructions to render a bullet from server (since server really just do a :FireAllClients())
You could drop client requests to render bullets if they are out of view, or too far. This is a relatively common practice. The pitfall of this is due to the nature of how bullets work. They move very fast, and very long distances - relatively quick. So you’d want to make sure that the bullets you’re not rendering, will only be dropped if they are far away, and won’t eventually be visible. The last part is the important bit.
the current practice I have is that if the shot origin and anticipated hit position is going to be out of reach of the local player, then the bullet won’t be rendered. in essence I still need to do a raycast, but compare that in production with perhaps thousands of bullets flying around, this seems a rather better solution of the two.
regarding your original comment on whether client would benefit from parallel rendering, I marked it as a solution since in theory, if the bullet positions are being updated in that way without accounting for complex math (i.e. bullet weight, drag, gravitation), there’s very little need to parallel them.