Using the Cache with Distribeast

When you run a distributed rendering job, objects in the Beast cache are sent from the submitting application to the other workers in the network. The workers then maintain those objects in their own caches, to speed up any other jobs that they may have to run.

This distributed caching involves some special considerations, outlined in the sections below.

No invalidating objects

When you use distributed rendering, your application cannot depend on being able to invalidate any objects in the cache, since those objects may have already been sent to one or more workers. If so, the objects will be maintained in the cache local to each worker. Requests to invalidate an object are not propagated to the workers.

Therefore, when you set up your object naming conventions (as described under Using the Cache), you should use a system that incorporates unique IDs into your object names in order to avoid cache conflicts and make sure you always use the most up-to-date version of your game assets.

Cache scope and object naming

When you initialize your Beast Manager, you determine the scope of its cache. The choice you make has important consequences for your naming conventions, as introduced under Using the Cache. There are also special considerations when using Distribeast, since cached objects are shared across the network.

Local scope

If you initialize your Beast Manager with a local cache scope, your object names only have to be unique for the objects sent by that Beast Manager. They will not be shared with other Beast Managers, even when you run a distributed job. This is exactly the same as when you use local scope without Distribeast.

Global scope

If you initialize your Beast Manager with a global cache scope, and you run a distributed rendering job, all cached objects sent to the workers will be visible to those workers even when they are treating rendering jobs from other submitters. This may speed up the rendering jobs, sinced the cached versions of the resources can be retrieved from the network resource cache by any job when needed.

However, this also means that when you use global cache scope and distributed rendering together, you must make sure that your object names are unique across all jobs that may be sent to the Distribeast network by another Beast Manager with global scope. If the object names are not unique, a naming conflict may lead to one of your rendering jobs incorrectly using a texture or mesh created by a different submitter. This could cause incorrect results or even rendering failures.