We generate our USD files through Houdini/ANARI/… on our desktop systems, and I want to distribute the generated USD to our large HPC clusters for rendering. We can’t install a third-party queuing system as we already have a ‘blessed’ version, and our desktops don’t have access to the queuing system, which would then require copying the files over the network.
I’m looking at modifying a Hydra-compliant renderer to run distributed in a client-server mode. I’ve already done this for a different file format with the same renderer (put the renderer(s) into the queue on the cluster, once they are running on the nodes they establish a connection back to the main host, my desktop, and the files are distributed across the network, caching the files on the remote server so repeated renderings don’t require additional transmission.
I’m lookin for pointers as to where the best place is to hook this in. One way would be non-intrusive and sit over/alongside USD, but where? Load a stage in the client and traverse its children transmitting as we go, or is there something at the plugin level like an ArResolver that would work? Or something else? The other way would be to create a distributed stage.
Any pointer to others who have done this or where to hook in would be appreciated.
It sounds to me like an asset resolver is probably the way to go… You might want to look at VFX-UsdAssetResolver/src/HttpResolver at main · LucaScheller/VFX-UsdAssetResolver · GitHub which is an asset resolver for http based USD assets, which I believe downloads the assets to the local machine over http when such a file is requested. Though I could certainly be misunderstanding your requirements.
@mtuckerarHttp is not that actually (I made it): it simply allows to offload asset resolving to another process through a very simple HTTP url conventions. This is useful to prototype asset resolving in Python. However, @dhruvgovil mentionned that he is working on an actual Http resolver that would download the layers on request.
I think the concept behind arHttp would work, but yes a real Http resolver to work from would be better.
The idea for me is that a remote machine will open a base .usd file, and if the resolver can’t find a local copy of an asset it wants to load, it sends a request to the data server, which locates the asset and then ships it back over some network protocol to the requestor which will create a local cached copy along with a checksum to avoid retransmitting in the future if it hasn’t changed on the data server.
I just implemented such a process with a very much simpler workflow. Before the actual renderprocess starts, I execute a python script which uses ComputeAllDependencies(), copies the required files locally and then sets the PXR_AR_DEFAULT_SEARCHPATH in a way that the local files are found first. Even if this is quite low level, it works fine here.
That would be great if you could provide an example of what you’re doing. In the meantime, I’m trying to build some of the example asset resolvers (the link above, Luma Pictures, …), most seem to assume that you’re working with an installed USD from a DCC/NVidia distribution. I’m trying to develop from a source build. I hacked the daylights out of the VFX-USDAssetResolvers (FileResolver for now) to work with a python from a virtual environment and a source build, and it almost compiles (missing Py_dealloc during link).
Any pointers to cmake magic for building against a source distribution. I tried the method that looks for pxrConfig.cmake, but it can’t find OpenSubdiv, which is weird.
Thanks @charlesfleche for the correction. I guess I just assumed based on the name. What you describe actually sounds even cooler (thigh maybe less directly applicable to the original post)
(thigh maybe less directly applicable to the original post)