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

Rewrite VMobject subpath getters by calculating split indices #3759

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

chopan050
Copy link
Contributor

Overview: What does this pull request change?

Related PR: #3292

Taking inspiration from ManimGL, I added new methods VMobject.get_subpath_split_indices() and VMobject.get_subpath_split_indices_from_points(), which instead of explicitly obtaining a Python list of subpaths, it obtains an (n_subpaths, 2) ndarray of indices indicating where every subpath starts and ends.

These methods also accept parameters n_dims (which allows us to choose between 2D or 3D point comparison) and strip_null_end_curves (useful in a future PR for VMobject.align_points(), where the null end curves at every subpath must be removed as a fix to certain bug).

Then I rewrote VMobject.get_subpaths_from_points() and VMobject.gen_subpaths_from_points_2d() to use this new method VMobject.get_subpath_split_indices_from_points().

TODO: vectorize VMobject.consider_points_equals() in a subsequent PR for extra optimization in VMobject.get_subpath_split_indices_from_points().

Motivation and Explanation: Why and how do your changes improve the library?

Methods like VMobject.change_anchor_mode() and VMobject.align_points() could benefit from calculating split indices, since they allow for things such as calculating the lengths of the subpaths in a vectorized fashion, which then allows for creating a single NumPy empty array with the right length from the beginning, rather than appending into a NumPy array.

Links to added or changed documentation pages

Further Information and Comments

Reviewer Checklist

  • The PR title is descriptive enough for the changelog, and the PR is labeled correctly
  • If applicable: newly added non-private functions and classes have a docstring including a short summary and a PARAMETERS section
  • If applicable: newly added functions and classes are tested

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🆕 New
Development

Successfully merging this pull request may close these issues.

None yet

1 participant