Autobump and displacement

[tsmithBN2CR]

Hi All,

I have been having a banding-like artifact issue with Arnold autobump displacement for some time now, both in Maya and Houdini, in multiple versions of Arnold across several years (also including multiple versions of Maya and Houdini, as well as Gaffer albeit with a different asset). While it does at first glance look like a banding issue caused by 8-bit or 16-bit displacement, the maps are 32-bit, and the issue disappears when turning autobump off, or when rendering the exact same displacement maps in other renderers like VRay. 

That being said, because the no autobump workflow requires using an incredible number of subdivisions iterations in order to capture all of the detail present in the 17 x 32-bit displacement udims , it does not seem to be a robust solution, especially when tests in other renderers like VRay do not have the same issue. It seems like a bug or limitation in how Arnold autobump functions or I am missing some fundamental setting or some have suggested there could be a floating point issue with the displacement maps themselves (I do not currently have a license for Nuke in order to investigate).

When I last investigated this issue I easily spent over 40 hours trying every combination of subdivision bounds, subd iterations, uv type (smooth, pin, unppined, etc), filenode settings (<udim>, old school manual uv tile offsets in 2d placement nodes combined in layered texture). 

1. If I delete all sections of the model except faces linked to udim 1001, the artifact nearly goes away entirely. As a test, I created 17 versions of the model, starting with one mesh that included only the faces for udim 1001, then including faces for 1001-1002, then 1001-1003, 1001-1004, 1001-1005, 1001-1006, 1001-1007, 1001-1008, 1001-1009, and so on until 1001-1017. With each additional section/udim of the model included, the issue gets worse. I included 'Ni_autobump_tests.zip' in this post which shows the normals pass from this render test (the banding effect is visible in all channels, not just normals). 

2. If I use lower subdivision iterations it reduces/eliminates the issue, however using lower subdivision iterations causes other types of artifacts, specifically, the combination of the lower number of subdivisions and autobump, causes  sculpted creases to have a sort of wavey line, so the autobump captures the detail of the displacement maps, but the actual tessellation isn't high enough to properly capture the 'crease'.

Has anyone else encountered an issue similar to this? happy to provide any additional information required and I can upload a test scene from maya and or houdini with downressed displacement maps.

Here is render test on my artstation page, note this was rendered with autobump turn off and subdivision iterations cranked high enough to gobble up a rather incredible amount of ram:

https://www.artstation.com/artwork/Oy0YX6

Thankyou,

-Travis

[lee_griggs]

Does it happen on other geo or with other displacement maps?

Can you share the original displacement map/geo or a small section of each?

[tsmithBN2CR]

Hi Lee,

First off, thankyou.

Will test with other geo and/or with other displacement maps shortly. I might have run a similar test before but maybe not with alternative displacement maps. Will test both alternate geo and alternate displacement maps and get back to you.

In the meantime I attached a zip to this post with the geometry. Will upload another with the displacement maps shortly (this version of the displacement maps are 8k so might need to use dropbox or downres, will test a downres as that might be the easiest way).

P.S. Sent private message with password.

Thanks again!

-Travis

[tsmithBN2CR]

Hi Lee,

Downscaled my displacement maps from 8k to 2k and saved them in three separate zip files. Due to the size of the files I needed to spread the upload into 3 posts here.

Thanks again!

-Travis

[tsmithBN2CR]

Udims 1008-1014

[tsmithBN2CR]

And lastly 1015-1017. Let me know if you would like 8k versions of the displacement maps.

[tsmithBN2CR]

And lastly I saved 1001 at 8k with PXR24 compression just to make it uploadable. I test rendered locally and it does not seem to effect the result at all.

[tsmithBN2CR]

Hi All,

I tried the test suggested by Lee, in this case I made 17 planes and offset each plane so each covers 1 udim, for 17 planes and 17 udims, then combined into one mesh, then exported as alembic.

This is 6 sudivisions (keep in mind that each plane has only 1 face)

This is 9 subdivisions with the same geometry and displacement maps.This is 12 subdivisions with the same geometry and displacement maps.

Will now test with displacement maps from a different asset.

[tsmithBN2CR]

Just as a test, I borrowed some displacement maps from a completely different asset, and rendered them on the same 17 planes with 17 udims setup.

The only common thread between these two sets of displacement maps was that the original displacements were baked out of Zbrush (or Zbrush+Mudbox in the case of the first test), and edited in Mari in order to add additional high frequency details. Will try displacement maps with no Mari post processing just to confirm this isn't some fun new feature introduced by Mari.

6 subdivisions.9 subdivisions.12 subdivisions.

[tsmithBN2CR]

As one last test, I baked fresh displacement maps from Zbrush from another completely different asset, and ran through the 6, 9 and 12 subdivision tests.

6 subdivisions.

9 subdivisions.

12 subdivisions.

[lee_griggs]

