The lower physics joint doesn't follow the IK lower leg angle

the prediction goes all over the place

The first controller which should receive the winner params and get the same score as it achieved last time, does not behave in the same way.

wtf

Do I get a perf. increase or a decrease?

Deterministic run in debug but not in release when a changing VF is calculated from a non-changing input.

see branch alternative_foot_joint 4dd008e

Gravity compensation is only calculated for the Jacobian of the foot. The resulting torque is applied for all links.
What I interpreted wrong here is that I apply this torque additively to the links, when I should had calculated new Jt for each link and applied the torque to all its parent links.

When letting the variable "quadruped"( in App.cpp, which tells whether or not to create a quadruped) depend on another variable, the biped simulation wouldn't work. This was independent of the value of quadruped.
As long as there was a branch where it could be set to true, the biped would fail, even if the branch path wasn't taken.

Think I fixed it for now. But I don't know what the actual error was.
The error seem to occur on line 339 to 344:
if (quadruped)
{
lLegHeight = scale_0.4f;
footHeight = scale_0.05f;
footLen = scale*0.2f;
}
lLegHeight was being written to (it seemed) even if "quadruped" was false. I can not explain it other that that the error must've been somewhere else and will show up again when I least expect it... :(

This is probably an error caused by something like wrong operator usage(like == instead of = or + instead of += for instance). But I cannot find anything using static code analysis.

The model seems to weak to even lift its feet. It is allowed to fall unoptimized, but there should at least be some form of strength in the legs at start.

Discovered that there is a large difference in the VF forces being applied in unity and C++. The ones in C++ seems to grow infinitely large (downwards), the ones in Unity seem to more correctly match the error in orientation needed to be adressed. Can this be due to the currently larger PD gain in the LF in c++? Either way, the direction (down) still seem off in that case.

I've also made the feet huger and uniform, in order to make the model overall stabler, while I try to find the source of the absolute non-stiffness in the legs.

Creating a heavier LF results in stronger corrective movement in the legs. Probably as it then forms a firmer base for applying the GC VFs.

The feet explicit collision check writes it result to the wrong place in memory it seems

Related to #12

I never fixed this!
In controllersystem in isincontrolledstance:
bool isTouchingGround = false;
//isFootStrike(p_lf,p_legIdx);

The collision check is still commented out!
Reenable this and try to find the bug as to why not all characters receive the correct collision data.

It should only seed on program start. especially the fixed seed

Possibly, the calculations(either in bullet or in the locomotion sim, or both) are too reliant on floating point precision to work with a certain parameter set outside the area in which it was generated (which is in the world center at the moment) or there is another bug somewhere in the locomotion sim which causes this.
Quick fix to allow for visualizations has been implemented as a render offset (m_positionOffset in the transform component), which is only used by the renderer.

It seems like it wants the character to have velocity 0.

Somewhere torques of NaN vectors can be generated. Find where and fix! This might be a probable cause for the NaN values appearing in the bullet physics issue #5.

The resulting foot pos is wrong for the first iterations of the IK.
The starting hip pos is also a tiny bit off. Not as much as the feet though. And the hip pos does not get better after time, which the feet does.