On Tue, 10 Sep 2002 16:41:07 +0530, "Rahul Pilani" <rah### [at] yahoocom>
wrote:
>is something wrong

try to understand area_light parameters, they are nicely described in
documentation

btw: this group is not for binary posting and there is a special group for
newbie kind questions

ABX

Post a reply to this message

Well, you were correct about it being due to the area_light parameters, but
he didn't post a binary, he posted a .POV file...

ABX wrote:
> 
> On Tue, 10 Sep 2002 16:41:07 +0530, "Rahul Pilani" <rah### [at] yahoocom>
> wrote:
> >is something wrong
> 
> try to understand area_light parameters, they are nicely described in
> documentation
> 
> btw: this group is not for binary posting and there is a special group for
> newbie kind questions
> 
> ABX

Post a reply to this message

Gwen & Emory Stagmer <emo### [at] comcastnet> wrote:
> Well, you were correct about it being due to the area_light parameters, but
> he didn't post a binary, he posted a .POV file...

  But he posted it uuencoded, not in plain text. That is, he posted it in
binary format, not text format.

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

Sorry, my reader just gave it to me in text - I didn't notice the UUENCODE...

Emory

Warp wrote:
> 
> Gwen & Emory Stagmer <emo### [at] comcastnet> wrote:
> > Well, you were correct about it being due to the area_light parameters, but
> > he didn't post a binary, he posted a .POV file...
> 
>   But he posted it uuencoded, not in plain text. That is, he posted it in
> binary format, not text format.
> 
> --
> #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

Rahul,
   Try the following lighting:

light_source 
    {
    <-12,12,-3>
    color White
    area_light <3, 0, 0>, <0, 0, 3>, 20,20
    adaptive 3
    //jitter
    }

Note: I've got 400 lightsources, you had 9.  I also don't usually like
the jitter, I'd rather wait for the 'real thing'.  I ran this at
800x600 A0.3 on my AMD Thunderbird 750Mhz - took about 3 hrs 45 min.
Slowest lines ran about 4PPS!  There's just a little bit of banding
around coordinates 265x445, but it's pretty smooth...
I posted it at:
  http://www.untiedmusic.com/dice1.jpg

I generally find lighting is one of the places I always can criticize
about other peoples work (OK, mine too sometimes!).  Render it rough
while you're working on it, but for the finals, very dense area lights
will make a HUGE difference when trying to do these kinds of soft
shadows and edges...even the Sun is not a point source, it's a disc.
You can simulate it with area lights and get MUCH more realistic daylight.

Emory

ABX wrote:
> 
> On Tue, 10 Sep 2002 16:41:07 +0530, "Rahul Pilani" <rah### [at] yahoocom>
> wrote:
> >is something wrong
> 
> try to understand area_light parameters, they are nicely described in
> documentation
> 
> btw: this group is not for binary posting and there is a special group for
> newbie kind questions
> 
> ABX

Post a reply to this message

Gwen & Emory Stagmer <emo### [at] comcastnet> wrote:
> Note: I've got 400 lightsources, you had 9.  I also don't usually like
> the jitter, I'd rather wait for the 'real thing'.

  When you have enough density in the area light, jittering can get rid
of the banding in the shadows without introducing visible graininess, thus
needing less density and thus rendering faster. (I speak from experience.)

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

> I speak from experience

Me too, I've tried setting up a grid of point lights, to simulate an
automated grid of area_lights. In cases where you want a very large area of
light, a real grid is best while it illuminates the objects accurately, not
just softening the shadows... But in cases where you need the sun, there is
absolutely no visble gain from setting up a real grid of lights.

In other words, a real grid is good for the blue sky, or a reflecting wall,
or so... Warps idea of a mix between area_lights and a real grid sounds like
a good idea... And speaking of the blue sky, sometimes radiosity provides
this kind of area-light more efficiently than a grid of light_sources.

Good luck,
Regards,
Hugo

Post a reply to this message

Hugo <hua### [at] post3teledk> wrote:
> Warps idea of a mix between area_lights and a real grid sounds like
> a good idea...

  Uh? There must be some confusion here.
  I was speaking merely of one single area_light (when I use the word
"density" I'm talking about how many "point lights" it contains, ie. the
'Size_1' and 'Size_2' parameters used in the documentation).

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