Unroll Necessary
The physical representation is a parallel universe which exists for the game objects in our game engine. This representation sometimes resembles the graphical representation universe and is sometimes quite different, depending on the specific game objects. The PhysX engine now owned by Nvidia is what we use to model this physical world and simulate the behaviors of its elements, the physical objects.
The way we use physics is mostly for collision detections, rigid body dynamics, character controller and cloth simulation. Ragdolls have been in the wish-list for quite a while and we’d have to see if they can be included in the time available, pre-production testing was ok but real production testing hasn’t been followed yet.
There are two main types of physical objects. The ones which are simulated and update their graphical representations based on their coordinates and those which get updated from the graphical representations. An example of the first group is a falling box, its simulated physical representation would be updated and based on its position in the world, a graphical representation for it would be rendered every frame to indicate where it should be in space at that time. An example for the second group would be a physical representation for the weapon of a character which would be used for collision detections. The location of this object would be specified from the location of a character bone moving by its prebuilt animation, an example where a physical object would be updated from a graphical object.
Seems quite straight forward but here is where the fun begins. In the main game loop, input is processed first, followed by the game object logics which include animations updates, followed by the physics update and finally the render. Everything works great in this case for the second group mentioned above since the graphics gets updated, ex. Animation bones, and then in the physics update, the physical representations are adjusted at the correct positions. However for a box falling down, the updated positions for the frame would be updated in the physics update invocation which happens after the game object updates, meaning it would not be possible for the graphical representation to adjust itself with physics and graphics would fall one frame behind. This problem can be negligible in most cases since when all graphics is one frame behind, it would be hard to really realized this and find out the one frame (about 0.03 secs or less) difference between physics and graphics.
The above “escape strategy” would last only until you try to increase the levels of interactions in the scene. Like trying to lift a character on a platform. A platform which is animated. Lets trace the main loop. Game objects get updated, the platform is animated so the new position for this platform is specified, a physical representation is attached to this platform so in the same update process, the physics will be set at the correct position to follow the animation, the actual position in the physics world will not be updated until the next physics update which is due very shortly. Physics update executes, the new position for the platform is calculated, the character controllers are now processed to find the new positions for the dynamic characters, since our character is on this platform, the position of its character controller will resolve to somewhere on top of this platform, and the physics update ends, rendering starts. A platform will be rendered in the correct location but our character, which happens to have a correct position for its character controller, is really one frame behind since it gets synchronized with the physical representation during the main Game Object update loop which happened before the physics update. This would cause our character to go inside the rising platform and be one frame behind in the graphics world. This problem can be modeled by functions and we can say that in the above scenario a physical object is the function of a graphical object and another graphical object is the function of a physical object. physic = f(graphics) and graphics = g(physics) Now we are trying to solve these equations at the same time in one iteration, leading to problems.
A work around to this issue can be to have a post physics update loop after the physics simulation to re-adjust the objects which got affected by the changes in physical objects. This could be the last step in the main game loop right before rendering. This way it would be possible for our character to look synchronized with everything else.
Again the above would only be valid if the main character does not contain any physical objects attached to it. If there are physical objects attached to the main player, such as weapons or ragdoll capsules, the re-adjusting the characters graphics location after the physics update can find out the new positions for these physical objects and set the position but this position will not be really applied to the physical world until the next physics simulation update, which will be in the next frame, having another physics simulation update in the existing frame will complicate things and cause a few unwanted issues and cause the same loop to go on forever.
One solution to this final problem configuration would be to be able to divide the physics simulation update loop into one where the actual dynamic objects get simulated and another which can specify the exact kinematic object positions, the second loop would not need any notions of time and time-steps. This is of course something we cannot do since we do not own the source code for PhysX and we’d have to continue and deal with it as a black box for the time being and look for workarounds.