Telling Bullet That Something Happened In The Past

Would you like to see a Partial-Rewind-And-Replay system in bullet?

Yes and I would use it.
3
75%
Yes but I wouldn't use it.
0
No votes
No there is a better approach.
1
25%
 
Total votes: 4

STTrife
Posts: 109
Joined: Tue May 01, 2012 10:42 am

Re: Telling Bullet That Something Happened In The Past

Post by STTrife »

I don't think I understand your post Granyte...

What is the best practice you talk about in the first sentence, and what is 'this' you are referring to in your second sentence?
Granyte
Posts: 77
Joined: Tue Dec 27, 2011 11:51 am

Re: Telling Bullet That Something Happened In The Past

Post by Granyte »

sorry about the formatting the two lines are un related the first one is is just saying that games from EA not using a sensible model does not surprise me
because rubber banding and such issues can only happened if the client and the server can in the first place get into an argument about the positionement of the player




the second is me saying that telling bullet something happened in the past could be usefull for some in game effect instead of for networking
User avatar
KKlouzal
Posts: 44
Joined: Thu Mar 06, 2014 5:56 am
Location: USA - Arizona

Re: Telling Bullet That Something Happened In The Past

Post by KKlouzal »

It could most definitely make for some amazing effects but my primary use would be for networking as suggested here this is the best practice to again save as much bandwidth as possible: http://gafferongames.com/game-physics/n ... d-physics/

I originally started this thread to figure out two things: 1 if it is/would be possible to facilitate such a feature in bullet and if so where would be the best approach to take making such a feature available. My previous posts should give full clarification about the goals of such a feature.

Thank you everyone for your time it is most appreciated.
STTrife
Posts: 109
Joined: Tue May 01, 2012 10:42 am

Re: Telling Bullet That Something Happened In The Past

Post by STTrife »

If I understand the article correctly, it's very specific for FPS games, and the rewind is only used on the client side predition of the player character, and I think it also assumes a static world.
so it's tuned to a specific situation. So I wouldn't recommend for games with more complex physics simulations.

When I learned networked physics (quite some time ago) we had to implement an algorithm that is more general:

-server runs physics engine
-client runs local simulation of movement only (based on rotation, angular velocity and linear velocity, no collisions very simple etc.)
-server runs local simulation of movement only for all clients (this is so simple you can do it for all clients)

Now the server can tell how much the client local simulation deviates from the real simulation, and if a certain threshold is violated (for example more than 5 degrees off rotation or more than 0.1 meters position difference), then the server sends the updated position/rotation/velocities of the object.

You could extend that with client side prediction of the primary charater's movement for example, if your worlds floor is predictable...

I don't know how well this algorithm works in real situations (we just tested it on lan), or if it's too 'simple' and was just intended to teach us, but I thought it was pretty nice. A nice thing is that it only sends updates for objects that are really out of sync.
c6burns
Posts: 149
Joined: Fri May 24, 2013 6:08 am

Re: Telling Bullet That Something Happened In The Past

Post by c6burns »

KKlouzal wrote:... as suggested here this is the best practice to again save as much bandwidth as possible: http://gafferongames.com/game-physics/n ... d-physics/
I don't know if I would go so far as to call rewinding client side physics for networking purposes a best practice. It's an interesting idea, but I've never seen a client/server that did that. There are other ways to solve sync issues and minimize bandwidth which consume less resources on the client and are less complex to implement.
User avatar
KKlouzal
Posts: 44
Joined: Thu Mar 06, 2014 5:56 am
Location: USA - Arizona

Re: Telling Bullet That Something Happened In The Past

Post by KKlouzal »

I'm all ears about other methods but saving bandwidth is the #1 priority, all else comes second.
c6burns
Posts: 149
Joined: Fri May 24, 2013 6:08 am

Re: Telling Bullet That Something Happened In The Past

Post by c6burns »

KKlouzal wrote:I'm all ears about other methods but saving bandwidth is the #1 priority, all else comes second.
*Everything* else is secondary to bandwidth? As in you are willing to incur additional latency to get lower bandwidth? You are willing to do 6 months more work for a 1% decrease in total bandwidth? Each project is going to have their own constraints/priorities based on resources and requirements. I've never been in a position of having lower bandwidth be my *ultimate* goal, always a secondary goal.
STTrife
Posts: 109
Joined: Tue May 01, 2012 10:42 am

Re: Telling Bullet That Something Happened In The Past

Post by STTrife »

I was also wondering why you focus so much on bandwidth. Do you intent to make it work for dialup connections? Where i live everyone has broadband (20 mbit is normal) so bandwitdh is by far not the biggest issue. I guess its more about the whole processing speed of updates, and efficiency and scalability.

C6burn, what kind of networking algoritshms would you recommend for general networked physics?
User avatar
KKlouzal
Posts: 44
Joined: Thu Mar 06, 2014 5:56 am
Location: USA - Arizona

Re: Telling Bullet That Something Happened In The Past

Post by KKlouzal »

Bandwidth is the number one priority but I will admit I'm being quite over zealous in the way I've been stating it.

You are correct latency is also a big factor, the higher the latency the further back in time you would have to go with any specific physics object (using my proposed idea that is) thus exponentially increasing the amount of needed processing, therefore using the least amount of bandwidth possible without added increase to latency would be the number one priority.

My reasoning behind this is to allow the most amount of physics bodies to be simulated in a networked environment as possible.

Again since bullet can be ran multithreaded/gpu the added processing cost seems negligible as well as memory requirements with computers having more and more ram as technology evolves.

