Regression: Alpha/transparency not working correctly with intersecting mesh in Cycles #96537

New Issue

Mustard · 2022-03-16T21:47:44+01:00

Mustard commented

2022-03-16 21:47:44 +01:00

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.23

Blender Version
Broken: version: 3.1.0, branch: master, commit date: 2022-03-08 18:16, hash: c77597cd0e
Worked: 3.0.1

Caused by 74afc86d4b

Short description of error
Alpha/transparency in Cycles seems not to be handled correctly when there are intersecting mesh.
I am not sure if the mesh of the attached .blend is particularly complex, but it was working correctly in Blender 3.0.1.

Exact steps for others to reproduce the error
You can reproduce the uncorrect transparency (as in the image) in the attached file, just start rendering with Cycles. It happens both in viewport and render, and both with CPU and GPU.
Even if the number of transparency bounces is big, and the shader is only a transparency node, the transpancy seems not to work as expected.

hair.blend

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.23 **Blender Version** Broken: version: 3.1.0, branch: master, commit date: 2022-03-08 18:16, hash: `c77597cd0e` Worked: 3.0.1 Caused by 74afc86d4b **Short description of error** Alpha/transparency in Cycles seems not to be handled correctly when there are intersecting mesh. I am not sure if the mesh of the attached .blend is particularly complex, but it was working correctly in Blender 3.0.1. **Exact steps for others to reproduce the error** You can reproduce the uncorrect transparency (as in the image) in the attached file, just start rendering with Cycles. It happens both in viewport and render, and both with CPU and GPU. Even if the number of transparency bounces is big, and the shader is only a transparency node, the transpancy seems not to work as expected. ![hair.PNG](https://archive.blender.org/developer/F12930575/hair.PNG) [hair.blend](https://archive.blender.org/developer/F12930587/hair.blend)

Mustard commented

2022-03-16 21:47:44 +01:00

Added subscriber: @Mustard

Mustard changed title from ~~Alpha/transparency not working correctly with intersecting mesh~~ to Alpha/transparency not working correctly with intersecting mesh in Cycles

2022-03-16 21:58:08 +01:00

Richard Antalik commented

2022-03-17 01:52:55 +01:00

Added subscriber: @iss

Richard Antalik commented

2022-03-17 01:52:55 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Richard Antalik commented

2022-03-17 01:52:55 +01:00

It is quite dense mesh, but seems to be a regression from what I can see.

lictex_ commented

2022-03-17 05:06:02 +01:00

Added subscriber: @lictex_1

Mustard commented

2022-03-17 19:56:20 +01:00

In #96537#1324400, @iss wrote:
It is quite dense mesh, but seems to be a regression from what I can see.

Exactly, it was working correctly in 3.0.1.
The issue obviously remains when you put a texture with alpha channel, with bad render results with this mesh in Cycles.

> In #96537#1324400, @iss wrote: > It is quite dense mesh, but seems to be a regression from what I can see. Exactly, it was working correctly in 3.0.1. The issue obviously remains when you put a texture with alpha channel, with bad render results with this mesh in Cycles. ![unknown.png](https://archive.blender.org/developer/F12932173/unknown.png)

Philipp Oeser commented

2022-04-19 12:01:29 +02:00

Added subscribers: @leesonw, @brecht, @lichtwerk

Philipp Oeser commented

2022-04-19 12:01:29 +02:00

Caused by 74afc86d4b
#96816 (Hair cards with alpha texture map produce weird black color under cycles.) is probably a duplicate.

Not sure how this can actually be avoided in this usecase here now?

Maybe @brecht and/or @leesonw could comment?

This might very well be the new limitation, but will set to High prio for now.

Caused by 74afc86d4b #96816 (Hair cards with alpha texture map produce weird black color under cycles.) is probably a duplicate. Not sure how this can actually be avoided in this usecase here now? Maybe @brecht and/or @leesonw could comment? This might very well be the new limitation, but will set to High prio for now.

Philipp Oeser changed title from ~~Alpha/transparency not working correctly with intersecting mesh in Cycles~~ to Regression: Alpha/transparency not working correctly with intersecting mesh in Cycles

2022-04-19 12:01:57 +02:00

William Leeson commented

2022-04-19 23:55:51 +02:00

I took a quick look and it seems that there are many polygons intersecting which is causing the ray to hit objects in the same space and thus never move on. The obvious fix is to add offsetting back to transparency see #97459 and it appears to work but this adds the offsetting issues back in :-). I guess the more robust solution would be to be able to hold more than one id at a hit point so that all object intersecting in the same area could be skipped but that might be slow. Maybe when multiple hits at the same location are found offsetting could be used.

Brecht Van Lommel commented

2022-04-21 17:05:53 +02:00

Adding offsetting specifically for transparent bounces probably would not make things worse than before 3.1? We may skip over some surfaces unnecessarily but it's not obvious the ray offsetting changes helped much with that specific problem.

A more robust solution may be tracking ray start and end distance for transparent rays, rather than moving the ray start position forward. Then we can more easily ensure the ray is always moving forward, by ensuring the start distance increases. Potentially we could even ensure all intersections are found in a consistent order by allowing hits at the same distance as long as the primitive ID is higher than the previous hit. This is a more complicated fix so we may just do simple offsetting to solve the immediate problem, but it would be interesting to try.

Recording multiple intersections would also help, but increased GPU memory usage and reduced performance are bigger concerns for that approach.

Adding offsetting specifically for transparent bounces probably would not make things worse than before 3.1? We may skip over some surfaces unnecessarily but it's not obvious the ray offsetting changes helped much with that specific problem. A more robust solution may be tracking ray start and end distance for transparent rays, rather than moving the ray start position forward. Then we can more easily ensure the ray is always moving forward, by ensuring the start distance increases. Potentially we could even ensure all intersections are found in a consistent order by allowing hits at the same distance as long as the primitive ID is higher than the previous hit. This is a more complicated fix so we may just do simple offsetting to solve the immediate problem, but it would be interesting to try. Recording multiple intersections would also help, but increased GPU memory usage and reduced performance are bigger concerns for that approach.

William Leeson commented

2022-04-21 22:04:02 +02:00

Yes I have done a more accurate version of offsetting but I still don't really like the offsetting approach. So, then like you mentioned I decided to try sorting them based on prim id. I don't think it is going to be much slower but it is not quite there yet so I'll give that a go first and see where I get.

Brecht Van Lommel commented

2022-05-17 21:18:51 +02:00

@leesonw, are you still actively working on this?

Ideally we'd have a solution by bcon4 (June 1), if you don't have time I might try implementing something.

@leesonw, are you still actively working on this? Ideally we'd have a solution by bcon4 (June 1), if you don't have time I might try implementing something.

William Leeson commented

2022-05-17 22:24:15 +02:00

@brecht I doubt I will have time before June so feel free to take over.