The DEMoCap Networking uses the Drag[en]gine Network Protocol as protocol and defines a set of messages and linked states supported by DEMoCap. The specification can change with upcoming DEMoCap updates but stays backwards compatible. Servers and clients are required to ignore unknown messages and linked states.

To implement this protocol best use Drag[en]gine Network Library and add the necessary message and state handling.

Various messages use FrameNumber to indicate in what update frame a message has been generated. To avoid delayed old messages interfering with new messages the following pseudo-code has to be used:

int32 Difference = (int32)FrameNumber - (int32)LastReceivedFrameNumber
if Difference == 0 then ignore message // duplicate
if Difference < -32767 then Difference += 65536 // wrap around uint16
if abs(Difference) > WindowSize then ignore message
if Difference < 0 then ignore message
process message

WindowSize is by default 180 unless message define a different value.

These are all messages the server and the client can send to each other.

Upon connecting the client has to send this message to request access to DEMoCap indicating the kinds of features it supports. The connect request message has this format:

The server will then respond with a Connect Accepted message or disconnect the client if rejected.

Send by the server after a client connects which send Connect Request message identifying itself as a DEMoCap client. This is the first message received from the server. The client should not send any messages until it has received this message as this will get him disconnected. The message is send reliable and has this format:

Send by the server if the bone layout used for motion capture changes. Bone layouts do change if a different character configuration has been activated or the character configuration changed. Layout contains the entire bone hierarchy for the active character. Each bone is marked static or dynamic. Dynamic bones are affected by motion transfer rules. Static bones are not affected by motion transfer rules. Send are all bones since static bones can still be animated due to playing back a previous animation or using a base animation. The dynamic flag can be used by clients to know which data is motion capture and which data has other source. The message is send reliable and has this format:

BoneData has this format:

VertexPositionData has this format (all weights are 0):

Send by the server for each motion capture frame. Motion capture data is in bone local space. The root bones are relative to either the actor position relative to the scene or the selected capture object. Capture frames match a specific bone layout revision. The client has to use the latest received bone layout. Capture frames belonging to different bone layouts have to be discarded. This avoids clients trying to read capture frames using the wrong layout. The message is send unreliable and has this format:

BoneState has this format:

VertexPositionSetState has this format:

These are all linked states the client can request.

Send by the server to link the record/playback state. The link message has this format:

The client has to add these values to the state in this specified order: