Page MenuHome

Cycles: Experiment with making previews more interactive

Authored by Sergey Sharybin (sergey) on Feb 21 2015, 6:04 PM.



There were two major problems with the interactivity of material previews:

  • Beckmann tables were re-generated on every material tweak. This is because preview scene is not set to be persistent, so re-triggering the render leads to the full scene re-sync.
  • Images could take rather noticeable time to load with OIIO from the disk on every tweak.

This patch addressed this two issues in the following way:

  • Beckmann tables are now static on CPU memory.

    They're couple of hundred kilobytes only, so wouldn't expect this to be an issue. And they're needed for almost every render anyway.

    This actually also makes blackbody table to be static, but it's even smaller than beckmann table.

    Not totally happy with this approach, but others seems to complicate things quite a bit with all this render engine life time and so..
  • For preview rendering all images are considered to be built-in. This means instead of OIIO which re-loads images on every re-render they're coming from ImBuf cache which is fully manageable from blender side and unused images gets freed later.

    This would make it impossible to have mipmapping with OSL for now, but we'll be working on that later anyway and don't think mipmaps are really so crucial for the material preview.

    This seems to be a better alternative to making preview scene persistent, because of much optimal memory control from blender side.

Diff Detail

rB Blender

Event Timeline

Fixed threading issues

This revision was automatically updated to reflect the committed changes.

Sorry if this can be seen as a feature request: currently the rendered preview redraws on *any* change happening in the node-tree even if the node added/removed/changed is not connected or evaluated (mix=0/1 conditions). This is sometimes annoying since long and clean previews get cleared (and slow the system down while re-rendering) while one is making some node operation that don't affect the final material appearance.
For the sake of this kind of optimizations, do you think that this can be addressed?

First of all, thanks for the feedback. But it's actually better to happen in ML or IRC :)

Second of all, the thing you're talking about is actually in out TODO list for ages and it's something to be addressed for sure.