Chris Huff <chr### [at] maccom> wrote:
: The area light would go from 
: <location>-Axis_1-Axis_2 to <location>+Axis_1+Axis_2.

  Actually, I think it goes from
<location>-axis1/2-axis2/2  to  <location>+axis1/2+axis2/2
  That is, the width of the area light is axis1 and the height is axis2 and
the <location> is its center.

  I might be wrong, of course, but I think I tested this some years ago.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <3a0d45d1@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Actually, I think it goes from <location>-axis1/2-axis2/2 to  
> <location>+axis1/2+axis2/2
>   That is, the width of the area light is axis1 and the height is axis2 
> and the <location> is its center.

After looking at the source(and resisting the temptation to completely 
rewrite it), I think you are right, the length of the axis vectors 
specifies the size across, not the size from the center. The 
block_area_light() function in it's current state in MegaPOV is not a 
pretty sight... :-)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> The
> block_area_light() function in it's current state in MegaPOV is not a
> pretty sight... :-)

That's for sure!  I tried a patch to the area_light code and wound up working
with the official version because I couldn't stand looking at that section of
code in MegaPOV anymore.

Btw, that patch turned out to be a flop - didn't work as I had hoped.

-Mike

Post a reply to this message

In article <3A0DF5CC.289FA76D@aol.com>, MikeH <Ama### [at] aolcom> 
wrote:

> That's for sure!  I tried a patch to the area_light code and wound up 
> working with the official version because I couldn't stand looking at 
> that section of code in MegaPOV anymore.
> 
> Btw, that patch turned out to be a flop - didn't work as I had hoped.

Just wondering...what was that patch supposed to do?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> Just wondering...what was that patch supposed to do?

It was an attempt to make a completely general purpose area light that,
like the current area light implimentation, only worked on shadows.  The
difference is that you would provide a list of vectors as the shadow sample
points.  It actually works but needs some kind of jitter to eliminate
artifacts.  I tested the patch with a large array of points derived from a
geosphere mesh and ran into an obvious problem - the shadows can completely
surround the surface, but the lit calculation still only eminates from one
point.  Therefore the light doesn't illuminate from the sides properly.  I
figured that the only way to get it to work would be to perform a complete
diffuse and shadow calculation for each point and the amount of work
involved wasn't worth the trouble. That, and you could do the same thing
with an array of standard lights and get the same effect which also happens
to take about the same amount of time to render as ambient geometry with
radiosity on.

An excercise is futility I suppose.

-Mike

Post a reply to this message

i decided to use an area_light with a light bulb i made to try and
realistically light my scene. the main spherical part light bulb has a
radius of about 0.7 units. but when i set the area_light's two axises to
0.7 i got a parse error: Attempt to malloc zero size block: (File
...\..\source\point.cpp Line: 657)

here's the code for the light_source that gave me the problem;

light_source{
<0,6.6,0>1
area_light
x,z,1,1
fade_distance 10
fade_power 0.25
}

it works fine as long as the area_light's axises are at least 1 unit in
size. i dont know if this is a bug or not, so i thought i'd ask.

Post a reply to this message

Twitcher <nomail@nomail> wrote:
> area_light
> x,z,1,1

  I haven't tried, but making a 1x1 area light seems pointless (it would
be simply a point light, so why bother making an area light in the first
place), and perhaps a source of problems for the parser... (If this is
the reason for the allocation error, then it's a bug which should be fixed.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e22140d@news.povray.org...
> Twitcher <nomail@nomail> wrote:
> > area_light
> > x,z,1,1
>
>   I haven't tried, but making a 1x1 area light seems pointless (it would
> be simply a point light, so why bother making an area light in the first
> place), and perhaps a source of problems for the parser... (If this is
> the reason for the allocation error, then it's a bug which should be
fixed.)

Yes, and I believe Twitcher had mistakenly thought the second two numbers
were for the dimension rather than a grid of points (sublights).

So to clarify that, if so, x and z are the size or area. Use 0.7*x,0.7*z,2,2
to get the result intended. Like Warp said, 1 by 1 is no good.

I checked, and sure enough, the error isn't informative unless you already
know what's going on. Probably should tell the user about a minimal grid
size of points needed for the area light when less than 1 is used just as it
does when it is greater than 1 and less than 2. Oddly enough it's giving a
good error message when negatives are used that are -1 or less but it isn't
doing so for all decimals between -1 and 1.

Post a reply to this message

hughes, b. <omn### [at] charternet> wrote:
> So to clarify that, if so, x and z are the size or area.

  Technically speaking that description is incomplete. The two vectors do
not only define the size (ie. dimensions) but also the orientation of the
area lights. Using x and z gives you a very different orientation than
using eg. x and y. (Unless you are using 'orient', of course.)
  It should also be noted that using x and z is different from using
x and 2*z, which gives you an area lights twice as long in the z direction
(in this case, in order to get better lighting, you should also double the
density of the grid in that axis, ie. the fourth parameter given to
'area_light').

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

By the way, for more info about common misunderstandings about area lights,
see http://www.students.tut.fi/~warp/povQandT/misconceptions.html#arealightconfusion2

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message