Some iray ressources consumption tests

Anim

While I was reading some of the GPU memory threads here I had the idea to make a few tests.

I especially wanted the values to be in Megabyte and Gigabyte. So I did some test renders with G8 and a hair in a simple no lights, dome only scene.

Results are below and they are as I expected them to be.

But there is one question:

I did use:

- no hdr panorama

- the Daz default one

- a super highres one

but the ressources consumption did not change.

Any idea about that?

Mattymanx

In Daz Studio 4.10 and earlier, Iray use to load the textures once for every surface they were used on.  That was part of why I created this set - https://www.daz3d.com/resource-saver-shaders-collection-for-iray - The info listed there for textures is for 4.10 and earlier, as geometry handeling is still the same.  I am curious, what was your texture compression set to for your tests?  Did you change it at all?

As of DS 4.11, the newer Iray handles textures better and its less of an issue.  Though they  are still a larger resource hog than geometry is.

Anim

You are right, compression was at default 512 - 1024.

Should have also mentioned:

- Studio 4.12.1.16 beta was used

- Render size was H 1280 W 720

Attached is a result with texture compression set to 512 - 4096

 

Anim

I have added values for compression set to 8192 - 8192. That means more or less no compression in this example. Texture size goes up to 1,4 gigabyte.

One need to decide whether it is worth it (check the hair it rendered better).

I also made a render with lowered pixel filter. I like to use mitchell instead of gauss if I need crisp details (value is 0.9 in this example which makes the image a little to harsh, but it shows the effect of filter size compared to texture compression.

 

JD_Mortal

Just a note here... Texture compression ALSO applies to any screen-backdrops ("environment" window, image set as background), rendered plane backdrops, and HDRIs that you have in the scene. (Which it honestly should not be doing for those specific items, as a back-drop and HDRI should not actually be "rendered", but rather, it should be scaled to fit the scene and simply projected to occupy the "ALPHA" spaces.)

Thus, if you are rendering a 4096x4096 backdrop with a 4096x4096 output, but have compression set to anything lower than 4096 and 4096, the backdrop will also be compressed, then "blown-up", to occupy the same pixels as 4096x4096. This is less obvious if you use a larger image for the backdrop, and it fits into a smaller scene-space, but it is still visible, in many instances.

The compression leaves a moticable pattern of checkerboarding where a smooth gradient should be. As well as fine detail loss, where individual pixels should be, which now span multiple or partial pixels. (As if it was shrunken to 512 then blown back up to the original size, with a "blend" or "soften" filter that is linear pixel-resize, instead of spanning to a true blended-pixel.

I understand why it does this, however, it should not be doing this, as it is not needed for these instances and there is no way to "turn it off", that I know of, per item. (You can't force texture compression to be ignored on a specific item, as it is an all-or-nothing option. One with a default that is no longer ideal for the times, with 4K resolutions being the average render-size and 8K slowly creeping up into production levels. Previously they were 1024, which was still smaller than 1080p resolution. Which is when I noticed the issue as my backdrops were all getting visually mangled by this compression setting. Making the use of a backdrop useless to me, except for previewing what the scene will look like, after I render, with the backdrop added in manually, by an external art program.)

Translation: You will lose the original image quality for your backdrop, if it does not match the threshold values. Thus, you are forced to use values which are required to sustain the backdrop detail, which may not be needed for the model detail, which unnecessarily increases your overhead for rendering.

Workaround: Turn off the backdrop image before actually rendering and apply the backdrop in an external art program, using the ALPHA background from the render. For the HDRI, you have to render that item individually, with a compression setting that matches the HDRI image, so it does not compress before rendering. (I have HDRI images that are in the 40,000 pixel size, but a resolution that is equal to your rendered output size, the largest square, is adequate for retaining the least noticable compression of the HDRI background. The HDRI resolution is not overkill, as much as one thinks. It is for rotation or motion quality, which can not be gotten by smaller images for the HDRI, without causing mid-pixle overlap distortion. It treats them as sub-pixels instead, for more accurate and smooth rotation angle transitions.)

JD_Mortal

I can't wait for "smart compression", where it simply evaluates the surfaces size on the output, and then adjusts the compression, based on that "need".

If the eyeball is only occupying one pixel, a 4096x4096 image isn't needed for the texture of the iris, nor is a 512x512, for that matter. However, if the eye is nearly 50% of a 4096x4096 render screen, then sure... load the 4096x4096 image for it, but not the unseen finger-nails, which have the same image size, in a distant reflection in the eyes, which only reflects them as a 16x16 image in the reflection.

This is also an issue when trying to render one close-up model with a series of distant models. You can remove the object detail complexity of distant models, but not the texture detail compression, which goes back to the "all or nothing", settings. (I think there is a plugin for that, but I am not sure if it still works or if it works "that way". I think it is called "scene optomizer"? But, it may be a one-way ticket, destructive optimization, which is not ideal for traveling cameras in a render.)

I'm tired of deleting hands and feet and eyes, and the additional reflections and sub-surfaces and normals, that go with them. :P

Anim

Hm, interesting consideration.

But I don't see an effect in test renders

The used exr panorama is: 10240 x 5120

Render on the left:

min threshold: 14336

My understanding is that no compression takes place because the image is below min threshold (max threshold (16000) is not relevant in this case).

Render on the right:

max threshold: 1024

My understandinf is that the image gets maximum compression because it is above the max threshold (min threshold (512) is not relevant in this case).

There is no visible difference in the renders and the log says no memory is used for textures. It seems, the environment is not consuming texture memory at all and is not affected by compression.

But I am not sure about this conclusion. Do you have an example with a more high res pano?