Black Prophecy Technical Director Cyrus Preuss published his second Game Physics diary entry today, and this one focuses on the physics engine that the team utilizes for the upcoming MMO. In case you missed it, you may want to read his first entry before diving into his newest post.

Preuss discusses three individual processing steps that take place within the update fuction of the physics engine: collision detection, collision resolution and physical update. Preuss explains it better than we can, so check out his full entry after the jump.

The 'Physics Engine'

The physics engine offers the possibility to define and create instances of the previously mentioned objects within a "physics world." The "physics world" itself has also to be considered an object. The "update" function is called repeatedly on this object with a certain, fixed delta time. In the course of processing this function call, several different things happen in a specific order.

As a result of each "update" function call, all included rigid bodies can have altered data with regards to position, orientation, linear and rotation velocity. Within the game this data is used to update render geometries in their position and orientation. The game logic can deduce further actions, respectively consequences, due to the data alteration. The repeated call of the "update" function is often called "physics loop".

The individual processing steps within the "update" function are divided into:

• Collision detection
• Collision resolution
• Physical update

I will now briefly elaborate these individual phases and their relevance for the game.

Collision detection

As its name implies, collision detection is about the detection of collisions of individual geometries among each other. During collision detection, a distinction is made between two or more phases. Firstly, the so-called broad phase in which potential collision pairs are identified based on highly simplified geometry. Secondly, the contact calculation or narrow phase in which the exact contact data between individual, previously identified, geometry pairs is calculated. This phase is much more complex than the broad phase. Hereby the kind and complexity of the collision geometry play an essential role.

At the end of this phase, data is available which is not just utilized for the physics simulation but also for the event generation. By analyzing the contact data, collision particle effects or collision sounds can be generated for example.

Collision resolution

Within the scope of collision resolution, respectively its preparation, constraints are generated between the collision pairs, which are resolved completely or partly in the following physics update.

Physical update

During the physical update all constraints are applied. Collision constraints that are not resolved during an update step will be rescheduled. Subsequently, all non-static, thus dynamic objects are iterated.  For dynamic objects all external forces and torques are applied. Now it's possible to calculate new linear, respectively angle-related, velocities.  In the end, the positions as well as the orientation of the individual objects are adjusted based on the new velocities.

That's it for part two of my developer diary. On the first glance, this whole game physics thing might confuse you a bit but if you put all the tiles together one by one you will see what the overall picture looks like and recognize that it is less complex than it appears to be.

In the next part of my developer diary I will talk about interaction with the physics engine to illustrate how the theory is applied in practice.

Stay tuned!