Texture management in the viewport
I'm a heavy user of large images in projects (generally as tiled EXRs). Coming from older tools (infiniMap/LW) and, more recently, modo, I'm missing ways of dealing with this with respect to the viewport. Often, I end up crashing blender.
I filed a bug about this a while back, but wanted to see what the community felt in terms of usefulness and practicality.
For reference, db&w's wonderful infiniMap plugin for LightWave 3D is designed for insanely large textures to be used efficiently (via tiled EXR). Noting that these textures often exceed a machine's ability to display or edit them, it therefore offers a 'create proxy image' button that allows the user to select a low resolution 'proxy' image that is only used for display purposes. At render time, the high resolution image is utilized. This also prevents the runtime pain of rescaling the image for the viewport (and, for very large images, or scenes with large amounts of data this runtime rescale can fail due to memory constraints - as noted earlier).
In modo, the global preferences allow for a maximum OpenGL texture size to be set. It's less elegant, but works pretty well. More recent releases also permit textures to be entirely blocked from the viewport display and thumbnail generation systems, avoiding out-of-memory or expensive computations (and application slowdowns)
So, with regard to non-tiled, non-mipmapped formats, I'd really like to see the ability to :
- Permit a user defined 'proxy' image to be specified and used for viewport/thumbnail display, with the 'real' image being used only at render.
- Permit textures to be entirely blocked from any viewport/thumbnail display.
Both options above also apply to mipmapped formats, but it would be good to also perhaps offer some level of control over the displayed mipmap level (defaulting to the lowest resolution, least resource intensive), if there is some ability to offer special handling for such formats.
3 Comments
I hope the overrides planed for 2.8x will solve this problem. You could create a low-detail version of the material for the viewport, and create a render-time override with the large image. Maybe? I'm not sure how overrides are gonna work.
While proxies and mipmaps would be great to have, what you can do already for the sake of having light textures in rendered viewport is to use the simplify panel
@Lsscpp: Unfortunately, that doesn't work in the case of many large images, or large scenes. The overhead of simplifying a large texture or many large textures often leads to a crash. It's why these other mechanisms in other tools exist. Having to simplify the image often requires loading the image fully in order to simplify it, preventing any gain from being realized because the machine is exhausted by the effort to resample the image. I've tried simplify and often it doesn't help me avoid the blender crash behind my request.
This proposal also relates to the devtalk.blender.org/t/tiled-exr-texture-caching-support/562 branch of blender where the Cycles implementation for tiled EXR handling is almost there (some bugs), but the rest of the system needs to be able to handle the incoming data to prevent trouble.
The blender V-ray fork (and presumably other renderers) also offers support already for large mipmapped (tiled) EXRs, but the blender system can't efficiently handle typical tiled EXR files (large images, by-design) without often failing.