Obtaining sensor readings without rendering the entire scene?

[mohanamisra]

For my use case, I need to get the sensor readings for a particular scene configuration, but for multiple scene configurations (6000+). Rendering the entire scene 6000 times even with a low spp value of 8 seems takes unrealistically long.

Is there any way I can get the sensor readings without rendering the entire scene?

My entire simulation project is currently using Mitsuba 3.0, if there are alternatives/plugins that I should look into for this particular issue with obtaining sensor readings, I'd be open to that as well.

[merlinND]

Hello @mohanamisra,

By "without rendering the entire scene", do you mean "rendering only a crop of the image", or "rendering only a subset of the geometry present in the scene"?

In any case, it should be possible to speed up rendering by:

1. Rendering on the GPU if not doing it already
2. Using the mi.traverse() API to modify the scene, rather than loading a separate scene each time
3. Using the new @dr.freeze feature from the latest Mitsuba / DrJit version to reduce overhead: https://drjit.readthedocs.io/en/v1.1.0/freeze.html

[mohanamisra]

@merlinND I'll look into dr.freeze feature, thanks !

I only require the irradiance sensor readings and nothing else. For that purpose, any "partial" (or none at all) rendering that is required, I would be more than fine with that!

However, the sensor reading would be a function of the entire scene because the light bouncing off of shapes would affect it.

[merlinND]

However, the sensor reading would be a function of the entire scene because the light bouncing off of shapes would affect it.

Yes, exactly, even though there will only be a single sensor reading, I think that you still need to account for the whole scene to get fully correct results. In that sense, I don't think that "partial rendering" is possible.
However I would encourage you to profile the code in order to find the bottlenecks, sometimes some small changes can make huge differences. If the bottleneck currently is tracing / kernel generation rather than actual GPU work, then @dr.freeze can make things much faster.

[mohanamisra]

Could you please elaborate on how to identify if the bottleneck is tracing / kernel generation?

Regardless, I will definitely be running the code on a GPU moving forward.

[merlinND]

An easy way would be to profile your script with NSight Systems and check the total run time vs the run time of CUDA kernels. If there are large gaps between kernels, then @dr.freeze may be able to eliminate those.