Issues with DiffuseAreaLights and Meshes

[e-ulff]

I have been working on extending pbrt to render infrared images, and since almost everything can be considered an emitter in infrared, ive been looking into the DiffuseAreaLights.

Currently, each instance of DiffuseAreaLights has it's own copy of an Image (as mentioned in #183). This leads to loading being insanely slow and memory exploding if one tries to create a mesh light with an associated image for emission, since each triangle has to load and store it's own image. This is quite easily fixed by simply using Image* instead and only loading each image once.

If this is something that would be deemed usefull for the code i can happily create a pull request.

But looking at the function DiffuseAreaLight::Bounds() which computes the power of the light, we see that the current sampling wouldn't work for models that have emissive textures and are uv mapped. So maybe the "fix" i stated earlier is of no interest with the current light samplers? Would improving the DiffuseAreaLight::Bounds() to work for uv mapped shapes be of interest, or would this be considered to far away what is currently described in the book? And if it is of interest, does anyone have any ideas for how one would go about computing this power? (Maybe monte carlo?)

Any thoughts on the matter would be very appreciated, sorry if my writing was hard to follow.

[pbrt4bounty]

Hi.. I noticed this issue here too. To 'solve it', I added a limitation on scene creation time, that prevent to use complex textured geometry for mesh lights.. It's partial solution that don't work in your use case

[e-ulff]

@pbrt4bounty If you are interested in a more "correct" solution you can check out my commit here 3833617. I added some simple image caching kinda like how its done for normal maps which can speed up the loading times a lot.

However if you are using the BVH light sampler you will still get long start up times since in DiffuseAreaLight::Bounds() it has to compute the average of each image for each shape, this could also be cached but since it doesnt create accurate bounds for many cases it's probably not of interest to fix what already doesn't work.

[pbrt4bounty]

I tested your code here and the time for a not very complex mesh are improved from 1:47 minutes to 0:53 minutes but, still very far to the render time with not textured mesh: 00:04 minutes :(

[e-ulff]

@pbrt4bounty which light sampler are you using? As i mentioned in my previous comment, if you are using the BVH light sampler most of the time spent loading is likely caused by DiffuseAreaLight::Bounds() which has to iterate over the entire texture for each vertex.

Try using the uniform light sampler, this should make the loading time close to the case without texture!

[pbrt4bounty]

You are right.. 00:04 minutes !!

[pbrt4bounty]

Yes.. the benefit for 'Uniform' light sampler is huge so, with you permission, I want to add this code to my fork :)

[e-ulff]

@pbrt4bounty Of course, go ahead :)

[blue-apparition]

extending pbrt to render infrared images

infrared? You know that the core physics assumption of pbrt is that the wavelength is negligibly small (aka geometrical optics)? With a finite wavelength you get the scalar (aka fourier) optics theory with its famous diffraction, interference, etc effects.

Did you already "extend" the rendering equation to the scalar case?

[e-ulff]

@blue-apparition Im assuming geometrical optics, the wavelength of long wave infrared is still much smaller than the objects im concerned with.