← All ideas
  • Published 29 Oct 2017

Cycles Render Proxy Support

Many render engines support the ability to load pre-cached "snippets" of scene files in place of another object in the scene, known as render proxies. The basic workflow is as follows:

  1. The object to be rendered is exported to a special "proxy" file. It is translated for the renderer at this time, and the resulting file can be loaded directly by the render engine without any additional translation by the host 3D app.

  2. A "proxy" object is created in the main scene, and the file created in step 1 is selected as the final geometry.

  3. At render time, the "proxy" object is ignored and the renderer directly loads to cached objects from step 1 in place of the proxy object.

This has a number of benefits:

  • The object has already been translated to the renderer, and does not need to be re-exported on every frame and test render after that. Useful for background assets such as a trees, cars in traffic, buildings, etc.
  • As a result, the object does not need to be evaluated or even loaded with the main scene, saving memory and improving performance.
  • It allows nesting of objects that would not be possible otherwise, such as a tree with particle-based leaves being cloned by a particle system. This is not supported normally in Blender, but in a render proxy situation the tree would already be cached out, and cloned into a forest as a single object.
100%

Development Status: Open

Upvote 22 Downvote 0
jason.clarke0
29 Oct 2017

5 Comments

brechtvanlommel

I think it would be better to improve Alembic and collections support in Blender to handle these kinds of use cases. The reason renderers have their own custom systems is mostly historical, there was no standard file format before and the host application didn't have any support for this kind of lazy loading builtin. Alembic and USD are now replacing that more and more.

Doing this in Cycles means we'd be duplicating work that we want all of Blender to benefit from eventually anyway. Being able to (optionally) preview proxies in the viewport or use them for Eevee as well seems important to me.

5
atair

@Brecht Van Lommel: Speaking from observation, not technical knowledge, but it seems that proxys in e.g. VRay also have the acceleration structure saved within the proxy, making scene translation very fast even when having gigabytes of proxys - which would be one argument to implement them alongside with Alemic

What also is possible with proxys that are built closer to the engine itself is dynamic loading/unloading which works in Vray/Arnold (Vray only as long as no global method like light cache is used) allowing to render scenes bigger than the available Ram.

2
dddjef

* @Brecht Van Lommel * Hello! I think there's a misunderstanding around this feature. Renderman, Vray and Arnold use proxy for memory management purpose. The proxy file is only loaded in memory when a ray hits its bounding box. The fact the proxy is in a "chewed" format is also a plus for the loading time, but it's not the main thing. For the moment, I have to load everything in blender viewport to have it in render, I won't be able to load very large scene.

1
wilBr

a must have feature for huge scenes management, small scene file size, fast scene load and save, fast viewport interaction etc.

jason

The PowerLib add-on that was developed during Tears of Steel (IIRC) offered a basic form of this kind of functionality. I've done it manually using the Edit Linked Library add-on. The automatic rendertime swap is the only thing, I think, that neither of these two add-ons provide.