Orientation Encoded as Quaternions

Use quaternions through the DLL, in the Network protocol, and to interface the Refresh/Renderer.

Benefits:
Cleaner design, architecture open for future improvements/added effects.

The current Q2 description of model orientation and view orientation makes implementation of full 6 DoF very difficult, and raises client side prediction issues, too.

Problems:

Feasibility: Corinne Yu of ION Strom claimed to have worked quaternion support into their copy of the licensed Q2 codebase earlier this year.

There will not be a problem interfacing the renderer. >From the original exchange with John Carmack:

The renderer now takes matrix values instead of
angles for more flexibility and less confusion.
I am considering a quaternion representation for the
game and network, but its not at the top of my 
priority list.

Implementation 1 - Minimal:
If quaternions were only introduced in the network protocol, the DLL could be changed later by anybody. Conversion of quaternions to matrix and (if needed) angles could be done in the Q2 client.

  • Add a new data type:
       In: q_shared.h:
    
       tyepdef vec_t    quats_t;     // Maybe fixed?
       typedef quats_t  quat_t[4];
       
  • Change entity_state_t, player_state_t, pmove_state_t and usercmd_t to use a quaternion wherever a triple of short/float is used for angles.
  • Change gi.Pmove appropriately.
  • Rework svc_playerinfo network command:
              short delta_angles[3]
              vec3_t viewangles
              vec3_t kick_angles
              vec3_t gunangles
            
  • Rework svc_packetentities/svc_spawnbaseline network command:
              byte angles[3];
            
    Implications of byte orient[4] in terms of angle resolution, and isotropy/distribution to be resolved. Might require normalization to unit quaternion when converted back to float. This is already a bulk of work. Implementation 2 - Maximal: This is a sketchy and incomplete list, that adds to the minimal requirements listed above. This list can't say anything about server or client internals. It deals with network, MAP/BSP and Game DLL in parts, but not completely.

    This is missing handling of rotational friction, rotation in collision response, angles used in monster AI for movement/targetting, and probably a load of other issues. In summary, the implementation would be a major change, and could scarcely be considered an evolutinary change within the DLL.

    Related Proposals:
    A reworked client side prediction of player POV movements, and/or a reworked client side interpolation/extrapolation of entity updates would be affected by introducing quaternions to the network protocol.
    The alternative of using an OpenGL::glRotate axis/angle representation, which also uses four numbers for three degrees of freedom, has not been proposed formally. It shares most of the problems, while being less generic.
    Some details depend on when the client handles updates transfered by configstring changes.

    Submitted 980321, revised 980328, revised 980420, comments to Bernd Kreimeier.