PBR - how to supress arealights in reflections

[sanostol]

I have a pbr render lit wiht a environmentlight and a hdri as map, and added a arealight to create some more accentuated shadows. unfortunately the arealight shows up in the reflection, is there a way to hide it in reflections?

thanks

Martin

[brianburke]

If you uncheck "Specular Contribution" on your light it won't show in the refls.

[sanostol]

unfortunately pbr does not respect this. with area lights it does not work

If you uncheck "Specular Contribution" on your light it won't show in the refls.

[sanostol]

it seems that as soon as You use slightly blurred reflections the uglyness appears, even when no arealights.

the strange thing is that it happens on some imported geometry. when I place another geometry at the same place roughly with the same orientation it does not show this ugly white highlight. mh, very strange

Edited April 25, 2010 by sanostol

[stelvis]

I've come across the same issue recently and something doesn't seem right to me here in terms of how specular/glossy path tracing in PBR seems to be summing area light contributions

eg if I have a surface with a glossy BSDF and a diffuse BSDF summed (so that their specular and diffuse responses are roughly equal)

if I shine an area light at an object using that surface then the specular hit I get seems totally out of proportion to the diffuse response - and I don't mean the expected intensity difference due to how widely the light is scattered between the two BSDF's - I would expect the diffuse to be less intense but the spec hit seems off the scale

ie: If my light has an intensity of 1 with no falloff surely a reflected specular hit shouldn't be 10 * brighter than the light source itself???

that doesn't seem at ALL physcially correct to me - in real life reflections are not usually more intense than the primary light source

if I use an environment map (say applied via an emissive shader to an inverted sphere so it shows up in both reflections and indirect 'diffuse' pathtracing) that seems to be behave much more how I would expect in that the 'glossy' specular response seems much more balanced to the indirect diffuse response using exactly the same shader - ditto for simpler emissive objects (geometry with a simple constant emissive shader like glow)

given theres no way to isolate the contributions to diffuse path tracing from glossy path tracing on the light itself it seems theres no easy way to hack ones way out of this either

I did find turning glossy bounces to 0 in the PBR ROP options killed the area light spec hit completely whilst still allowing 'normal' reflections from geometry (that gets controlled by specular bounces) - however that just made me realise that I really don't understand why there are three separate bounce controls in the PBR panel - ie I thought they were all 'just rays' and PBR couldn't differentiate between them?

and whats the difference between 'gloss' and 'specular/reflection' in PBR anyway? from my admittedly limited twiddling so far it looks like 'gloss' = direct specular from light sources only ?

final rant - why isn't there a custom PBR version of the lighting model VOP? - I eventually found out how the 'normal' lighting model is mapping the usual mantra params to (some of) the underlying BSDF functions when that VOP gets used in a PBR context, but only by trawling through the actual VOP function descriptions in the VEX header files - ie its not at all obvious how this is happening from using the interface which is still using params that really only make sense in a non-PBR context, and many of the BSDF's themselves are apparently not accessible in VOPs at all without rolling your own code...

[DaJuice]

Wondered the same thing a while back. http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=13944&highlight=reflections

The short of it is, you have to add the Color Limit parameter to mantra and lower the value. The help files warn of lower "accuracy" and dimmed lighting but in practice I haven't seen any of that. The default value is 1024. I set mine to a default of 100 and go from there.

[Fabiano Berlim]

Wondered the same thing a while back. http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=13944&highlight=reflections

The short of it is, you have to add the Color Limit parameter to mantra and lower the value. The help files warn of lower "accuracy" and dimmed lighting but in practice I haven't seen any of that. The default value is 1024. I set mine to a default of 100 and go from there.

Yes DaJuice, you are right.

A tip for those who may find problems with render: It's kinda boring to search but you will find almost all the answers in here http://www.sidefx.com/docs/houdini10.0/props/mantra10_0

'Color Limit'

Houdini name vm_colorlimit

IFD name image:colorlimit

Default (1000)

When performing shading, mantra places no limits on values which may be returned. However, when performing Physically Based Rendering, it’s possible to get very large values for some rays. These extrema will show cause color spikes which cannot be smoothed out without sending huge numbers of rays. The color limit is used to clamp the value of the Cf variable to avoid these spikes.

Cheers

[stelvis]

Yes DaJuice, you are right.

A tip for those who may find problems with render: It's kinda boring to search but you will find almost all the answers in here http://www.sidefx.com/docs/houdini10.0/props/mantra10_0

'Color Limit'

Houdini name vm_colorlimit

IFD name image:colorlimit

Default (1000)

When performing shading, mantra places no limits on values which may be returned. However, when performing Physically Based Rendering, it’s possible to get very large values for some rays. These extrema will show cause color spikes which cannot be smoothed out without sending huge numbers of rays. The color limit is used to clamp the value of the Cf variable to avoid these spikes.

Cheers

the problem with that is that it just clamps dynamic range AFAIK

we were discussing this in the studio the other day - I'm guessing the current BSDF's like phong and blinn just don't have an especially realistic response in that as you push roughness lower and lower towards what you might consider a 'mirror' reflection (it won't ever get there) the actual function is exponentially increasing returned light intensity along the angle of refelection (ie as the 'specular lobe' gets smaller, it gets exponentially stronger).

I 'm not sure that either of these functions are really 'energy conservative' in that they actually return realistic energies back to the eye point - i could be wrong - the puzzling thing is that emission from other geometry seems to be handled much more 'realistically', but I suspect thats due to the fact that in the case of indirect lighting (which would include the effect of emissive surfaces) the BSDF is solely responsible for determining the biasing on the path tracing - ie its not computing light intensity at all as it is with light sources, but just shaping the spread of rays used to determine whats sampled in the environment then those rays are simply averaged to get the reflected colour - that could be just as unrealistic physically, but it 'feels' right in terms of the results it produces to my 'artistic' brain

I guess my assumption was that an area light would behave the same way as an emissive object of the same brightness (ie area light intensity equates to the RGB values of cE) but that isn't at all whats happening

[Jason]

A lot of this is really confusing and frustrating in 10.0 due to many of the PBR limitations; but I think if you're patient and wait for a short while till 11.0 arrives, I believe many of these issues might be relieved in some way or other.

Keep the faith!

[stelvis]

A lot of this is really confusing and frustrating in 10.0 due to many of the PBR limitations; but I think if you're patient and wait for a short while till 11.0 arrives, I believe many of these issues might be relieved in some way or other.

Keep the faith!

didn't mean to sound like I as moaning - I'm just trying to get my head around what it actually does

IMHO part of the problem is that its called "physically based rendering" , which sort of sets up some expectations that its fundamentally more physically correct in how its treating illumination

I don't think it really is though - as far as I can tell its really a combination of a different, more 'efficient' sampling framework and a clever idea about how to use BSDF's to shape that sampling, but apart from that it doesn't fundamentally treat lights or indeed indirect reflections really any differently from non-PBR - it just samples them differently, and allows one to use the same function (or combination of functions) to shape both direct and indirect lighting without actually changing anything about how the illumination from either is actually computed at a low level

there is definitely some mileage in terms of being able to work with BSDF functions directly, and I'm quite interested in seeing what advantages that might bring - the frustration is more to do with the lack of documentation about what its actually doing and VOP level support for stuff that doesn't hide the PBR side of things away from the user which means a lot of guessing and making assumptions that may be incorrect

anyway I guess I need to take a closer look at H11 at this point if its changing radically

[stelvis]

did a few experiments today comparing indirect lighting of emmissive objects and direct light source (both area lights and environment lights) - rather than hijack the OP thread further, I've started a new one