Tiled EXR / texture caching support?

Just checking in to see what (additional) information might be useful.

I’m going back and re-converting the existing EXRs from the source images. That seems to be working more consistently, so the darkness/brightness is understood. The error for the malloc puzzles me, though.

The tiled EXR support is only inside Cycles, but not the rest of Blender. The error thrown in imb_addrectfloatImBuf() is outside of Cycles, so it must be from Blender trying to load the image to generate a thumbnail, OpenGL preview or something like that. Those things remain untouched in the texture cache branch, it only changes Cycles itself.

1 Like

I filed the EXR crash bug for blender itself (it does seem to be specific to EXR format and doesn’t even need a viewport display to trigger - an equivalent PNG doesn’t crash).

I have been using the build for some heavy duty animation rendering recently. I am seeing reports of BROKEN files in the post-frame report. I’m a little surprised because these are freshly generated tiled EXRs on local storage for each machine and are binary identical when compared :

Machine A (SSD storage):

 214    1        1        0.0                       0.0s  2048x2048x3.f16  D:\textures\ArMan0004-M4-ArMan0004-M4-Body-D.exr  MIP-COUNT[0,0,0,0,0,0,0,0,0,0,0,1]
 215    1        5        0.0   (    4    0.0)      0.0s  2048x2048x3.f16  D:\textures\ArMan0004-M4-ArMan0004-M4-Body-S.exr  MIP-COUNT[0,0,0,0,0,0,0,0,0,0,0,5]
   BROKEN                                                                      D:\textures\ArMan0004-M4-ArMan0004-M4-Hair-S.exr
 217    1        5        0.0   (    4    0.0)      0.0s  2048x2048x3.f16  D:\textures\ArMan0004-M4-ArMan0004-M4-Head-D.exr  MIP-COUNT[0,0,0,0,0,0,0,0,0,0,0,5]

Machine B (spinning storage)

   BROKEN                                                                      D:\textures\ArMan0004-M4-ArMan0004-M4-Body-D.exr
     215    1        6        0.0   (    2    0.0)      0.0s  2048x2048x3.f16  D:\textures\ArMan0004-M4-ArMan0004-M4-Body-S.exr  MIP-COUNT[0,0,0,0,0,0,0,1,0,1,1,3]
   BROKEN                                                                      D:\textures\ArMan0004-M4-ArMan0004-M4-Hair-S.exr
     217    1        3        0.0   (    1    0.0)      0.0s  2048x2048x3.f16  D:\textures\ArMan0004-M4-ArMan0004-M4-Head-D.exr  MIP-COUNT[0,0,0,0,0,0,0,0,0,0,1,2]

I noticed that the branch was updated with master, so will try and build that in case it makes things better or more consistent.

1 Like

Some follow-up here. I’m getting some odd behavior in this test; not sure whether it’s useful. I have a noise-driven water surface under a tiled-EXR-image-textured skydome. During render, some of the buckets on the water seem to end up much darker. I’ve also seen this on other elements in the main scene (buildings, grass, etc.).

Rendering this small test scene with regular blender doesn’t show these artifacts.

If it’s useful, I can package the scene for you.

I’m just following up on this - would the blender scene file be useful?

1 Like

Hi folks, getting into the blender world. I’m developing a personal project and I’m willing to change it from max to Blender, however I’m using A LOT of tiled EXR’s and I was wondering if this tiled EXR/TX caching feature is already implemented in B 2.80

Is this implemented right now? Or planned to 2.81? Thanks a lot guys!

It’s not in 2.80, it will be for a later release but it’s not attached to a specific version yet.

@Brecht : good to hear. Will that implementation also extend to the viewports so that they don’t try to display the high detail mipmaps, but something much less demanding? I never heard back about my bucket-related weirdness with the branch, so wondered if this project had stalled.

Looking forward to it! Its a feature that can improve massively the amount of textures in the scenes without swapping RAM, so its really important for massive environments rendering in acceptable render times (or even allowing it to render, as some folks uses lots of high res UDIM textures in the scenes that may not fit in RAM when not mipmapped)

Thanks!

2 Likes

I wondered if this was any update on the scheduling of this support. It looks like the branch was updated in late January, but its overall status is unclear to me.

Any news on this, folks? I cant code but if I can help somehow I would be glad to.

Thanks!

1 Like

@StefanW : I saw the branch is being kept up to date somewhat; is there anything pending at this time?

How did a miss this patch, this is super interesting / important!
This can save a ton of memory in exterior scenes.

@StefanW @SteffenD I have some quick questions:

  • Does it work with GPU? (I think it does not… but just in case)
  • Is something that can be disabled to avoid using it in situations where you don’t want it at all? (like having it as an experimental feature that can be disabled to go back to the current status).
  • Is it being kept up to date with 2.91?
  • Where is the branch to extract the patch? I would love to apply this to our build and test it.

Thanks!

2 Likes

Hi, the link was posted earlier in the thread: https://developer.blender.org/diffusion/B/history/cycles_texture_cache/
Last update was from June.

Cheers, mib

1 Like

thanks @mib2berlin! :slight_smile:

However, will see what the answers to the other questions are, to know if it’s in a status taht can be useful to merge it in our build :slight_smile:

1 Like

I’m in the middle of updating it to the latest master. There’s something not working with displacement maps at the moment, but that shouldn’t be hard to resolve.

10 Likes

Awesome, as soon as you tell me something I’ll apply it :smiley:

2 Likes

Also looking forward to this. I’m using a lot of Tiled EXR files and I’ll Switch from Max to Blender if this can be implemented.

2 Likes

@StefanW any patch to test? :slight_smile:

4 Likes

I found myself revisiting this thread and wondering about the current status of the branch and any merge plans. Is there news?

2 Likes