Right, the behavior of typeid() is compiler specific when you disable RTTI (disabling RTTI isn't part of C++ standard). Regarding your original code, it looks good to me. Thanks for sharing the trick (:
Money. If the game project is interesting for me (jrpg f.e.), then moral satisfaction is enough. All business is based on idea to be the first one against competitors.
I can tell you right now that you wont be able to monetize a single algorithm. You should either: 1) Have your implementation as part of some graphics middleware you license to AAA developers. Anyway, you told you got no access to console devkits, and most AAA developers wont be interested if you got no console port. Not many AAA developers develop for open platforms only and saying that "porting is a breeze" will not cut it, comes across as very unprofessional and shows you got no clue. 2) Indirectly monetize the algorithm by gaining reputation and publishing well written article of your algorithm, for example by trying to get it in GPU Pro or such if it's truly something good. Then use the reputation to advertise your consulting services, use it for negotiating better salary, etc. This would probably be your best bet.
If you set all your joint matrices to identity, you should get the bind pose (i.e. the exported mesh should be in bind pose). That's a way you can check that your vertex shader is mostly working as expected.
It can be a bit tricky to get the joint matrices you send to the vertex shader right though and I'm guessing this is where the actual problem is. For the animation data I'm having joint->parent transformations, so after all the animation blending the final step before sending the joint transformations to vertex shader is to transform these animated joint->parent transformations to bind_space->joint->object_space transformations. The first step is to iterate through all the joints and multiply the animated joint->parent transforms with parent->object transforms to get joint->object transforms (the joints are sorted in parent->child order so parent is always transformed before being used for child transform to get the cumulative transforms). The next step is to iterate the transforms over again and multiply each calculated joint->object transform with its bind pose object->joint transform (i.e. joint inverse bind-pose transform) to get bind_space->joint->object transform, which you send to the vertex shader.
Also a small hint on optimizating the shader: You can first calculate weighted joint matrix and transform the vertex in the end with the matrix, instead of transforming the vertex with each joint and weighting the result. So your shader can be optimized to something like this: