Chris Rydalch

In USD, reading stages can be multi-threaded, but writing is single-threaded. As for VEX in LOPs, Python is better when operating entirely on USD prims. There is overhead to getting the USD data into VEX, in order to run the SIMD operations in parallel. While the kernels run, threads are saturated, but after those run, we're back to converting data and doing single-threaded writes to USD. This is also why adding VEX into your prim patterns can add a lot of overhead, compared to using the prim pattern functions. So Python is better for performance in LOPs, though VEX can be convenient to write (and is preferred when doing mixed SOP/USD read/write).

Python can be so fast, because it's often a pretty thin wrapper around the USD/SDF C++ operations. It's certainly possible to make the Python functions slow in LOPs, but I'm continually amazed at how much performance can be squeezed out of Python with Solaris.

I highly recommend this presentation by Mark Tucker (Solaris lead), where he goes over LOPs cooking details, and how to make your networks/nodes as performant as possible: https://www.youtube.com/watch?v=ukfe2gOJ3l0 [www.youtube.com]. A fair bit of the details make more sense when writing C++ LOP nodes, but also covers Python, VEX, profiling performance, etc...

Hope this helps!

Sorry I kept getting pulled away, after having this tab open for a bit. I think the subframe range and number of samples just needed to be higher; and then cache the frame range, but on 1's, on the GeoClipSequence.

By default, any unconnected `texcoord` inputs will rely on the default `primvars:st` texture coordinates. If you have UVs using a different name, then you'll want to connect your geomepropvalue reading those primvars, and connect them to the texcoord input. You might also need to convert the vector3 to vector2 explicitly, if it's behaving unexpected.