-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hinge Goal affected by triangle size #8
Comments
Hi Tomohiro! Great to hear from you and thanks for the pointers. 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. 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. |
Here's a GH definition for testing changes to the hinge goal |
Another bending energy I've been looking at as an alternative is the one described in section 5 of |
Thanks a lot! I will modify this and use for our current project! |
I took a short look at Bobenko 2005. This uses potential bending energy of This form is the same as my model, except that I used L as the harmonic mean or just the mean of triangular heights, while Bobenko uses the distance between centers of circumcenters of triangles. Although Bobenko's method seem to have rigorous interpretation in the viewpoint of discrete differential geometry, the use of circumcenter might be problematic for ill-shaped triangles. |
COM model for hinge objective.zip |
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.
The text was updated successfully, but these errors were encountered: