How to get rid of pixelated shading in iridescence material type?

Anyone know why the iridescence material type does this pixelated look (the metal part on the race track)? Weird thing is it only happens in one direction. HDRP manual is not very helpful, just has a short description on iridescence type and that’s it.

z1czax

There’s only 3 lights in the entire scene: one point light attached to each vehicle (there was me and 1 AI in that videoclip), and a directional light acting as the sun.

When I change the material type to standard, the problem goes away, but the artist wanted this to be iridescent. Hoping to find a solution if possible.

I’m using HDRP 12.1.7, Unity 2021.3.11f1

EDIT: Ok I figured it out (I think). The artist who set up the material set it to use alpha clipping (TransparentCutout). I changed it to the actual transparent surface type and the problem seems to be solved.

EDIT 2: Happened again on another material that this time, didn’t have transparency, so I couldn’t use the same solution as before. Turns out it gets fixed if I set the Coat Mask numerical value to at least 0.018 (doesn’t matter that the Coat Mask texture isn’t assigned). Don’t know why this fixes it.

Hello; thanks for the detailled post.
We’ve had this issue in the past (IIRC it was SSR on an HDRP/Lit material with clear coat > 0) but i checked and it should be fixed in the version you have, so this is why it concerns me. (it has been fixed in 2021.3.7f1).

So I have one question, are you using SSR in your project?
If yes, does disabling SSR also fixes the issue (like setting coat to 0 does) ?

If no, there may be a another issue and the best thing to do would be to report an issue using the bug reporter since I did not managed to repro on my side using latest 2021.3

If I’m guessing correctly, SSR means screen-space reflections, then yes I am using screen-space reflections.

It is not used in that scene, (I have it turned off in the HD Render Pipeline Global Settings > Frame Settings (Default Values) since it is only used in our Main Menu.

It does not get fixed if I turn it off in the HDRP Pipeline Asset file.

I think you misunderstand a little. Setting coat to 0 does not fix the issue. The issue happens when the coat value is < 0.018. I have to set it to at least 0.018 to get rid of it. Setting it to 0.017 does not fix it, for example.

1 Like

So I’ve recreated it in a small scene:

The spheres need a normal map for you to see the bug. Even just a plain flat normal map will do. Giving the spheres a dark color will help you see it better.

The sphere on the lower right (the one exhibiting the bug) uses a material (iridescent material type) with 0 coat. But the ground it’s on (the ground at the right) uses a material (standard material type) with coat at 1.0.

The ground at the left (where the bug doesn’t happen) uses a material with coat set to 0.

The sphere at the lower left uses the same material that has the bug, but since it’s on the ground with coat set to 0, it doesn’t happen there.

The upper left and upper right spheres use a material with coat set to 0.018. For some reason, that makes them “immune” to the bug.

So to recap:
Sphere with 0 coat on ground with 1 coat => pixelation bug
Sphere with 0 coat on ground with 0 coat => no bug
Sphere with 0.018 coat on ground with 1 coat => no bug
Sphere with 0.018 coat on ground with 0 coat => no bug

I don’t know if this is enough for you or if you want me to submit a bug report on it.

Thanks. I managed to repro something similar on multiple versions.

One last thing to check on your side, are your sure your normal map imported as an actual normal map?
Because I can only repro when the normal map is imported as a regular default texture. If the normal is imported correctly, the issue doesn’t repro on my side.

Yes, that’s correct, I checked, and the texture was not marked as a Normal Map. I believe in the old Material Inspector, it will alert you that the normal map you have assigned was not marked as such, but I see no such warning in an HRDP material inspector, so this is probably why the artist working on this made that mistake (I didn’t notice it myself in my small repro project).

1 Like

Hey, it has already been fixed on our side.

You can follow the backports in this link if needed !