You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nice work, this was quite the undertaking. I don't have a firm grasp on the code yet, but could it be sped up if there is an exisiting triangulation? (i.e. can I get rid of the Delaunay calls if I have by own triObj = Triangulation(x,y) and I normally call plt.tricontourf(triObj,data)). My hope was in cases such as animations of a stack of images of data on a triangulated mesh, this could perhaps significantly speed up the animation.
The text was updated successfully, but these errors were encountered:
Thanks! Yes, I think it's feasible to use a pre-computed triangulation and call tricontourf instead (I didn't even know that function existed!). I'll look at the output from tricontourf: hopefully the paths will work the same. Thanks for the suggestion!
This enhancement seems a bit subtler than I thought. The problem is that the contour vertices are not in the graph of your triangulation, but they probably lie somewhere along on the triangulation edges. Maybe there's a way to identify which edges each contour vertex belongs to, then find the paths that join different contours. I will have to think about it more.
Nice work, this was quite the undertaking. I don't have a firm grasp on the code yet, but could it be sped up if there is an exisiting triangulation? (i.e. can I get rid of the Delaunay calls if I have by own triObj = Triangulation(x,y) and I normally call plt.tricontourf(triObj,data)). My hope was in cases such as animations of a stack of images of data on a triangulated mesh, this could perhaps significantly speed up the animation.
The text was updated successfully, but these errors were encountered: