-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This wiki will be a more in-depth look at what AYON USD Resolver can offer, how it works, and why we decided to implement it in the specific way we did
In the simplest terms, a USD resolver is a "plugin" that hooks into OpenUsd to allow the asset Resolution system to "find" files.
The advantage of writing a custom asset resolver is that we can connect USD very closely with AYON and ensure that all the nice features you can use with Ayon will improve when using USD.
- here's an example.
- Let's say you have some published USD files on your AYON server. But you must mount the Network drive in different places on your workstations. Usually, this could get really annoying because you
- A. need every file with a relative path
- B. you need to move the drive location.
- But if you use an asset Resolver communicating with AYON, the server can inform your USD instance about where to find the right files. Therefore, all file paths are absolute and always tracked by AYON. There is no risk of losing files on the go.
- Let's say you have some published USD files on your AYON server. But you must mount the Network drive in different places on your workstations. Usually, this could get really annoying because you
- Render farms are a very common problem when discussing asset resolution and server communication.
- Reasons for that are usually that many machines will ask the server for the same information and thereby practilcy DOOSing the system But because we write our own asset resolver, we can use a simple trick to eliminate that problem. We simply store a file that holds a frozen resolution state. Later on the farm, we load this file and disconnect the Ayon-Cpp-Api, thereby eliminating the option to communicate with the server while still storing the Resolution information.
this section will talk about how the Usd resolver internally works and why we did some things the way we did.
our resolver is registered as a Primary resolver. This is done so we can cache every file we come across. It also allows us to create some nice little performance metrics regarding Uri identification.
every time an asset needs to be resolved within USD, the Asset resolver resolve() function is called. This then triggers a sequence of steps namingly. AyonUri identification, Cache lookup, Server call, path assembly. The most expensive step is the Server call. That's why we have some options to batch together information before calling the server to decrease the time it takes to resolve a scene.