Is it safe to subclass the Virtual Character Controller?

[Avelina9X]

After wrangling with PhysX for almost a month to get a usable dynamic character controller I've jumped ship to Jolt.

The Jolt VCCT is almost perfect, but has a few things I'd like to change via subclassing, because while the built in VCCT is much better than my PhysX controller (and a billion times better than the slop they supply as a built in CCT) in terms of stability and stepping, some of the contact-based interactions feel unrealistic, such as thrown objects pushing the player around as if the player was weightless. Additionally, downstepping is sometimes unrealistic for large gaps, feeling like a straight-up teleport downwards rather than an actual "down step"; I think this is the only thing which works better in my PhysX CCT compared to the Jolt VCCT, so I'm confident I could adjust the functionality, assuming it is something which is safe to modify.

Are such modifications recommended via subclassing, or would I have to rebuild the VCCT from scratch for API safety?

[Avelina9X]

Oh god it's all private. I'll have to reimplement everything manually.

[jrouwe]

Subclassing was indeed not intended. The intention was that this would go through the listener class CharacterContactListener (and CharacterVsCharacterCollision but that one is not relevant in this case).

such as thrown objects pushing the player around as if the player was weightless

This would be handled by OnContactAdded and OnContactPersisted by modifying CharacterContactSettings::mCanPushCharacter.
Note that CharacterVirtual is a kinematic construct. You move it through velocities and, as all kinematic objects, it has an implicit infinite mass. Only for pushing down on the ground there is special code that gives the character mass and applies a force based on that mass. If you want it to respond to other bodies in a certain way, you need to program that yourself. E.g. if you want to be able to push certain objects slowly then you need to set a lower speed on your character when you detect that you're pushing the object.

Additionally, downstepping is sometimes unrealistic for large gaps, feeling like a straight-up teleport downwards rather than an actual "down step"

If you don't use ExtendedUpdate, you can call functions like Update and StickToFloor yourself and determine how far you want to step down (it's also exposed as ExtendedUpdateSettings::mStickToFloorStepDown). But maybe I don't understand exactly what you mean.

Anyway, if there are specific hooks that you need then maybe I can help out.

[Avelina9X]

So the StickToFloor() method utilises the private GetFirstContactForSweep() and MoveToContact() methods to actually implement the checking and snapping of the player down to the ground. In turn those two methods utilise GetCenterOfMassTransform(), mCharacterVsCharacterCollision, sCorrectFractionForCharacterPadding(), GetContactsAtPosition(), StoreActiveContacts() and UpdateInnerBodyTransform() among other methods and members which are all private (or not exposed to other translation units in the case of sCorrectFractionForCharacterPadding()).

This in no way prevents me from re-implementing the same functionality myself since it's just sweeps and setting the player's position, but this would be much less efficient both in terms of performance and code-reuse compared to using the in-built private helpers.

What I'm trying to achieve is fractional snapping; if the stick to floor (or walk up stair) distance is 50cm I want to spread the act of snapping up to these different levels over multiple frames, with exact snapping distance depending both on horizontal velocity, max step size, and framerate. The problem is we cannot simply reduce the step size used in the Extended Update Settings, because doing so prevents the CCT from actually stepping/snapping. So we need the step size to still be for example 50cm so we can still detect the snap/step, but the distance we snap up or down that frame is a much smaller value. I cannot do this using only the public methods available in the class, because the detection distance and snap distance are the same variable.

The only way I can think to make this "smoother" using only public methods and without writing my own sweep and move to contact methods is to change the player's height dynamically every frame to sort of emulate the fact that the distance between a person's head and feet changes when a human walks up and down stairs; when we step down the player gets taller by the step size and then decreases over the next few frames, and when the we step up we get shorter and then increase over the next few frames, both of these systems effectively letting the player's "head" interpolate from the old Y height to the new Y height over subsequent frames.

[Avelina9X]

Basically, this is what happens:

This is what I want (while still being technically on-ground the entire time, rather than in the air despite actually being in the air):

And this is what I think can only be done using public methods:

[jrouwe]

Have you considered doing smoothing on the game side? For our game, the capsule moves instantly to the new position, but we visually interpolate the character/camera to make any movement over rough terrain look less jittery. We even smooth horizontally to ensure that walking into small rubble doesn't affect smoothness of the camera.

GetFirstContactForSweep for a large part doesn't take the character padding into account (it only accounts for it in the direction of movement), which helps in sliding over small stuff but imo is not a great public API to have. If you were to break up the movement using these functions, then I think you would find that the capsule ends up 'in air' and start falling instead of following the terrain. I'm guessing that this is going to add a lot of complications if you want to fix that.

[Avelina9X]

I originally didn't want to consider such an option because I wanted to have a single source of truth for positions in the physics system and avoid interpolations done outside the physics engine for things which should be server authoritative.

However I forgot that we can in fact use the physics system for interpolations using constraints or drives to pull a real rigid body towards the Virtual Character's position. This keeps the single source of truth because the Virtual Character represents the desired location, while the Rigid Body driven to that location represents the player's actual location.

Thank you for this constructive discussion and your work in general on Jolt!