Thank you! I’ll take another look at that again anyway. We’re not using adaptive subdivision precisely because of it’s horrible memory consumption, and the style of the show doesn’t really need it anyway
How many render passes do you use? Every pass you enable takes even more vram. You can mitigate it a bit by doing tile renders.
Don’t know whether you were talking about that addon but that might be a solution?
1 Like
Right now we’re using mist, denoising data and cryptomatte, I was setting up a bunch of other passes before but it was impossible to render.
I’ll take a look at tiling too, right now it’s at default 2048
I tried this one but it force us to have everything local on the scene, and we’re working with linked assets, so it’s not really an option.
1 Like
This isn’t it, they seem to be more focused on resizing than picking the proper bit depths and color channels.
Which is important but only solves half the problem.
1 Like
Arnold converts textures to .Tx files.
3 Likes
ReSTIR implementation is currently proving to be difficult regarding how best to handle the flexible methodology to Cycles’ shading system. I get the impression that the implementation showcased in the official Nvidia paper is optimized for materials that make use of a Principled shading system like what pops into the tree by default when a new material is created.
The various papers are not clear on how to handle a system based on building blocks, so I am guessing the devs. are not willing to spend too much time trying things when there are other ways to speed things up.
2 Likes
Hey @Ace_Dragon, thanks for sharing this insight on RESTIR. I’m curious, where did you come across this information?
4 Likes
Seconding your question.
.Tx files are just EXRs with multiple layers. 
They won’t improve much if the renderer don’t deal with loading the correct layer when rendering.
You never worked with Arnold or Renderman for that matter?
A renderer written with this specific feature is way, way more memory efficiënt than Cycles.
1 Like
The two go together.
Without one, the other can’t work, especially the tile system and mip map.
1 Like
.tx files are not necessarily layered EXR files.
When we used Arnold in Softimage (a loooong time ago, 2009 IIRC), it was recommended to convert every texture to .tx manually or let the Sitoa (Softimage to Arnold) plugin do an auto-conversion before rendering.
Under the hood, it used the OIIO maketx tool to convert bitmap texture files to .tx files. In its default configuration, it uses TIFF file format. I just looked it up in the current documentation and it still uses TIFF, if you don’t specify EXR explicitly:
https://openimageio.readthedocs.io/en/latest/maketx.html#cmdoption-format
The downside of TIFF is that it’s just an unregulated container like AVI or MOV where you can put anything inside. I remember that so many times we had to open TIFF files, that only opened in a specific software, ZBrush back then even was able to export TIFFs that it couldn’t import afterwards!!! 
The upside is that TIFF can handle 8-bit data (which saves a lot of memory because most of the textures are 8-bit still) while EXR can handle just about anything BUT 8-bit.
But in the end .tx can be either TIFF or EXR because they’re the two formats that support both tiles and mipmaps. Blender can take advantage of .tx since OSL was added BUT only if you render on CPU! OSL on GPU is possible but it doesn’t support the tiled / mipmapping features of OSL.
My biggest feature request for Blender for about 15 years is a texture cache that can handle tiles and mipmaps or “texture streaming” or “pyramid mapping” or what it might be called.
I don’t have high hopes for meshlets or “Nanite for xxx-renderer” or whatever they might call it. Even in Octane I bet we won’t see it for another 5 years (Otoy are masters of promising amazing features that you’ll never see 
).
But having a texture cache mechanism that frees us of always having to think about the bit depth and resolution of every single texture and their amount will be such a relieve.
11 Likes
I’m just saying that memory management is mainly a part of the renderer, and Cycles doesn’t has that implemented…
AFAIK, OIIO deals with tiles on its own, and the maketx just makes the Mip-Maps and stores them in layers in an EXR or TIFF output (as stated in the OIIO source code). The .Tx itself doesn’t do any magic.
Oh that would be a shame, it sounded so promising but I suppose most things that sound too good to be true usually are.
It seems Pro-Render from AMD had some implementation but I have no idea what the limitations are or how well it works.
I wonder whatever happened to getting path guiding on the GPU. Seems that is dead in the water. Last I heard they were waiting for Intel but that could be a long wait.
1 Like
I knew there was a blender branch
Stefan Werner was working on it.
4 Likes
Wasn’t this part from the work that was done for Tangent Animation? I remember reading something like that long ago but I can’t remember where
2 Likes
Yes, it was Stefan Werner working on a texture cache for Blender / Cycles at Tangent Animation back then because otherwise the whole production of “Next Gen” wouldn’t have happened.
3 Likes
I hope the devs get back to this project in the not too distant future 
3 Likes