- It's unclear why a custom cRigidBodySettings constructor is needed. There is no explanation given for why no default constructor exists in the NPTrackingTools.lib, or what purpose providing your own constructor serves. I can only assume it was intended to be used to set app-specific RigidBody property defaults.
- Without a default constructor, the state of an cRigidBodySettings instance is undefined. Which means you must fist initialize the instance via TT_RigidBodySettings. Or, to explicitly set each member of the cRigidBodySettings instance.. but even then you'd still normally need to use TT_RigidBodySettings in order to load the corresponding mName/UserData/etc of the RigidBody you're trying to configure. All of which kinda destroys my original assumption about the purpose of not providing a default constructor in the Motive API.
- The code example for TT_SetRigidBodySettings is especially confusing because the integer rbcount is being declared before the constructor, but used in the code after it. The example code seems to depict a scenario where the for-loop appears directly after the constructor, which is obviously not something that would compile. And calling TT_RigidBodyCount in global scope prior to TT_Initialize probably wouldn't do anything useful either. Is that code a "typo"?
Unless I'm missing something obvious, I would recommend improving the code examples on that part of the API to be more clear about why no default constructor exists, what purpose making your own serves, and where to define it. Ideally it would be nice to have a default constructor included in the NPTrackingTools libs.