No attenuation for portals lights

Category:feature request

Portal lights is a feature mainly intended to focus background photons emission. Correct me if I am wrong but background lighting uses no attenuation for light decay when sampled for the direct lighting component, while when a portal light is sampled for direct lighting, it behaves like a normal area light so inverse square (quadratic) attenuation is used. The result is that portals don't really behave like a background lighting substitute which is its not the intended purpose. While background lighting produces constant shading regardless of the surface location, anything close to the portal light will become overexposed.

The feature request is to allow for no attenuation in portal light direct lighting sampling component and photon emission to first bounce segment in diffuse and caustic maps, at least as an option, so it really behaves like a background lighting substitute. Correct light decay management is very important for render engines to get good results.

There are other issues with portals, for instance when sampled for direct lighting, although they might have no decay, they will eventually produce soft shadows according to its actual size and not according to the background 'size' they are supplanting, but I don't know whether there is an easy solution for that.



Direct lighting sampled from the background. Because of the correct decay, there are just two zones or EV stops between the middle grey everything is using (808080) and the white wall on the right (B3B3B3), which is a realistic asumption if we compare it to how digital cameras work, for instance.

Direct lighting sampled from a portal light which is supposed to be supplanting direct lighting produced by the background, using portal light power=1 since this value is in fact just a background power multiplicator. Notice how the supposedly white wall is now grey because of the incorrect decay and we would need to increase brightness of the wall another zone or EV stop (CCCCCC) to make it look white, which would break any realism.

All tested with the new color pipeline in place.


Finally, there is one last issue with portals, which is the fact that portal power setting work in fact as a background power multiplicator, but it does not control background exposure when portal power is other than 1. However, controlling background exposure with portal power would conflict with other GI methods than photon mapping, so maybe it should be as it is now.

These issues are to be expected from portals, which are helpful for photon mapping but could be the source of all kind of issues once human input is allowed to control which is supposed to be phisically based light emisions.


Status:active» needs review


I'm not sure I understand... I've prepared a simple test scene (attached) and tested without portal and with portal (power 0 and power 1) and I cannot see obvious differences in decay... maybe I'm missing something?

Just try the attached scene with Plane_portal enabled or disabled for Blender rendering and try different power values too. Please let me know how can I replicate this problem.





portal_atenuation.blend 502.39 KB


Correct me if I am wrong but portal light Power setting is in fact just a background power multiplier. If you change background power setting then portal light power changes too even if background Use IBL checkbox is disabled. In order to compare direct lighting attenuation between a background and a portal light, the later should use Power=1 so in fact it uses whatever power setting the background is using. Also when making the comparison:

  • Use Direct Lighting mode.
  • Portal is disabled (in a disabled layer) when the background lighting render is done (Use IBL checkbox enabled).
  • Background lighting is disabled (Use IBL checkbox disabled) when the render is done with the portal light layer enabled.

Doing the comparison this way, in one case only the background is sampled for direct lighting and in the other case, only the portal light is sampled for direct lighting. The feature request is that in either case, the same result is produced assuming the portal may use the same attenuation model than the background. I guess you can also check the code to confirm whether portal light is in fact using the same attenuation model (inverse square) than regular arealights.

Background lighting is not supposed to use attenuation because is hypothetically so far away and powerful that the attenuation factor is negligible when light reachs any object. The same happens for instance with sun lights models. Changing to a non-attenuation model for portal lights means that they should behave like a background or a sun light when sampled for direct lighting, when shooting photons or when sampled by path tracing algoritms.

I hope you can follow my reasoning. I have enclosed a test scene and the results, which illustrates what I mean. Rendered with YafaRay 1.0.0

AttachmentSize 753.93 KB




Just to keep you updated, I'm investigating this and it's really difficult. The sampling from the background light and the sampling from the portal light are totally different! It's not only a matter of square of distance, pretty much everything is different in the way they sample and calculate light.


I will keep investigating this, but it's not going to be solved in the short term...


Status:needs review» active


no problem David, thanks.


Status:active» postponed

Not sure what to do about this... postponing for now.