2-Marker Rigid Body!

[husam]

Hi,
I am currently working on a simple full body motion capture system using the Rigid-Body SDK. I have read the tracking tools documentation and looked at the ARENA software, sadly some things didn't add up, so please bear with me

The Rigid-Body tool documentation (under marker quantity section) states that at least three markers are required to define a rigid body; this is of course a fact because two points can only define a line segment, and no rotations can be defined for a line segment; Well what if a line segment is all I need. Eventually, our rigid bodies that we intend to track are not arbitrary objects flying in the sky, they are bound to the real world objects, to the bones. If we take a close look at the ARENA body motion capture we will notice that leg bones are tracked using not 3-marker rigid bodies but 2-marker line segments. This clever configuration seems to take advantage of the fact that leg bones have very limited rotations along their Axes, so a simple line segment should be enough to determine the direction, the Quaternions must be small enough to be neglected. The problem is, the extremely brief documentation (under Using the Rigid Body API) does not mention the minimum number of markers required to define a rigid body, can I define a rigid body with only two markers and get a line segment? if not, then how come the ARENA can track the 2-marker leg bones? Isn't the ARENA's tracking core based on the Rigid-Body SDK?

If we look at the NatNetSDK's 'natnettypes.h', we will see that the header defines the sDataDescription structure which can describe either a rigid body, or a 'marker set'. Well what exactly is a marker set? Can I define and track a Line Segment using a marker set? if yes, then how can i do it?

[beckdo]

Hey Sam. I like your ambition! If you're trying to solve a skeleton, you'll likely find, and I think you already have, that the rigid body engine in the Rigid Body Tool will not get you there. Arena's skeleton solver is based on the rigid body tracking engine in the Rigid Body Tool, but it adds inter-rigid body constraints that the Rigid Body Tool can't do. You'll likely want to attempt to create your own rigid body solver that can take advantage of the additional constraints afforded by the fact that you're tracking a skeleton.

[neill_solow]

I also dreamed to write additional constraints into the rigid body solver process in the rigid body toolkit. it is to be regretted that there is not any functionality for this.

[husam]

Hey Doug. Thanks for the reply. I think a custom skeleton solver will be necessary after all. However, if one wants to implement such solver, what, in your opinion, is the most convenient set up. Would it be A) Ignore the Rigid Rody SDK and use the marker data from Point Cloud SDK to identify and track the skeleton. B) Use Rigid Body SDK to track three (or more) marker rigid bodies (markers associated with upper body bones in the ARENA's body model), and track line segments using markers not associated with rigid bodies (markers associated with lower body bones in the ARENA's body model), then link the tracked rigid bodies and line segments to form a skeleton. C) Simply add a third marker to each of the line segments to form a rigid body and track every bone with three or more markers using the Rigid Body Tool, then link the resulting bones to form a skeleton.

Thanks for your time.

[beckdo]

In the next couple weeks the Tracking Tools will be available (or you can probably get the latest beta version if you email support). The Tracking Tools (which are available as a free upgrade to Rigid Body Toolkit users) includes an improved rigid body tracking engine. However, it's not designed to track a full skeleton and you will likely need to roll your own. You could certainly leverage the Tracking Tools Trackable Engine to give you a head start on your tracking or you could roll your own completely from the Point Cloud data.

[neill_solow]

As fo me, in the Tracking tools everything solved in realtime and it's a problem. There is no way to accurate solve each frame situation, to make some decision manually, to correct solving process.

[Jim]

The Tracking Tools really are meant as a real time system to deliver tracked object data to other systems in real time. Think of head tracking, object tracking, and some analysis, but not meant to be an offline systems with editing.

For tracking a skeleton, and using less than 3 markers, you really need Arena, or a system that combines the output of the tracked markers with a skeleton system to resolve the positions of the bones. The Tracking tools operate independently of a skeleton structure, so it doesn't have the aid of such a mechanism.

For why it can track with only two markers, is that it reuses other markers to get a total of 3 markers, typically at the joints. In Arena, you can view just the tracked RBs and see what segments are actually being created. And, as you point out, we know the constraints of the skeleton, so we can limit the resolved positions of the RBs to make it more reliable.

Arena is more suited towards editing, and solving out a full skeleton that you can import into other tools like Maya and MotionBuilder.

In the new Tools, there are more constraints that you can add to each individual rigid body.

If you would like to build your own, we are supportive of that, it is why we even offer a base SDK to access the cameras directly, but it is a lot of work, so we try to make the pricing of our software very competitive. I would probably start from a Point Cloud and work out from there, that way we have you coverd for camera calibration and 3D point reconstruction.

I hope this helps explain how we have targeted the two pieces of software.

[husam]

Thanks guys, I'm sure you'll be hearing from me soon asking about something so till then