Stopped getting custom values from BSDFs

[Frollo24]

Hi! Recently I posted a issue asking how to get some custom values (metallic, roughness...) of a principled BSDF in order to create a custom G-buffer, and with the release of Mitsuba 3.4 I was finally able to get those values. However, when doing some testing suddenly the code stopped working. Here's the custom integrator I've been using so far:

class Metallic(mi.SamplingIntegrator):
    def __init__(self, props):
        mi.SamplingIntegrator.__init__(self, props)

    def sample(self, scene: mi.Scene, sampler, ray: mi.RayDifferential3f, medium: mi.Medium = None,
               active: bool = True) -> Tuple[mi.Color3f, bool, List[float]]:
        si = scene.ray_intersect(ray=ray, active=active)
        bsdf = si.bsdf(ray)
        col_eval = bsdf.eval_attribute('metallic', si=si, active=active)

        valid = si.is_valid()
        color = dr.select(valid, col_eval, mi.Color3f(0.0, 0.0, 0.0))

        return color, valid, [dr.select(valid, 1.0, 0.0)]

    def aov_names(self) -> List[str]:
        return ['metallic.M']

    def to_string(self) -> str:
        return 'MetallicIntegrator[]'

Is there anything wrong with this code? (Including misconceptions or bad habits)

[njroussel]

Hi @Frollo24

This all looks fine.

I don't get this part of your message:

with the release of Mitsuba 3.4 I was finally able to get those values. However, when doing some testing suddenly the code stopped working

So this exact integrator was working once the release was done, but over the past weeks it "stopped"? What does "stopped" mean? Does it return random values? Zeroes?

[Frollo24]

Thanks for the response. Yeah, I didn't express myself very well with that sentence. What I meant was the integrator suddenly started outputting zeroes whenever an intersection was found.

[njroussel]

That's surprising. Everything points to something in your specific script that changed unexpetedly. My recommendation would be to trace a single ray with your integrator and see that sample() does indeed behave as expected. You can easily do it in a tiny scene with just a sphere centered in 0 and then you just need to build a ray that points at it.

If even that doesn't work, I can take a look at full reproducer.

[Frollo24]

Okey, I saw my error, that's because I was using a normalmap BSDF which had a principled BSDF plugin. Given that case, which is the best way to get the normalmap sampled along with custom values of a principled BSDF?

Thanks in advance!

[njroussel]

Unfortunately, this is not supported currently

It wouldn't take much work to properly support it though. This is where all of this logic happens. Basically we would need an extra case in put_object to run the callback on the nested object too.

Something like this might be enough:

diff --git a/src/render/bsdf.cpp b/src/render/bsdf.cpp
index d03c6769..bac64118 100644
--- a/src/render/bsdf.cpp
+++ b/src/render/bsdf.cpp
@@ -55,6 +55,8 @@ struct AttributeCallback : public TraversalCallback {
                 result = func_object(texture);
                 found = true;
             }
+        } else {
+            obj->traverse(this);
         }
     };

I'd welcome a PR for this change if you want to look into yourself. We have no immediate use for it so it is rather low on our priority list if we were to look into this properly ourselves.

[Frollo24]

Thanks for your response. In case I made a PR with that enhancement, how long would it take until it will be available on PyPI so that I can use it without a custom build?

Thanks in advance again.

[njroussel]

Hard to say. We don't have a fixed release schedule.

We do currenlty plan on having a small patch release in the next couple of weeks. This could fit into it.

[Frollo24]

Thanks a lot! I will make a PR on the following days, hope it helps!