Sharp bright/dark split line in BTF rendering

[colinzhenli]

Hi, thank you for releasing this plugin.

In rendering examples like this, I noticed a sharp split line between the bright and dark regions in the rendered BTF results. From a physical perspective, I would expect this transition to be smooth, rather than showing a clear discontinuous boundary.

I am wondering whether this is expected behavior, or whether it may indicate an issue in the rendering setup or the BTF data.

One possible reason I would like to raise is that the cosine falloff at grazing angles for direct illumination may not decrease smoothly to zero. Could this cause the visible bright/dark split line?

Thank you!

[elerac]

Hi @colinzhenli

As you pointed out, the cosine falloff is not applied in this plugin. This omission is intentional.

The BTF is designed to model a wide range of complex optical phenomena from a large set of images, including diffuse/specular reflection, texture/normal/height variations, local shadows/inter-reflections/scattering, and cosine falloff. Therefore, the falloff is expected to be implicitly captured by the measured images rather than explicitly applied in the rendering program.

This assumption is reasonable when the image set provides a sufficiently dense sampling of illumination and viewing directions over a wide angular range. However, the UBO2003 dataset contains only 81x81 illumination/viewing directions, resulting in 6561 images in total. In addition, its polar angles are limited to the range [15°, 75°]. Since the dataset does not include observations at grazing angles, it cannot represent the cosine-falloff attenuation in the entire angular range.

You could obtain a visually smoother transition by extrapolating the BTF with synthetic black images near the falloff region. However, this imposes a cosine-falloff assumption outside the measured angular range, rather than representing actual measured reflectance behavior.

[colinzhenli]

Hi, thank you for the detailed explanation.

The analysis about the limited angular range makes sense. Since UBO2003 only covers polar angles from 15° to 75°, it is understandable that the grazing-angle falloff cannot be fully captured by the measured data.

I have one follow-up question: have you tried the UBO2014 dataset? As far as I know, it has denser angular sampling, with 151 × 151 illumination/viewing directions, and a wider elevation coverage including 0° angles. If you have tested it, did you observe the same sharp bright/dark split-line artifact, or does the transition become smoother with the denser angular coverage?

Thank you!

[elerac]

Yes, I have tried with UBO2014. You can see the corresponding implementation in the previous Mitsuba 2 version. However, I later dropped UBO2014 support when updating this plugin for Mitsuba 3.

The previous version relied on BTF_extractor. Unfortunately, at that time, I was unable to compile its Cython code in my recent Python environment. This issue may be resolved with some additional effort, or in this year, Codex/Claude will do it easily.

The previous version includes several rendered examples, but they were not rendered under the same lighting configuration (a single point light source), so I cannot assess whether the transition behavior is smoother for UBO2014.

A PR that fixes BTF_extractor compatibility and restores UBO2014 support would be very helpful and greatly appreciated.

[colinzhenli]

Hi, thank you for the clarification.

We have successfully compiled BTF_extractor 1.7.0 with Python 3.11 and Mitsuba 3.8.0. When we have time, we can submit a PR to help fix the compatibility issue and restore UBO2014 support.

I also have a related but separate question. Do you know whether the UBO2014 measurements have the cos(theta_L) falloff baked into the data, or whether this factor was divided out during calibration?

I looked into this because Bonn's reference btflib defines a cosine_flag field in the BTF binary header, which seems to record exactly this:

https://github.com/cgbonn/btflib/blob/a9645d520417995603d7e16f38150f599d011e2e/matlab/%40btf/private/read_meta_data.m#L40-L46

After parsing the headers of all UBO2014 cloth .btf files, this flag is 0 for every material. According to the comment in btflib, this should mean that cos(theta_L) is not baked into the data.

However, when I plot empirical BRDF lobes by fixing phi_i and phi_o, sweeping theta_i, and drawing one curve per fixed theta_o, I still observe a clear cosine-like falloff toward grazing incident directions.

So empirically, the data looks like it may contain the cosine falloff, which seems to contradict the cosine_flag = 0 metadata. Do you have any insight into this?

Thanks!

[elerac]

We have successfully compiled BTF_extractor 1.7.0 with Python 3.11 and Mitsuba 3.8.0. When we have time, we can submit a PR to help fix the compatibility issue and restore UBO2014 support.

That's great! Thank you so much!!

For the UBO204 data, that plot is a good visualization. As you noted, the behavior seems to follow a cosine falloff.
I am not entirely sure, but it may also be helpful to plot additional materials and pixels that are likely to exhibit distinctive reflectance behavior, such as shallow subsurface scattering and local shadows.