Rigging for Motion Capture via Perception Neuron
I used to play with motion capture when I still was an university student and what I still remember nowadays about this system is that, its accuracy and high costs. It's not affordable for independent content creator or small business. Even for companies of medium size, it still too expensive to get one in one corner of the studio.
Fortunately I got Perception Neuron (and its software, Axis Neuron) a few weeks ago as a gift from my colleagues, and started to play with it.
Because my purpose at the very beginning, is to apply this system in the production of VR/AR game, to replace those animation keyframe works in 3d graphic softwares with motion-capture data, then my first test was quite result-oriented: how to get then combine all joints' data from Perception Neuron to Unity 5?
Based on the suggestions from the official user guide of this motion-capture system, I created a character in Maya with skeleton system which was exactly the same with the one used by Perception Neuron including the naming of joints. This is to ensure all of them could match the one used in mo-cap, and receive the data contained:
(Rigging)
(Hierarchies and Names)
The Mapping of joints in Unity 5 also followed Neuron's official guide and the final result is fine:
Then I realised that, perhaps it still works even when I create a simplified rigging system. Because for Humanoid Rig, Unity 5 will convert all skeletons made by customers to its own mechanism of character no matter what, just through Rig Mapping in character's import settings, and this made all data gathered in various ways could be shared one platform, then get exchanged.
To use an metaphor to describe this concept more clearly, it's just like there is something universally accepted in a market where lots of goods from all over the world need to be exchanged. Or you can just say, the role of Unity's mapping is just like what money plays in global market.
To confirm this idea, I made another rig system that is almost the minimum requirement of Unity 5:
(Rigging)
(Hierarchies and Names)
And the test result in Unity 5 is also satisfying.
For game development, the constraints come from both hardware and software, because a game is still a program on nature, and whether it could run smoothly or not on the target platform, this should be the most important concern of all parties of development. Therefore, the resources the graphic team could get is usually quite limited, or you could say, we couldn't expect too much although nowadays the reality is much prettier than it was 20 years ago because we had more powerful game engines, graphic cards and game consoles which allowed more graphic features to appear on the screen.
So the test above is just to get prepared for both the ideal case and the worst case while developing an interactive program with graphic elements, on what is the most gorgeous plan which the graphic team could apply with, and what may be the practical possibility that we need to face to.