Point light attenuation/falloff does not work when cast_shadows is enabled

[azeey]

Environment

• OS Version: Ubuntu 20.04
• Source or binary build? source, ign-rendering6, f043b4fc
• Render Engine: ogre2

Description

• Expected behavior: Point light attenuation/falloff to work regardless of cast_shadows.
• Actual behavior: When cast_shadow is enabled, the light does not falloff according to the attenuation parameters. For example, given the following light source

  <light type="point" name="mylight">
  <cast_shadows>true</cast_shadows>
  <pose>0 0 2.5 0 0 0</pose>
  <diffuse>0.8 0.8 0.8 1</diffuse>
  <specular>0.8 0.8 0.8 1</specular>
  <direction>0 0 -1</direction>
  <intensity>2</intensity>
  <attenuation>
  <range>4</range>
  <linear>0.5</linear>
  <constant>0.2</constant>
  <quadratic>0.01</quadratic>
  </attenuation>
  </light>

with cast_shadows = true, I get a sharp circle determined by the range (4m) of the light.

with cast_shadows = false, the light falls of smoothly, but the box does not have a shadow.

Steps to reproduce

1. Run the attached file (test.sdf.txt) in ign gazebo.
2. Change <cast_shadows> to true or false.

[darksylinc]

This may actually be a different (but related) error.

Without cast_shadows

When cast_shadows is disabled Forward+ (from now on F+) algorithm is used by the lighting system. Very big lights can cause severe performance degradation; but small lights usually end up cut "abruptly".

Lights theoretically travel through infinity, so any radius that limits is range is going to be arbitrary. Using Light::setAttenuationBasedOnRadius helps cutting the arbitrariness by providing a minimum luminance threshold (i.e. pretend the light cuts off once % of luminance is reached) but it still gives you less flexibility.

As a hack/workaround, ForwardPlusBase::setFadeAttenuationRange is enabled by default; which will smoothly attenuate when getting close to the light's radius; regardless of PBR parameters of physical attenuation.

TL;DR The light's attenuation settings are honoured, but an extra (much more aggressive) fade is applied on top unless ForwardPlusBase::setFadeAttenuationRange( false ) is called.

The range is not part of the attenuation equation. but setFadeAttenuationRange( true ) (the default setting) hacks it on top to be considered.

With cast_shadows

When cast_shadows is enabled, regular Forward is used (without the +). Because in this case light's size has no direct impact on performance; we don't use the hack; and the light's attenuation settings are honoured without any hacks.

The range is not part of the attenuation equation.

Solution?

That will depend on the intention. The physically correct solution is to call setFadeAttenuationRange( false ) and either use a very aggressive attenuation or a very large radius to avoid blockiness-like artifacts (light curring suddenly)

Other solutions is to just be aware of this and tweak the attenuation until they both agree.

[jrutgeer]

Expected behavior: Point light attenuation/falloff to work regardless of cast_shadows.

I can confirm that is is not only related to point lights: spot light shows the same behaviour (left with, right without shadow):