TrackedArray vs numpy array

Hi,

I did some processing for a Trimesh object and then got the new vertices viamyverts = mesh.vertices. I then did some subsequent computations on myverts which went fine. However at some point I happened to notice that myverts is actually of type TrackedArray. Converting it to a simple numpy array I got a speedup by a factor of 4.

This is not really a big issue, but I was wondering if there should be a method to return the vertices as a simple numpy array, or maybe at least the docs should mention that using the property will yield a TrackedArray.

[mikedh]

Oh interesting. The TrackedArray is the thing that enables caching, which provides huge speedups in applications accessing properties multiple times so it’s kind of necessary for vertices and faces. If this turns into an ongoing issue, I wonder if we could make it so copies of a TrackedArray revert to ndarray type.

That being said, in some quick and dirty profiling I couldn’t see any speed difference:

In [1]: import numpy as np                                                                                                                 

In [2]: import trimesh                                                                                                                     

In [3]: m = trimesh.creation.icosphere()                                                                                                   

In [5]: v = m.vertices                                                                                                                     

In [6]: n = m.vertices.view(np.ndarray)                                                                                                    

In [7]: n                                                                                                                                  
Out[7]: 
array([[-0.52573111,  0.85065081,  0.        ],
       [ 0.52573111,  0.85065081,  0.        ],
       [-0.52573111, -0.85065081,  0.        ],
       ...,
       [ 0.91298249, -0.39960705, -0.08232358],
       [ 0.91298249,  0.39960705,  0.08232358],
       [ 0.91298249,  0.39960705, -0.08232358]])

In [8]: v                                                                                                                                  
Out[8]: 
TrackedArray([[-0.52573111,  0.85065081,  0.        ],
              [ 0.52573111,  0.85065081,  0.        ],
              [-0.52573111, -0.85065081,  0.        ],
              ...,
              [ 0.91298249, -0.39960705, -0.08232358],
              [ 0.91298249,  0.39960705,  0.08232358],
              [ 0.91298249,  0.39960705, -0.08232358]])

In [9]: %timeit np.linalg.norm(v, axis=1)                                                                                                  
31.6 µs ± 978 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [10]: %timeit np.linalg.norm(n, axis=1)                                                                                                 
30.7 µs ± 1.08 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [11]: %timeit np.dot(n, n.T)                                                                                                            
1.81 ms ± 43.5 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [12]: %timeit np.dot(v, v.T)                                                                                                            
1.84 ms ± 32.2 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

[jjnurminen]

Ok. It’s not really a problem for me - just wanted to make sure there wasn’t a bug or something. I think my use case is kind of uncommon anyway, since I’m looping through a subset of vertices and modifying it in iterative fashion.

Thanks for the package BTW - it already saved me a lot of time.