Chris H., thanks for the macro.  I hadn't thought about doing that.

I'm finding I don't understand the concept of area_light very well, and
I was wondering if someone could clarify it for me?  Looking at page 222
of the official documentation, I read that the syntax is:

light_source { <location>, COLOR area_light <Axis_1>, <Axis_2>, Size_1,
Size_2 [adaptive ADAPTIVE] [jitter JITTER] [LIGHT_MODIFIERS] }

What I don't understand is the axis_1 and axis_2.  The descriptive
paragraph just above the syntax says that an area light is a one or
two-dimensional area of space.  

Therefore, one possible interpretation of this syntax would be that the
area starts at the location of the light_source, and extends in one
direction until the limit set by the axis_1, then again starts at the
location, and extends in a second direction until it hits the limit set
by axis_2, forming between them the two sides we need to know to form a rectangle.

A second possible interpretation of this syntax is that it should be
specified in the same way as a box, with more than one plane location
specified in the vector arguments, and the area_light filling the area
between the two points.

Which is the correct interpretation?

If it is the first one, how do you use this with the looks_like
argument?  You'd get half of your cylinder, for instance, lit... or even
a quarter of it, depending on how the object is displayed around the
<location> argument.

I know that I'm probably making this more difficult than it ought to be,
but I just don't understand.

As an afterthought, can anyone suggest a good texture for simulating leather?

Thanks in advance.

Dawn, the confused.

Post a reply to this message

In article <3A0CEB66.142B670F@mac.com>, mck### [at] maccom wrote:

> Chris H., thanks for the macro.  I hadn't thought about doing that.

You're welcome... :-)


> I'm finding I don't understand the concept of area_light very well, and
> I was wondering if someone could clarify it for me?  Looking at page 222
> of the official documentation, I read that the syntax is:
> 
> light_source { <location>, COLOR area_light <Axis_1>, <Axis_2>, Size_1,
> Size_2 [adaptive ADAPTIVE] [jitter JITTER] [LIGHT_MODIFIERS] }
> 
> What I don't understand is the axis_1 and axis_2.  The descriptive
> paragraph just above the syntax says that an area light is a one or
> two-dimensional area of space.  

I have always interpreted it this way: the <location> vector specifies 
the center of the source, the two <Axis_x> vectors specify the 
directions and extents of the rectangle, and the Size_x values specify 
the "resolution" of the area light. The area light would go from 
<location>-Axis_1-Axis_2 to <location>+Axis_1+Axis_2.
The documentation is pretty vague though, and I have very rarely used 
area lights, so I could easily be wrong...


> If it is the first one, how do you use this with the looks_like
> argument?  You'd get half of your cylinder, for instance, lit... or even
> a quarter of it, depending on how the object is displayed around the
> <location> argument.

looks_like simply places a copy of the looks_like object at the location 
of the light source. The looks_like object will automatically be made 
shadowless, but will be lit normally(I personally have never used 
looks_like, I prefer to use unions of objects with the light source). 
Also, area lights only affect shadows, not surface shading, so there is 
no reason for only half of the object to be illuminated.


> As an afterthought, can anyone suggest a good texture for simulating 
> leather?

Depends on what you want, "leather" can have a lot of different colors 
and textures. A fairly simple pigment with a crackle, granite, or 
wrinkles normal would probably work well...

-- 
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

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