better volumes (minor but important fixes)

[Alessandro Padovani]

I have to thank TheKD of the daz forum that pointed this out. It seems there are some PAs that don't get the uber shader entirely. So they publish assets with non-sense materials. One example is using volumetric properties with transmapped hair. In this case iray just ignores the volumetric properties so we can do the same.

# if there's an alpha map then it's a surface and volume is ignored
if cutout opacity <> 1 or there's an opacity map
    ignore volumetric properties (same as thin walled on)

‌

Also there's a bug in the volumetric conversion. That is, with some more tests I found that if the sss and transmitted colors are the same then it's the transmitted color that gets inverted instead of the sss color. I didn't get this before since I never tested with the same colors.

# if there's transmission then use volume absorption
if transmitted color <> black/white
    use volume absorption
    color = transmitted color
    if sss color == transmitted color
        color = invert(transmitted color)
    density = 200 / transmitted distance

# if there's sss then use volume scatter
if chromatic sss color <> black/white
    use volume scatter
    color = invert(sss color)
    if sss color == transmitted color
        color = sss color
    density = 100 / scattering distance
    anisotropy = sss direction

Below an example first iray then cycles. It's a translucent sphere with a cube inside that I used to test the cutout opacity and the equations above. Scene included.

‌

‌

[Alessandro Padovani]

Issue #28 was marked as a duplicate of this issue.

[Thomas Larsson]

Implemented in latest commit, I think. You attached the json file rather than the duf file, so I could not check with exactly the same data. And I must say that switching transmitted and sss if they happen to be equal is really counterintuitive.

[Alessandro Padovani]

Commit 4638365 seems to always invert the scatter color, both with same and different colors for sss and transmission. I agree it’s weird to switch the color inversion. The correct duf file is attached now.

Also I tried to look at the commit code but I didn’t get much. Please note that the color inversion only happens in chromatic mode. If it’s mono then there’s no sss color to compare with.

[Thomas Larsson]

The problem is that the colors are not quite equal. In the duf file,

Transmitted color = [ 0.9769546, 0, 0.5019608 ]
SSS color = [ 0.9769546, 0, 0.5024597 ]

After srgb correction,
Transmitted color = (0.9500, 0.0000, 0.2195)
SSS color = (0.9500, 0.0000, 0.2200)

So the distance between them = 0.005. In the last commit, two colors are considered equal if the distance is some small number, arbitrarily set to 0.002. This covers this case, but may fail at times.

[Alessandro Padovani]

It’s my fault because I didn’t check for them to be exactly the same. But this way we got lucky and fixed another issue that’s the inversion switch happens even if the colors are similar. I feel commit c3ab5bb is fine, also because I guess it will be rare for the daz characters to use the same color for sss and transmission. So we have some coverage for this case too.

Then it’s a little weird how this color inversion happens. But I still remember when we didn’t have any clue at all about the chromatic mode and this is so much progress anyway. Marking as resolved.

[Thomas Larsson]

I really don’t like that there is a discontinuity. Are you sure that the inversion doesn’t happen in other cases too, e.g. when both transmitted and sss colors are neither black nor white?

[Alessandro Padovani]

I don’t like it too. No I’m not sure but it wouldn’t make sense at all if the inversion was random. I tested a fair range of possibilities and actual characters and it seems to work fine as it is. Then handling the issue with similar colors is a bonus in my opinion, since I doubt it will be a common case. Honestly my feeling is that the uber shader may be buggy in the volumetric section, at least with the chromatic mode.

As I see it we’re trying to match iray in practical cases though, to convert daz characters and scenes. And I wouldn’t dig too much unless necessary.

[Alessandro Padovani]

Ok I believe I got it. I’m sorry for the confusion but this was really hard.

In my tests I avoided on purpose colors having 0 or 1 in any chromatic channel. That’s because I know that for example (1,1,1) is considered absolute white by iray and is to be avoided as a color because it’s considered “not realistic”. As a consequence 0 or 1 in any channel means absolute value of that channel. Then if we avoid 0 and 1 in any channel the original equations in #24 work fine and we don’t need any inversion switch between the absorption and scatter colors.

Now with more tests it seems the issue arises when the green channel is 0. In either the transmitted or sss color. So it’s not when the colors are equal or similar. It’s when the green channel is zero. Below an example in iray where the green channel goes from 0.001 to 0 and triggers the inversion switch.

Personally I feel this is a bug in the chromatic mode since it doesn’t make much sense.

‌

[Alessandro Padovani]

Commit 350cb20 works as intended. The issue is weird but at least we have some coverage for it. Marking as resolved.

[Alessandro Padovani]

update. The fix for the chromatic mode has been removed in #697 commit 7fc95b4 because it doesn’t work fine anyway.