Discussion and Support for the OptiTrack, SmartNav and TrackIR brands by NaturalPoint

Natnet SDK 2.7 is now available

NatNet, VRPN, TrackD, and Plugins

by NaturalPoint-Dustin » Wed Dec 17, 2014 4:47 pm

NatNet SDK 2.7 is now available

We are pleased to announce a new release of the NatNet SDK. We invite you to try the software and share your feedback with us.


    Features & Enhancments

  • Motive 1.7 Streaming support
  • New timing sample for validating mocap streaming frame timing.
  • New Broadcast Trigger sample illustrating how to use remote record trigger/listen using XML formatted UDP broadcast packets instead of NatNet commands.
  • NatNetML - added SMPTE Timecode and Timecode Subframe members. See WinForms sample for usage.


  • Fix for FrameID periodically displays dropped/duplicate packets during live mode.
  • Fix for PacketClient incorrectly decoding rigid Body IsTracked parameter.
  • Fix for crash in GetDataDescriptions() when streaming a Rigid Body with a single character name.
  • Sample Clint incorrectly reports skeleton marker data
  • Update SampleClient3D to clarify quaterion decomposition, add new visuals.
  • Maximum markers per rigid body changed from 10 to 20 to match new RigidBody tracking capabilities in Motive.
  • Frame timestamp now keyed off hardware frame id. fTimestamp resolution increased from float to double.
Direct Download Link:
Technical Support Engineer
OptiTrack | TrackIR | SmartNav
Posts: 612
Joined: Tue Mar 19, 2013 5:03 pm

by luis.gonzalez » Thu May 28, 2015 3:41 pm

Hello to everyone, I'm new to the forum.

My university recently acquired two OptiTrack systems, with the Motive:Body license, and I'm in charge of starting them up, as well as developing the code needed to get the data available on the client machines (mostly Linux).
Therefore, I'm implementing the NatNet API in Qt, in order to make it available across platforms (Linux and Windows users). The project is open source, I encourage it's use and feedback, and the client can be found here:

While this project is on an early stage, I've found some issues, that I think are bugs, in the PacketClient.cpp file, of the NatNet SDK version 2.7, which I'm using as the NatNet communication protocol source.
The NatNet server app that I'm using is Motive:Body version
I would like to flag these issues in order to help the community.

  1. The first one has to do with obtaining the sending app's NatNet version number, while the PacketClient.cpp does the job with a structure, there are problems regarding the structure's bytes padding that compilers add at their discretion.
    One possible fix, that I propose, is this:
    Code: Select all
    // PacketClient.cpp
    DWORD WINAPI CommandListenThread(void* dummy)
            // handle command
            switch (PacketIn.iMessage)
            case NAT_MODELDEF:
            case NAT_FRAMEOFDATA:
            case NAT_PINGRESPONSE:
    //          // This can be used in conjunction with precompiler directive:
    //          // #pragma pack(push, 1)
    //          for(int i=0; i<4; i++)
    //          {
    //              NatNetVersion[i] = (int)PacketIn.Data.Sender.NatNetVersion[i];
    //              ServerVersion[i] = (int)PacketIn.Data.Sender.Version[i];
    //          }

                // This is the alternative: Directly access the sPacket structure fields
                // The pointer needs to traverse the datagram manually.
                char *ptr = (char*)&PacketIn;
                // message ID
                ptr += 2;
                // payload size
                ptr += 2;
                // sending app's name
                ptr += MAX_NAMELENGTH;
                // sending app's version []
                // sending app's NatNet version []
                for(int i=0; i<4; i++){
                    ServerVersion[i] = (int)*ptr;
                    NatNetVersion[i] = (int)*(ptr+4); ptr++;

    For more information regarding this fix, and the Open Source project, follow this link: ... 2effbaa85e

  2. The other issue is more tricky, because it is only displayed when a skeleton is being streamed. The unpack() function of PacketClient.cpp seems to loose synchrony with the datagram, when decoding the skeleton's rigid bodies info (position, orientation, etc.).
    The source problem seems to be the same, a structure padding that is happening in the NatNet server app (Motive version, because there is an extra 2 bytes padding between each rigid body info.
    One possible fix, that I propose, is this:
    Code: Select all
    // PacketClient.cpp
    void Unpack(char* pData) {
        // skeletons (version 2.1 and later)
            if( ((major == 2)&&(minor>0)) || (major>2)) {
                       // Mean marker error
                       float fError = 0.0f; memcpy(&fError, ptr, 4); ptr += 4;
                       printf("Mean marker error: %3.2f\n", fError);

                       // release resources

                       // Issue #5 Fix : Motive:body is appending 2 bytes of zero data
                       // to the end of each rigid body (belonging to a skeleton) data.
                       // The problem may be caused by structure padding on the
                       // Motive:body software.
                       // NOTE: Please contact NaturalPoint, Inc to solve the issue at the source.
                       ptr += 2;   // Issue #5 Fix.

                     } // next rigid body

                 } // next skeleton

       // labeled markers (version 2.3 and later)
       if( ((major == 2)&&(minor>=3)) || (major>2))

    For more information regarding this fix, and the Open Source project, follow this link: ... fea501ac98

By the way, it would be very useful if you could help me with the NatNet protocol documentation, besides that of the PacketClient.cpp, because I've sought throughout the forum and website, and I haven't found any documentation. I would really appreciate it.

Posts: 3
Joined: Thu May 28, 2015 1:59 pm

Return to OptiTrack Data Streaming