Open topic with navigation

Intro to Proxies

Table Of Contents

• Introduction
• Important Considerations
• UVs, Vertex Color, & Other Per-Vertex Attributes
• Motion Blur
• Instancing & Tessellation
• Creating & Exporting Proxies
• Export Parameters
• Using Proxies
• Proxy Object Parameters
• External Proxy References / How To Transfer Proxies

Introduction

Redshift Proxies allow you to place previously exported Redshift Proxy Files (.rs) files in your scenes without actually loading the geometry until it is actually needed at render time. You can think of a Redshift Proxy as an actual Redshift scene all on its own, they can even contain other Redshift Proxies.

Using Redshift Proxies in your scene is a 2 step process. First you export a Redshift Proxy File, then you import and place a Redshift Proxy in your scene and associate it with the exported file.

Using proxies has several advantages over in-scene objects, namely:

• Proxies are loaded by Redshift on demand and will therefore only use resources when they are needed (when a ray intersects the proxy's bounding box).
• Proxies have almost no time cost during scene translation. Extracting large amounts of geometry can be slow and using proxies means you pay that cost only once, when you first export the Redshift Proxy File.
• Proxies are stored in an optimized format on disk so that the renderer can immediately use the data after loading from disk without additional processing or memory overhead.
• Support for object types including animated and deforming meshes, hair, strands, instances, volume containers, lights and any materials/shaders applied to these objects.

The main disadvantages of using proxies:

• Making edits to the proxy can be more time consuming than if the original data is part of the scene (as it requires making changes in another file and re-exporting the Redshift Proxy File)
• After export Redshift Proxy geometry cannot be deformed or otherwise modified aside from adjusting tessellation settings. For example, you cannot animate components inside a proxy after export, but you can animate the position, rotation and scale of the proxy as a whole rigid object.
• Animated proxies can be heavyweight because they are per-frame caches.

Redshift Proxies provide the option to use either the materials embedded in the Redshift Proxy File, or to replace those materials with materials from the scene where the proxy is placed.

Redshift Proxy Files are DCC-independent, so for example you can export a Redshift Proxy File from Maya and import it as a proxy in Houdini, or vice-versa.

Important Considerations

When working with Redshift Proxies, it is helpful to keep the following things in mind:

• You cannot retrieve the original Maya, 3ds Max or Softimage mesh from a Redshift Proxy File, so it is advisable to keep the original source data that was used to export the Redshift Proxy.
• When placing multiple copies of a Redshift Proxy in a scene, it is much more efficient for memory and performance to create a single Redshift Proxy and then create multiple instances of this proxy and place them as desired.

The data exported with your Redshift Proxy is determined by your Render Settings at the time of export, by default Redshift will try to discard as much unnecessary data as possible to achieve the most efficient file size.

UVs, Vertex Color, & Other Per-Vertex Attributes

When exporting a set of objects as a Redshift Proxy File, only the vertex attributes used by the currently assigned shaders are included in the exported data. This is an important optimization to prevent file bloat. When a proxy file will be used as-is, without overriding materials, this is not an issue. However, when using proxy material overrides, this can cause unexpected behavior if the overriding material requires vertex data that was stripped at export time because it was unused. So if you need certain attributes for your proxies at any point down the line, make sure that a shader attached to your proxy object is making use of those attributes. For example, if you have a sphere with a spherical texture projection and an untextured simple material assigned, the texture projection will be stripped at proxy file export time because it is not used by the currently assigned material. If this proxy is then placed in another scene and the material is overridden by a material that does use UVs, it will render incorrectly due to the missing UVs.

Motion Blur

In order for Redshift Proxies to render with Motion Blur you must make sure that motion blur is enabled in your Render Settings at the time of export.

Instancing & Tessellation

If you are planning on instancing your Redshift Proxies please keep in mind that you can only use fixed tessellation.

Creating & Exporting Proxies

Export Parameters

Using Proxies

Proxy Object Parameters

External Proxy References / How To Transfer Proxies

Given that Redshift proxies can contain anything in a Redshift scene, this means that they can externally reference image files (such as EXR, PNG, etc), volume grids (like OpenVDB) and even other proxy files!

These external file references are stored in Redshift proxies both as absolute paths and as relative paths. Let's look at that with an example.

Let's say that a proxy file proxy.rs is exported in folder C:\MyProxies and it contains a shader that references texture mytexture.png which is under C:\MyProxies\Textures

The folder structre would look like this

Within the proxy.rs file, the reference to mytexture.png will be saved both as:

• An absolute path filename, i.e C:\MyProxies\Textures\mytexture.png
• A relative path, i.e .\Textures\mytexture.png

Redshift contains file paths both as absolute and relative in order to facilitate the "transporting" of proxy files and their external references.

To explain with an example: let's say that the above proxy and texture (and their folder structure) were to be copy/pasted on folder C:\MyOtherProxies and the original C:\MyProxies folder was deleted.

The absolute path would no longer work because there's no C:\MyProxies\Textures\mytexture.png file anymore! (we deleted the folder!)

But the relative path would still work! Because, relative to C:\MyOtherProxies\proxy.rs there would still be a .\Textures\mytexture.png path.

Now let's consider a proxy file that references a texture folder on a completely different drive! For example:

Unfortunately, in such a case it's no longer possible to construct a relative path because path C:\MyProxies\proxy.rs and path D:\Textures\mytexture.png have no common "root"

So, using this folder layout, if the textures were to be moved to a new drive (say, E:\), then the proxy would no longer be able to find them.

In such cases, we recommend using Redshift's path override environment variables

If your texture folder used to be D:\Textures and now it's E:\Textures, you can use the REDSHIFT_PATHOVERRIDE_FILE or REDSHIFT_PATHOVERRIDE_STRING to tell Redshift to turn E:\Textures.

The online documentation page explains how to do that with an example.

If you don't know what external references a proxy might contain, you can use redshiftCmdLine's -printdependencies switch (followed by the proxy's filename) to list these.