When trying to replicate your setup, I don't see any banding but I don't know if I am using them in the same way that you are. Do you have a simple scene with your shading network to get an idea of how you are using them (the password didn't work with Ni_meshes.zip)? 

I see that the maps are set to RGB and not grayscale in Photoshop.

[lee_griggs]

Are you using the latest plugins, btw?

[tsmithBN2CR]

Hi Lee,

Thanks again for taking the time to look into this. I am using Houdini 19.5.640 - Py3.7 with HtoA - 6.2.2.1 (6.2.2.1_19.5.640_0a87540) - June 20 2023 09:14:38 Arnold Core 7.2.2.1. Not quite the latest but close.

I copied your settings but most specifically the Error (ar_subdiv_adaptive_error) setting of 0 and it *almost* eliminated the issue but I do still see faint banding that seems to be linked to the number of udims or at least whether or not a model has udims. Running more tests on my end to determine whether or not it is the number of udims or just whether or not there are udims (also need to test with the asset mesh). Will post results asap.

Subdivisions set to 9 and Error set to 0 (ar_subdiv_adaptive_error) with only 1 udim. The banding is almost invisible but need to also test on the asset mesh, this is just a single plane.

Subdivisions set to 9 and Error set to 0 (ar_subdiv_adaptive_error) with 17 udims. The banding opacity seems to increase, but it is significantly reduced (previously our Houdini scene had Error set to 1.1, initial setup was by another artists so unsure why they set it so high).  This is with 17 planes and 17 udims.

In any event, why should setting the Error to 1.1  (ar_subdiv_adaptive_error)  cause this banding effect when coupled with udims? Could this indicate there is a bug in how autobump functions in Arnold?

Subdivisions set to 9 and Error set to 1.1 (ar_subdiv_adaptive_error) with 17 udims.

Will post more tests asap.

Thanks again,

-Travis

[tsmithBN2CR]

Hi Lee,

I sent the password for Ni_meshes.zip via private message. 

Did more tests yesterday. My overall conclusion is it seems to be some combination of error (ar_subdiv_adaptive_error, with lower values reducing but not eliminating the issue), the number of subdivisions (you can see the artifact changing in size based on the number of subdivision iterations), and the number or at least presence of udims (Using 1 udim only seems to nearly eliminate the issue, but I am not sure if that is solution?).

I have tested this with displacement maps freshly baked from Zbrush with no post modifications, as well as displacement maps that have been edited in Mari to add additional high frequency details in Mari from completely different assets with completely different base meshes with those 17 planes with 17 udims tests yesterday.

The following are tests with the asset mesh, using an error value of 0 or 1.1, wedge tests of 1-5 subdivision iterations, and 17 vs 1 udim.

1 subdivision with 0 for error, 17 udims

1 subdivision with 0 for error, 17 udims

2 subdivisions with 0 for error, 17 udims

2 subdivisions with 0 for error, 17 udims

3 subdivisions with 0 for error, 17 udims

3 subdivisions with 0 for error, 17 udims

4 subdivisions with 0 for error, 17 udims

4 subdivisions with 0 for error, 17 udims

5 subdivisions with 0 for error, 17 udims5 subdivisions with 0 for error, 17 udims

1 subdivisions with 0 for error, 1 udim1 subdivision with 0 for error, 1 udim2 subdivisions with 0 for error, 1 udim2 subdivisions with 0 for error, 1 udim

3 subdivisions with 0 for error, 1 udim

3 subdivisions with 0 for error, 1 udim

4 subdivisions with 0 for error, 1 udim

4 subdivisions with 0 for error, 1 udim5 subdivisions with 0 for error, 1 udim5 subdivisions with 0 for error, 1 udim

1 subdivision with 1.1 for error, 17 udims

1 subdivision with 1.1 for error, 17 udims

2 subdivisions with 1.1 for error, 17 udims2 subdivisions with 1.1 for error, 17 udims

3 subdivisions with 1.1 for error, 17 udims

3 subdivisions with 1.1 for error, 17 udims

4 subdivisions with 1.1 for error, 17 udims

4 subdivisions with 1.1 for error, 17 udims

5 subdivisions with 1.1 for error, 17 udims

5 subdivisions with 1.1 for error, 17 udims

1 subdivision with 1.1 for error, 1 udim

1 subdivision with 1.1 for error, 1 udim2 subdivisions with 1.1 for error, 1 udim2 subdivisions with 1.1 for error, 1 udim

3 subdivisions with 1.1 for error, 1 udim

3 subdivisions with 1.1 for error, 1 udim

4 subdivisions with 1.1 for error, 1 udim

4 subdivisions with 1.1 for error, 1 udim

5 subdivisions with 1.1 for error, 1 udim

5 subdivisions with 1.1 for error, 1 udim

Sorry for posting so many pictures but I thought it would be best to do a lot of wedge tests to try to test variables that effect this banding artifact.

Thanks again,

-Travis

[tsmithBN2CR]

Hi Lee, 

Just wanted to check whether or not you were able to access the zip with the creature render mesh? I sent a private message with the password.

Thanks again for your help with this,

-Travis

[lee_griggs]

Sorry for the delay. We are looking further into this. Here I have rendered your scene without subdivision and with catclark subdivisions: 9 and adaptive_error: 1.1. 

On closer inspection the banding is apparent.

 

  

[tsmithBN2CR]

Thankyou Lee, I have seen this banding effect in studio production context's before but usually the camera is so far away it is hard to notice, especially after motion blur, etc.  And I think displacement for reptile/dragon/dinosaur scales seem to be especially problematic (skin not as much, maybe because the height variation is much less?).

[tsmithBN2CR]

Hi Lee,

You mentioned that people were looking into the issue. Just wanted to check if there were any discoveries, and if it will be addressed in future versions of Arnold (or if it already has?).

And sorry to bump an old thread, work and life got very busy the past few months and did not have a chance to follow up until now. About to start up on the personal project again now that I have a bit more free time.

Thanks again,

-Travis

[thiago.ize]

Hi, I wonder if maybe this was fixed in Arnold core 7.2.5.2? From the release notes (https://help.autodesk.com/view/ARNOL/ENU/?guid=arnold_core_7252_html) it might be this fix :

• ARNOLD-14644 - Autobump goes away at extreme magnification

which maybe could be the issue you were having?

[tsmithBN2CR]

Hi! Thankyou so much for bringing this to my attention. Will post screenshots tomorrow but I tried Maya 2025 with Arnold 7.3.0.0 MoTa 5.4.0 and I still see the banding. It does actually seem like autobump of 'banding' on or off, so maybe related but didnt do the trick in this case.

Thanks again.