Help with GetGroundState During Reconciliation (Client-Server)

[cuppajoeman]

Hi I'm working on a client-server setup using jolt physics, I'm implementing client prediction and server reconciliation, but I have the following problem:

On the client we have a CharacterVirtual the user presses space, and a jump is simulated on the client and so

character->GetGroundState() == JPH::CharacterVirtual::EGroundState::OnGround

is not true.

After a very short amount of time, an authorative state comes in from the server and we first do:

client_physics_character->SetPosition(authoriative_position);
client_physics_character->SetLinearVelocity(authoriative_velocity);

and want to re-apply the input-snapshot that caused the player to jump, but the thing is:

character->GetGroundState() == JPH::CharacterVirtual::EGroundState::OnGround

Still evaluates to false because of our client predicted jump, and so no jump occurs (a jump only occurs if that condition is true).

Since more input snapshots were captured since the first jump input snapshot, then we go on to re-apply the next input snapshot on the authorative server position/vel and the jump does happen on the next input snapshot (space is still pressed) and this is bad because the jump occurs on a different input-snapshot as compared to what happened on the predicted state causing jitter in-game.

During reconciliation we apply any input-snapshots that occurred on the client on top of the authorative state, between each input-snapshot application we do the following:

character->SetLinearVelocity(convert_vec3_from_glm_to_jolt(updated_velocity));

and

character->ExtendedUpdate( ... )

are made in that order.

What I tried

The source code for SetPosition and SetVelocity don't change the state of the character's ground state, and so I tried fixing this by putting:

client_physics_character->SetPosition(authoriative_position);
client_physics_character->SetLinearVelocity(authoriative_velocity);
character->ExtendedUpdate(0.01, ...);

Which seems to fix the ground problem, but introduces the new problem that the authorative position and velocity are simulated a bit before we start the reconciliation which leads to jitter in-game.

Are there any other better ways to simply update the ground state of a character virtual without having to do an update?

I also thought that maybe using RestoreState before setting authorative pos/vel might work but might also incur extra cost/be overkill for what I'm trying to do, but I'm away from the computer now so I can't test that.

I also found that inside SolveConstraints there is this check::

	// Determine ground state
	if (num_supported > 0)
	{
		// We made contact with something that supports us
		mGroundState = EGroundState::OnGround;
	}

So I'm curious to know if doing something a call to RefeshContacts and something like the above might work.

[jrouwe]

I think RefreshContacts should mostly fix this issue as it runs collision detection again and updates the ground state, however it is not 100% the same thing as calling ExtendedUpdate as this can also detect contacts that you touch during the update (but don't end up touching at the end of the step).

Doing SaveState at every time step and rolling back to that state using RestoreState is the official way of doing things, but it does require that the state of all physics bodies is also rolled back (e.g. if a body that you were touching has been removed since the last SaveState call then RestoreState will not be safe).

The simplest thing to do would be to not replicate input, but the results of the input. If the server detected that the player was able to jump then send a 'jump' bit instead of a 'space bar pressed' bit. That way it doesn't matter what the ground state is on the client.

[cuppajoeman]

Thanks for the feedback, the reason we send the input directly and not the results of the input is that is provides one layer of safety against cheaters, if a client could say that they are jumping now, then potentially a hacked client could constantly be jumping to fly around the map, and that would be propagated onto other clients, by only allowing space pressed the server stays authorative on that.

Also I tried the RestoreState method, but I've been having trouble with that, initially I thought that StateRecorderImpl managed the frames of state, but from what I understand this is actually just a single state, is that right? The thing is I need to make sure I have an upper bound on the number of states I'm storing in my game so I don't run out of memory, so I can't just put all the states into a vector. I had made a ring buffer, but whenever I try to return the correct state out of the ring buffer I get an error because the copy constructor for StateRecorderImpl is not defined.

I tried looking at the usage of the state recorder in SamplesApp.cpp but from what I understand things are just added using a vector and occasionally clearing that vector, but that wouldn't work in my case because I always need some look-back into the history.

How can I have something like a ring buffer that works with StateRecorderImpl ?

[jrouwe]

from what I understand this is actually just a single state, is that right?

Technically it could contain more since it is just a binary stream. But the most logical implementation is that each frame has its own StateRecorderImpl.

whenever I try to return the correct state out of the ring buffer I get an error because the copy constructor for StateRecorderImpl is not defined.

StateRecorderImpl only has a move constructor because it can hold quite a lot of data that you don't want to copy by accident. The class is just an implementation of the StateRecorder interface though, so you're free to make a copy of it, strip out all the validation/IsEqual stuff and give it a copy constructor if you need one.

I tried looking at the usage of the state recorder in SamplesApp.cpp but from what I understand things are just added using a vector and occasionally clearing that vector, but that wouldn't work in my case because I always need some look-back into the history.

As it has a move constructor, it allows you to freely erase elements from the vector, e.g. if I change the code to this:

// Record the state prior to the step
if (mPlaybackFrames.size() > 100)
	mPlaybackFrames.erase(mPlaybackFrames.begin());
mPlaybackFrames.push_back(PlayBackFrame());
SaveState(mPlaybackFrames.back().mState);

then it will only record 100 frames instead of everything.