Dan-Piker
commented
3 years ago Hi Tomohiro!
Great to hear from you and thanks for the pointers. This is perfect timing - I was just looking recently at improving this as I'd noticed it is not behaving quite correctly. It currently also doesn't balance angular momentum and some folding simulations have a tendency to start spinning if not anchored.
Move[] in Kangaroo2 is not exactly applied force, but rather for each point affected by that goal, the vectors from the current position to the target position, ideally where the energy becomes zero.
All the Move vectors from the different goals affecting a point are combined in a weighted average, instead of just summed like the forces were in the old solver. This helps avoid overshooting the target, because some goals can be given higher priority than others just by increasing their weighting, without making the movement vector longer, which could cause instability in the old explicit solver. So Move[i]*Weighting[i] should be equal to the Force vector, and if it is it should converge to the same result as the old solver.
Some places where the old force based code used unitized vectors, I found that where goals were simply converted by using the force as the Move vector and keeping the Weighting constant, the goal would converge to the right thing, but in a scale dependent way - so very slowly for large objects and sometimes becoming unstable for small objects. For instance - this was the first attempt at the angle goal: https://github.com/Dan-Piker/K2Goals/blob/master/Angle.cs which I later updated to this, which avoids the unitize step and adjusts the weighting instead, which avoids the problem. https://github.com/Dan-Piker/K2Goals/blob/master/Angle2.cs
tomtachi
Kane-BorgMarkkula
The hinge goal seems make the hinge excessively softer when the triangle is smaller.
This seems to come from two reasons. First, the face normals are not unitized when computing the force Move[]. e.g., Vector3d A = Cross0 D; A = Cross1 D;
Also I believe the following line
double D = AngleError H 0.5;
needs to be inverted and also different for each triangular panel like (although the balance could also depend on the weight of the vertex, the following code assumes Move[] corresponds to the applied force (not force divided by mass)):
double D1 = AngleError / H0 * 0.5;
double D2 = AngleError / H1 * 0.5;
I wanted to test my modification by writing my own C# goal object, but I got caught by some other issue of being unable to update the input variables, so I have not fully yet tested if this fix can fix the thing.