Skip to content
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

Optimize barycentric coordinate computation #164

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Ameobea
Copy link

@Ameobea Ameobea commented Oct 17, 2023

In my application which traces thousands of geodesic paths, I found that the main bottleneck was solving the system of equations to convert cartesian -> barycentric coordinates.

I found a specialized solution for performing the conversion, and swapping it in produces the same results as the Eigen solver while doing so very much faster.

I totally understand if you're not interested in taking this change since it pulls code from a third party source and might have different behavior in case of weird things like degenerate/invalid triangles, NaNs, etc. but I thought I'd put it up to see if you're interested.

@@ -23,7 +23,6 @@ double displacementLength2(Vector3 displacement, Vector3 triangleLengths);
double displacementLength(Vector3 displacement, Vector3 triangleLengths);

// Convert between cartesian and barycentric coordinates
Vector3 cartesianVectorToBarycentric(const std::array<Vector2, 3>& vertCoords, Vector2 faceVec);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why delete this?

@nmwsharp
Copy link
Owner

Hi! Thanks for opening this.

I'm interested in merging this, the fast method seems quite nice.

I am a liiiiitle wary because the existing colPivQR approach was very extensively numerically tested as part of our intrinsic triangulations work. The explicit version here could be more stable or less stable, but either way I am a bit reluctant to merge it in without repeating those tests (and I don't have time to repeat those tests).

What if instead we could just merge it as an alternative option, for now? As a new cartesianVectorToBarycentric_fast() or something, alongside the old version? That way folks can have it as an option. We could even add a flag to the traceGeodesic() function to use it instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants