Currently, an additional rotation calculation step is needed to get joint angles after solving for IK. Since the purpose of IK is to find joint parameters that provide a given end effector position, it is my opinion that an IK library should provide a means to get the joint angle. In this case, something like double bone.getXAngleRadians(), bone.getYAngleRadians(), bone.getZAngleRadians() or a single method like double[] bone.getXYZAnglesRadians() would be nice to have.

What are the benefits of Kusudama Constraints? I can't find a paper describing them.

Any possibility to add maven support?

I'm interested in adapting ewbIK for .NET, but some files (e.g. AbstractKusudama.java) are missing the license blurb. How should I handle attribution in those cases?

It's too bad the underlying Java implementation is dependent on classes like pseudoScene.DVector. As far as I can tell, none of this code will work outside of sketchbook. Are you planning to release the source and make it standalone Java?

Hi,

I ported the project to C#/Unity, it seems to run correctly, albeit very slow (around 5-6FPS if solving every frame, on a high-end laptop).

One line I had to comment out is in bold below:

public void removeFromBoneList(AbstractBone abstractBone) {
if(bones.contains(abstractBone)) {
bones.remove(abstractBone);
boneMap.remove(abstractBone);
}
}

Is this line correct? It appears to be attempting to move an element from a HashMap by value not key, which I presume will not do anything? I do very little Java, so I maybe missing something.

Out of interest, what sort of performance would you expect to get when solving every frame (I have been trying ConstraintExample_Kusudama and SimpleExample as my tests). I don't know if performance issues have been introduced in the Java -> C# process, or whether this library is meant more for offline calculations than runtime (using it for things like working out where a human skeleton is based on three pieces of tracking data for head and both hands).

To reproduce, construct a new Bone, then call bone.getPin(). A NPE will result. Then add bone.enablePin() before getPin(), and it returns a DVector. If the pin is not enabled, it should probably just return null and not error out.

I'm trying to scope out what needs to be ported for the C++ game engine Godot Engine.

• Port C#? Java to C++
• Make a visualizer for kusudama constraints

The goal is to have realistic IK tracking given three sensors (head-mounted display, two trackers) and at least 3 - 10 VR tracker sensor positions.

My peers had some concerns about FABRIK's unnaturalness around the bending of the elbows, given only three sensor points.

The plan currently is to have analytic solvers for the IK system, but it doesn't have sound theory behind it.

#5 mentioned some calibration needed for scaling the body. We could use a "T" or "A" pose for doing that. Other systems like VRCHAT or HI FIDELITY used the height of the head-mounted display and the hips to give a possible scale. Scaled avatars like huge persons or small persons are a problem.