In my opinion the time required to complete such a feature is worth it especially if its done properly the benefits seem to very well outweigh the time requirements. Again this is my opinion as I can't see a more efficient way to do it.

I very much welcome your suggestions with open arms! :)

So I suppose more refined requirements would be the least amount of bandwidth usage possible without added latency to support the greatest amount of simulated physics bodies.
Granyte
Posts: 77
Joined: Tue Dec 27, 2011 11:51 am

Re: Telling Bullet That Something Happened In The Past

Post by Granyte »

Multi cores and gpu bullet have some serious draw back atm

bullet gpu does not support double precision nor ghostObject and require a a compatible gpu

as for multicore well I tried this 2 years ago and it still does the same now
https://www.youtube.com/watch?v=svdpP1Z ... Cd6XtKKGAw



So maybe the processing power to simulate will not be that cheap

for my project I hope to get as many player in a map as possible (given that my maps are solar system sized I damn better be able to fit quite a couple of them in there)

but for no I think my main technique will be cutting the update rate for the object the player cannot see or when they are to far away
User avatar
KKlouzal
Posts: 44
Joined: Thu Mar 06, 2014 5:56 am
Location: USA - Arizona

Re: Telling Bullet That Something Happened In The Past

Post by KKlouzal »

@Granyte, of course lowering the update rate for far away objects and removing updates for culled objects are basic optimizations that must be implemented. Those two alone will drastically reduce bandwidth consumption. To take it a step further would be having clients predict the physics interactions, which in turn would allow you to lower the update rate exponentially. You of all people making an MMO should be able to fully grasp the benefits of a system I'm proposing.

The only real question I'm asking in this thread is where should I begin looking to start implementing such a system? Would this require a new solver? Extending a current solver? Creating a new type of rigid body? etc.. If I'm going to take this task head-on I want to get started on the right foot.
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Telling Bullet That Something Happened In The Past

Post by Basroil »

KKlouzal wrote:To take it a step further would be having clients predict the physics interactions, which in turn would allow you to lower the update rate exponentially.
Predicting interactions with programmed events and standard dynamic objects not affected by a second player is easy. The issue is trying to predict player actions that will result in a change in what the predicted physics see. How much would predicting players cost you? 1ms? 100ms? 1 failed update every second?
KKlouzal wrote: The only real question I'm asking in this thread is where should I begin looking to start implementing such a system? Would this require a new solver? Extending a current solver? Creating a new type of rigid body? etc.. If I'm going to take this task head-on I want to get started on the right foot.
If you want to rewind a simple system, you'll want to make a copy of the motion states of all dynamic objects for as many frames back as you expect to rewind. That can be easy enough to do, though performance will suffer from so many memory state copies. You'll also want a copy of all non-physics states for all non-dynamic objects (triggered events, player interactions, etc). You'll then have to decide which states are valid and which must be ignored to keep your players from uninstalling (if you're on a ledge and another player's action that would drop the ledge was scheduled take place after the other player thought he was off that ledge but before it was registered in your system, which event should be the "real" event?). You might want to make a new island dispatcher to improve performance of the system (only update islands affected by a player rather than all), but implementing a solver or body primitive is not an easy task.
User avatar
KKlouzal
Posts: 44
Joined: Thu Mar 06, 2014 5:56 am
Location: USA - Arizona

Re: Telling Bullet That Something Happened In The Past

Post by KKlouzal »

Basroil wrote:Predicting interactions with programmed events and standard dynamic objects not affected by a second player is easy. The issue is trying to predict player actions that will result in a change in what the predicted physics see. How much would predicting players cost you? 1ms? 100ms? 1 failed update every second?
Everything I've discussed here hinges on the fact that the client's input is the only thing being used to calculate the predictions.

Each clients input data would be stored in a vector/list. The amount of inputs stored would be proportional to the individual client's latency + the latency of the client of whom were storing input data on. This allows us to then directly calculate the maximum amount of motion states you would need to store for each rigid body which would be however many motion states would be accumulated during the period of time of the largest value from the previous calculation.

This allows every client to account for the amount of time it takes to receive all the other clients input updates.

My Latency = 30ms
ClientA Latency = 50ms
ClientB latency = 70ms

Input updates sent every 1ms
My client would hold ClientA's 80 most recent inputs
My client would hold ClientB's 100 most recent inputs

Now that this is established My client would hold the most recent motion states that were processed in the previous 100ms

This would finally allow me to go 'back in time' to any given point that could possibly effect the simulation on any one individual rigid body and recalculate the motion state based off of the new input data and interpolate that into the current motion state.

This of course does not account for any other rigid bodies that were affected from this one rigid body being updated.

I figure you could definitely avoid recalculating the entire simulation by doing a couple optimizations.

Using the previous example calculations, if I need to update a rigid body 50ms ago, after calculating the rigid bodies new motion state I could get the amount of distance the rigid body has moved from it's old position to the new position and update any other rigid bodies that fall within this distance, then loop this process over all the rigid bodies that do happen to fall within this distance.


Don't get me wrong, it will be a lot of work. The gain by far outweighs the work involved.
Granyte
Posts: 77
Joined: Tue Dec 27, 2011 11:51 am

Re: Telling Bullet That Something Happened In The Past

Post by Granyte »

i do understand i'll have to test how much i can stretch with just those update but in no case i see where telling bullet something happened in the past could help

because in any case i can just tell the client this happened and now the motion state of those implied is that because i don't get what more can be needed since the player cannot teleport or if they do they should have particle effects in thier faces long enough for everything to go back to place without them seeing it.

i'm also afraid in massive space battle this would mean they client recalculating the simulation nearly every frame to account for the actions of 10000 player/npc
Post Reply