Reproducibility in PhysX

As the sampling method involves constructing the open loop control sequence from a collection of segments, it relies on the simulation behaviour in the concatenated segments being consistent with the behaviour in the individual segments. When the segments are being replayed in sequence, the starting conditions for each segment should be as close as possible to the starting conditions when the segment was originally generated, and the simulation should evolve as closely as possible, i.e. the physics engine should be highly deterministic. Otherwise, the starting conditions for subsequent segments will likely diverge further and further from those expected by the individual segments, and the control values will no longer be appropriate, leading to rapid failure of the open loop control.

The issue of simulation determinism is not discussed in Liu’s paper (Liu et al. 2010), and there are several reasons why it may not have been problematic in their im-plementation. They use ODE for simulation, which is open source and the factors affecting determinism are well known. ODE offers two options for time steps, either an expensive but accurate direct solver or a faster iterative method. In the itera-tive method, pseudorandom constraint reordering may be used for stability reasons.

Determinism can be controlled by using the accurate solver, using a constant seed for the pseudorandom number generation, or disabling constraint reordering. Fur-thermore, as the control is expressed in terms of PD targets, it does include an element of feedback. In the original paper, the simulation time step is 0.5ms, and the duration of a typical segment is 0.1s, or 200 simulation steps, which may allow some tolerance of small discrepancies in the segment starting conditions.

On the other hand, the implementation here uses PhysX, which is closed source, preventing inspection of the code to determine the factors affecting determinism, and no existing discussion of determinism could be found. Also, a much larger simulation time step is used here, so that each control segment spans only a few simulation time steps, and the feedback component arising from the PD control would be expected to make the open loop control much less robust to departures from determinism.

Therefore, some experiments were performed to investigate what factors influence

determinism in PhysX, and how reproducible the simulation could be made. There are a number of settings in PhysX which might be expected to have an impact on determinism, including:

Restoration Method There are various methods which can be used to restore the PhysX simulation to a previously recorded state. One approach is to use meth-ods exposed in the API to set the transform, velocity and angular velocity of each physics body to their previously recorded values. The problem with this approach is that some internal state not exposed in the API may not be captured and restored.

An alternative method is to use the binary serialization tools in PhysX, which allow the binary state to be exported to a chunk of memory and later restored, presum-ably allowing more internal details of the simulation to be captured, although the documentation does not detail exactly what is stored.

Articulation Iterations In this implementation, the character is represented using a PhysX articulation object. Articulations use an iterative solver to update their state each time step, with separate user adjustable iteration counts for internal driving such as joint forces, and external forces such as gravity and contact forces.

If there are any non-deterministic aspects to the iterative solver, such as the order in which constraints are solved, then higher iteration counts would be expected to produce more consistent results between runs.

Resetting Collision State PhysX maintains a cache of collision and contact in-formation for each body in the simulation, to speed up calculations on subsequent frames. The cache can be cleared for a body in the simulation by calling the reset-Filtering function, forcing the collision detection for that body to be performed from scratch on the next frame. Clearing the cache may be necessary to avoid invalid information being retained when the state is altered during the process of restor-ing a previous simulation state. Resettrestor-ing the collision information causes the next frame to be more expensive, but this is not really a concern since the sampling based method is already an offline approach.

Contact Offset Each body in PhysX has a contact offset, a small extension of its collision volume designed to avoid jittery contacts when objects are at rest. The default value is 0.02 times the typical length scale, which is defined when creating the PhysX scene to reflect the typical size of objects in the simulation (so 1m would be a standard choice for a scene containing a human character, giving a 2cm contact offset). Smaller values can cause jittering problems for situations which are well known to cause simulation difficulties, such as stacks of many objects which are close to stationary, but would not be expected to be problematic for a single character.

In order to test the effect these factors have on the simulation determinism, the

1E-6 1E-5 1E-4 1E-3 1E-2

1 2 4 8 16

velocity error / ms-1

iteration count

median maximum

Figure 5.3.1: Effect of Articulation Iteration Count on Run Consistency

simulation was set to a particular state, run for one time step, restored and re-run with identical joint control. The state of the hips body in the character was then compared between the original and repeat runs. This procedure was repeated for each frame in a 64 frame reference animation, and the median and maximum deviations between runs were recorded. The results below are for the discrepancy in the linear velocity of the hips body. The transforms and angular velocities were also compared but showed very similar behaviour to the linear velocity.

The effect of articulation iterations was tested for iteration counts between 1 and 16, increasing in powers of 2, with the internal and external iteration counts both set to the same value. The results for one particular configuration of restoration settings are shown in Figure 5.3.1, but all the other configurations showed similar behaviour. The maximum error can be much larger for very small iteration counts, but no improvement is observed above 4 iterations. Therefore, for simplicity the remainder of this section only discusses results for 4 iterations.

The discrepancy between runs is shown for various configurations of restoration settings in Table 5.3.1. Note that the velocities are reported by PhysX as single precision floating point numbers, with around 7 decimal digits of precision, so an observed difference of 0 only means that the relative error was less than approxi-mately 10⁻⁷, not necessarily altogether absent. Evidently using binary serialization and resetting the collision state between runs achieved the best typical deviation between runs, but some frames still showed inconsistent behaviour. However, it was observed that almost all of the frames showed no detectable difference, with the exception of a small number of frames around the time of each new foot contact.

Reducing the value of the contact offset for the character’s feet from the default value of 2cm to 0.5mm reduced the discrepancy to unobservable for all the tested frames. It is not obvious why this effect occurs, although one possible explanation is that the contact offset can affect the order in which contacts are resolved.

Restoration

Table 5.3.1: Effect of Restoration Configuration on Run Consistency

Based on these results, it appears that it is possible to achieve highly reproducible behaviour in PhysX by using the binary serialization method to restore simulation states, clearing contact data between runs, and using a small value for the contact offset of the feet.