POV-Ray

The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Tasklist

FS#46 - area_illuminate in area lights is not taking fade_distance into account

Attached to Project: POV-Ray
Opened by Samuel T. Benge (stbenge) - Friday, 07 August 2009, 20:37 GMT
Last edited by Christoph Lipka (clipka) - Thursday, 21 June 2012, 23:12 GMT
Task Type Unimp. Feature/TODO
Category Backend → Light source
Status Closed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 beta 32
Due in Version 3.70 RC4
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

It seems that the new area_illuminate flag for area lights does not take into account fade_power and fade_distance. The illumination falloff is still being calculated from the center of the light_source.

Here’s some relevant code:

camera{
  location<0,10,-10>
  look_at 0
}
plane{y,0 pigment{rgb 1}}
light_source{
  y*.1,100
  area_light x*10, z*1, 8, 8
  jitter
  area_illumination
  fade_power 2 fade_distance 1
}
This task depends upon

Closed by  Christoph Lipka (clipka)
Thursday, 21 June 2012, 23:12 GMT
Reason for closing:  Fixed
Comment by Christoph Lipka (clipka) - Friday, 14 August 2009, 00:59 GMT

Confirmed. (Took the liberty to re-format the original report for beauty.)

Light fading seems indeed to be computed globally for the whole area light, not each individual “sub-lights”. The question is whether we want to change this, as it will of course cost some performance. I doubt whether it makes much of a difference in typical use cases, so I’d advocate to make this optional somehow.

I’m thinking aloud about whether it could be decided automatically depending on parameters such as the light source’s size and distance to the point under test; but then again, this would require some “fuzzy logic” to avoid artifacts at the distance where the “detailed” algorithm kicks in.

Comment by Samuel T. Benge (stbenge) - Friday, 14 August 2009, 21:21 GMT

Thank you for taking the time to look at this.

I think having each "sub-light" account for distance fading would be a great enhancement for the area_illuminate feature. We could finally model realistic-looking fluorescent lights without having to create a costly array of miniature area_lights. We could also add better-looking fill lights, similar to how I made the indoor aqueduct image in the HOF.

I think light fading for area-illuminating light sources could be off by default, with the option to turn it on via a keyword like so:

area_illuminate fade_on

Something like this would turn on the area_illuminate feature and light fading for it both at once :)

Comment by Juha Nieminen (Warp) - Monday, 22 March 2010, 14:27 GMT

I don't see a reason why taking the fading parameters into account for each "sublight" would make the calculations significantly slower. It's more an oversight than anything else.

Comment by Thorsten Fröhlich (thorsten) - Tuesday, 23 August 2011, 06:41 GMT

What is the status of this?

Comment by Christoph Lipka (clipka) - Friday, 02 December 2011, 17:34 GMT

implemented with change #5572.

Loading...