POV-Ray : Newsgroups : povray.binaries.images : Seeking ancient bug report about shadowless area light Server Time
22 Dec 2024 23:26:50 EST (-0500)
  Seeking ancient bug report about shadowless area light (Message 1 to 2 of 2)  
From: Cousin Ricky
Subject: Seeking ancient bug report about shadowless area light
Date: 12 Jun 2022 12:17:43
Message: <62a611a7$1@news.povray.org>
There appear to be certain circumstances in POV-Ray 3.6.* and older in
which area lights become shadowless.  I have only discovered it while
testing my desk lamp, for which the code is a bit involved, so I have
thus far been unable to figure out what triggers this apparent bug.

I was wondering if anyone has come across this behavior, and posted
about it or written up a bug report. Since it only seems to happen with
older versions of POV-Ray, my not finding this issue on GitHub is not
surprising; but it leaves me not knowing whether this issue has ever
been raised before.

I have thus far been unable to reproduce the problem in a simplified
scene, and the problem is not consistent in my test scenes.  The dates
on the images refer to saved development stages of my desk lamp include
file.  For the second montage, the problem shows up only after May 29;
but for the first image the problem manifests as far back as April.
(Prior to that, the test files will not render, due to scene-breaking
changes in the include file.)

The one lead that I have comes from a "verbose" feature in which I write
SDL to the debug stream.  When I render the #debug'd code, the shadows
always appear.  The main difference is that in the include file, the
light_source is transformed along with the lamp hood and main fixture,
whereas in the #debug'd code, all the parameters are transformed before
being written into the light_source statement.  This suggests a possible
workaround, but I would still like to know what is going on.

POV-Ray 3.5 and 3.6 complain that the axes of the area light must be of
equal length when using orient, which at first thought suggests floating
point errors introduced during transformation.  Yet rendering the
#debug'd code does not yield this message, even though the vectors
ultimately went through the same transformations, and the #debug'd code
has lower precision!  A quick side test demonstrated that unequal axes
do not cause the problem anyway.

P.S. I didn't notice until after I prepared the montages that the point
light images used different attenuation parameters than the area light
images; but I have verified that this is not the problem.


Post a reply to this message


Attachments:
Download 'shadowless-area-debug.jpg' (93 KB) Download 'shadowless-area-rad.jpg' (32 KB)

Preview of image 'shadowless-area-debug.jpg'
shadowless-area-debug.jpg

Preview of image 'shadowless-area-rad.jpg'
shadowless-area-rad.jpg


 

From: Cousin Ricky
Subject: Re: Seeking ancient bug report about shadowless area light
Date: 19 Jun 2022 20:51:00
Message: <62afc474@news.povray.org>
On 2022-06-12 12:17 (-4), Cousin Ricky wrote:
> 
> The one lead that I have comes from a "verbose" feature in which I write
> SDL to the debug stream.  When I render the #debug'd code, the shadows
> always appear.  The main difference is that in the include file, the
> light_source is transformed along with the lamp hood and main fixture,
> whereas in the #debug'd code, all the parameters are transformed before
> being written into the light_source statement.  This suggests a possible
> workaround, but I would still like to know what is going on.

I got the workaround working, but I have still been thoroughly
unsuccessful in figuring out what the problem is or why and when it happens.


Post a reply to this message


Attachments:
Download 'test_lamp_debug1-v36-20220619.jpg' (16 KB)

Preview of image 'test_lamp_debug1-v36-20220619.jpg'
test_lamp_debug1-v36-20220619.jpg


 

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.