|
|
|
|
|
|
| |
| |
|
|
From: Jörg 'Yadgar' Bleimann
Subject: Strange behaviour of area_light
Date: 2 Dec 2011 04:15:18
Message: <4ed89726@news.povray.org>
|
|
|
| |
| |
|
|
Hi(gh)!
Onward with the standard include files and, thus, with the PoV-Ray
museum of Port Whatmough's Academy of Raytraced Art (ARA)!
When I started to test the neon tubes for the exhibition rooms'
illumination, I noticed a strange behaviour of the area_light: although
I defined center and size of the area light correctly, the light
concentrates in one point! Moreover, the looks_like object (a union of
two narrow cylinders) is cut in half!
Here is the code:
#declare F_Standard_Indoor =
finish
{
diffuse 1.15
brilliance 0.6
}
#declare F_Incandescent =
finish
{
diffuse 1
ambient 1
}
#declare T_Simple_White_Incandescent =
texture
{
pigment { color rgb 1 }
finish { F_Incandescent }
}
#declare Neon_Tube =
cylinder
{
0, <2, 0, 0>, 0.025
texture { T_Simple_White_Incandescent }
}
plane
{
y, 0
texture
{
pigment { MidnightBlue }
finish { F_Standard_Indoor }
}
}
light_source
{
<1, 0.1, 0.06>
color White
area_light
<2, 0, 0>, <0, 0, 0.12>, 5, 2
adaptive 1
jitter
fade_distance 1
fade_power 2
looks_like
{
union
{
object { Neon_Tube translate <0, 0.1, 0> }
object { Neon_Tube translate <0, 0.1, 0.12> }
}
}
}
camera
{
location <1, 4, 0.06>
look_at <1, 0, 0.06>
angle 40
}
// end of code
Bizarre!
See you in Khyberspace!
Yadgar
Now playing: Illusions On A Double Dimple (Triumvirat)
Post a reply to this message
Attachments:
Download '2011-12-02 includes showroom 1, take 19 - neon tubes, assembly view.jpg' (13 KB)
Preview of image '2011-12-02 includes showroom 1, take 19 - neon tubes, assembly view.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> When I started to test the neon tubes for the exhibition rooms'
> illumination, I noticed a strange behaviour of the area_light: although
> I defined center and size of the area light correctly, the light
> concentrates in one point! Moreover, the looks_like object (a union of
> two narrow cylinders) is cut in half!
You have two different issues here:
- The historic area_light code is only designed to generate soft
shadows; other effects (highlights and - as in your case -
distance-based light fading) remain as per a standard point light. (The
area_illumination switch introduced with 3.7 does fix this for
highlights, but not for distance fading yet.)
- As for the looks_like object, note that you need to specify that
object as if the light source was located at <0,0,0>; it will
automatically be translated to the true position of the light source. (I
just noticed that this doesn't seem to be mentioned in the docs. I'll
take care of that.)
Post a reply to this message
|
|
| |
| |
|
|
From: Jörg 'Yadgar' Bleimann
Subject: Re: Strange behaviour of area_light
Date: 2 Dec 2011 11:11:57
Message: <4ed8f8cd@news.povray.org>
|
|
|
| |
| |
|
|
Hi(gh)!
On 02.12.2011 16:16, clipka wrote:
> - The historic area_light code is only designed to generate soft
> shadows; other effects (highlights and - as in your case -
> distance-based light fading) remain as per a standard point light. (The
> area_illumination switch introduced with 3.7 does fix this for
> highlights, but not for distance fading yet.)
I tried area_illumination (second image attached here) - and, yes, a
little bit grainy, but I think it's tolerable at least for the time
being! The area illumination not being taken into account for fading
might yield weird results, but for my scene it would not very notable,
as I'll use not less than 5 x 6 of these dual neon light panels for a
room of 15 by 12 metres!
> - As for the looks_like object, note that you need to specify that
> object as if the light source was located at <0,0,0>; it will
> automatically be translated to the true position of the light source. (I
> just noticed that this doesn't seem to be mentioned in the docs. I'll
> take care of that.)
So the looks_like object is automatically centered around the (center
point of the) light source... would be a good idea to mention this in
the wiki (and the regular doc which comes with the installation package)!
See you in Khyberspace!
Yadgar
Post a reply to this message
Attachments:
Download '2011-12-02 includes showroom 1, take 20 - neon tubes, assembly view.jpg' (14 KB)
Download '2011-12-02 includes showroom 1, take 21 - neon tubes, assembly view.jpg' (18 KB)
Preview of image '2011-12-02 includes showroom 1, take 20 - neon tubes, assembly view.jpg'
Preview of image '2011-12-02 includes showroom 1, take 21 - neon tubes, assembly view.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So the looks_like object is automatically centered around the (center
> point of the) light source... would be a good idea to mention this in
> the wiki (and the regular doc which comes with the installation package)!
Yup. As I said, I'll take care that's updated. (BTW, the wiki is
actually the place where maintenance of the doc happens; the regular
docs in the installation package are auto-generated from there.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/02/2011 05:16 PM, clipka wrote:
> - The historic area_light code is only designed to generate soft
> shadows; other effects (highlights and - as in your case -
> distance-based light fading) remain as per a standard point light. (The
> area_illumination switch introduced with 3.7 does fix this for
> highlights, but not for distance fading yet.)
And the reason why area_illumination is not always on (at least
currently) is that it makes rendering of area lights a bit slower. In
most scenes its effects would be unnoticeable, so the extra rendering
time would be wasted. It's only when the area light is relatively close
to a surface (ie. so close that the diffuse/specular illumination would
visibly differ from that of a point light) that it makes a visible
difference.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I tried area_illumination (second image attached here) - and, yes, a
> little bit grainy, but I think it's tolerable at least for the time
> being!
>
> Yadgar
>
Regarding the graineeness isue:
Looking at your light_source, I see this:
light_source
{
<1, 0.1, 0.06>
color White
area_light
<2, 0, 0>, <0, 0, 0.12>, 5, 2
adaptive 1
jitter
fade_distance 1
fade_power 2
looks_like
{
union
{
object { Neon_Tube translate <0, 0.1, 0> }
object { Neon_Tube translate <0, 0.1, 0.12> }
}
}
}
As you have 2 strips, the 2 is OK.
The problem is that you have only 5 samples on the long side.
I propose something like this:
area_light
<2, 0, 0>, <0, 0, 0.12>, 17, 2
adaptive 1
jitter
Other densities that can be good: 33, 2 or 65, 2
(at 65, 2, or more, you probably no longer need to use jiter)
It's also possible that you may have correct results using only adaptive 0.
When you have a long and narrow light, the effective fade_power gets
lower than 2. In a typical room where your distance from the tubes are
relatively small, a fade_power 1.5 would probably be more realist.
The fade_power becomes 1 when the lenght of the light becomes very large
relative to the distance.
A very large/infinite emiting plane effectively don't fade with
distance: fade_power 0.
Do the test with a radiosity scene illuminated by an emiting plane.You
will have a constant illumination regardless of the distance from the plane.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.12.2011 23:01, schrieb Alain:
> When you have a long and narrow light, the effective fade_power gets
> lower than 2. In a typical room where your distance from the tubes are
> relatively small, a fade_power 1.5 would probably be more realist.
> The fade_power becomes 1 when the lenght of the light becomes very large
> relative to the distance.
A fade_power setting of 2 is perfectly ok in /every/ situation with
light sources of finite size. Note that the effective fade_power already
decreases automatically as objects get closer to the light source. This
effect is governed by fade_distance, which should be set to the light
source's size, or at least a value somewhere close.
Post a reply to this message
|
|
| |
| |
|
|
From: Jörg 'Yadgar' Bleimann
Subject: Re: Strange behaviour of area_light
Date: 5 Dec 2011 20:52:32
Message: <4edd7560@news.povray.org>
|
|
|
| |
| |
|
|
Hi(gh)!
On 02.12.2011 19:31, Warp wrote:
> And the reason why area_illumination is not always on (at least
> currently) is that it makes rendering of area lights a bit slower.
Yes it does... 129.029 CPU seconds (I assume that this is the time
actually devoted to POV-Ray regardless of any multitasking background
processes) (first image) vs. 148.053 for the the last image attached here...
See you in Khyberspace!
Yadgar
Now playing: East At Easter, live 1987 (Simple Minds)
Post a reply to this message
Attachments:
Download '2011-12-06 includes showroom 1, take 59 - neon light and carpet.jpg' (67 KB)
Download '2011-12-06 includes showroom 1, take 60 - neon light and carpet.jpg' (55 KB)
Preview of image '2011-12-06 includes showroom 1, take 59 - neon light and carpet.jpg'
Preview of image '2011-12-06 includes showroom 1, take 60 - neon light and carpet.jpg'
|
|
| |
| |
|
|
|
|
| |
|
|