> Alright, I've got some really neat looking clouds using the stacked planes
> method, ...


I don't understand why people use this "stacked-planes" technique when
method 3 media basically simulates it, sometimes making it faster because of
it's anti-aliasing capability.

Unless, of course, one doesn't have version 3.5, although I created some
pretty good clouds with 3.1 media once...

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

Slime <noo### [at] hotmailcom> wrote:
> I don't understand why people use this "stacked-planes" technique when
> method 3 media basically simulates it, sometimes making it faster because of
> it's anti-aliasing capability.

  When a concept gets popular, it's quite difficult to eradicate. In this
case the concept is "media is slow".

  (Another example of this kind of misconception is "area lights are slow;
it's better to use an array of point lights". See
http://www.students.tut.fi/~warp/povQandT/misconceptions.html#arealightconfusion)

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

Warp wrote:
>
>   (Another example of this kind of misconception is "area lights are slow;
> it's better to use an array of point lights".

I have a scene where area_light length*x,z,32,1 takes 6 times
longer to render than 32 point lights. 


_____________
Kari Kivisalo

Post a reply to this message

> I have a scene where area_light length*x,z,32,1 takes 6 times
> longer to render than 32 point lights.

I'd be interested in the source.

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

Slime <noo### [at] hotmailcom> wrote:
>> I have a scene where area_light length*x,z,32,1 takes 6 times
>> longer to render than 32 point lights.

> I'd be interested in the source.

  Me too. There's no logical explanation for this.

  (Unless 1-dimensional light sources have some defect or bug in POV-Ray.)

-- 
#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 wrote:
>
>   Me too. There's no logical explanation for this.

Here is the 2.0 source hastily converted to 3.5:

#version 3.5;

#declare USE_AREA=1;

camera {
  location  <6,6,-6>
  direction <0,0,1.5>
  look_at   <1,0,0>
}

#declare length=10;
#declare h=0.6;
#declare i=1;

#declare tube1=
union{
  light_source{
    <0, h, 0>
    color rgb i
    area_light length*x,z,32,1
  }
  cylinder{
    <-length/2,h,0>,<length/2,h,0>,0.05
    pigment{color rgb<1,1,1>}
    finish{diffuse 0 ambient 1}
    no_shadow
  }
}

#declare d=length/31;
#declare di=i/32;

#declare light=light_source{<-length/2,h,0> color rgb di}

#declare tube2=
union{
  #declare I=0;#while(I<32)
    object{light translate I*d*x}
  #declare I=I+1;#end
  cylinder{
    <-length/2,h,0>,<length/2,h,0>,0.05
    pigment{color rgb<1,1,1>}
    finish{diffuse 0 ambient 1}
    no_shadow
  }
}

#if(USE_AREA=1)
  object{tube1}
#else
  object{tube2}
#end

#declare ball=sphere{<0,0.25,0>,0.25}

#declare row=
union{
  object{ball translate<-1.5,0,0.5>}
  object{ball translate<-0.5,0,0.5>}
  object{ball translate<0.5,0,0.5>}
  object{ball translate<1.5,0,0.5>}
}

union{
  object{row translate<0,0,1>}
  object{row translate<0,0,0>}
  object{row translate<0,0,-1>}
  object{row translate<0,0,-2>}
  pigment{color rgb<1,1,1>}
  finish{diffuse 1.5 ambient 0.1 phong 1}
}

plane{y,0
  texture{
    pigment{checker color rgb<1,1,1> color rgb<0.5,0.8,1>}
    finish{diffuse 1.5 ambient 0.1}
    scale 0.5
  }
}

_____________
Kari Kivisalo

Post a reply to this message

> Here is the 2.0 source hastily converted to 3.5


Interesting. It seems as though you're right.

Here's what I suspect: when I changed the number of lights in the Z
direction of the area light to 2, the render time didn't change (38 seconds
with either 1 or 2 in the z direction). I think maybe POV-Ray is treating
1-dimensional light sources as two-dimensional ones, thereby checking each
point on the area light twice. If this is right, it borders on a bug...

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

The reason I used stacked planes is that it was a very simple idea and I was
just exploring how well it works. I can see that it does have its
limitations due to how close you can get and a limit of 256 recursion depth
(at least on  Windows 98). The one thing I found that was really great was
that I could use the 'object' pattern and actually model a cloud and then
you the turbulence modefier to make it wavy and such which produced some
very nice results. Also, with the stacked plains and the 'filter' color, you
can light the cloud and it will actually shadow itself like a gas really
does.

Is it possible to do all that with media, and is there some kind of tutorial
that might help me with it? (My luck with media is very very low, I change
something from the demo scene file and poof, it's all gone)
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c84b52c@news.povray.org...
> Slime <noo### [at] hotmailcom> wrote:
> > I don't understand why people use this "stacked-planes" technique when
> > method 3 media basically simulates it, sometimes making it faster
because of
> > it's anti-aliasing capability.
>
>   When a concept gets popular, it's quite difficult to eradicate. In this
> case the concept is "media is slow".
>
>   (Another example of this kind of misconception is "area lights are slow;
> it's better to use an array of point lights". See
>
http://www.students.tut.fi/~warp/povQandT/misconceptions.html#arealightconfu
sion)
>
> --
> #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

In article <3c86964e$1@news.povray.org>,
 "Chris Becker" <cmb### [at] ritedu> wrote:

> The reason I used stacked planes is that it was a very simple idea and I was
> just exploring how well it works. I can see that it does have its
> limitations due to how close you can get and a limit of 256 recursion depth
> (at least on  Windows 98). The one thing I found that was really great was
> that I could use the 'object' pattern and actually model a cloud and then
> you the turbulence modefier to make it wavy and such which produced some
> very nice results.

This is at least as easy with media density, just use the object pattern 
with turbulence.


> Also, with the stacked plains and the 'filter' color, you can light 
> the cloud and it will actually shadow itself like a gas really does.

This is automatic with scattering media. Media doesn't have problems 
with recursion limits, and you don't need as many samples in the first 
place because they are spaced differently, more like planes 
perpendicular to the camera.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

"Slime" <noo### [at] hotmailcom> wrote in message
news:3c8557ff$1@news.povray.org...

> I think maybe POV-Ray is treating 1-dimensional light sources > as
two-dimensional ones, thereby checking each point on the
> area light twice. If this is right, it borders on a bug...

I don't think so. I changed the spheres into boxes to see the shadows
better, lifted the light to 2.6 and got the following:

area_light, area 32x1, points 32x1
----------------------------------------------------------
Box                    21684326       2200482     10.15
Cone/Cylinder          54435326      54420812     99.97
Plane                  56639191        969192      1.71
Bounding Box          339332733     110901120     32.68
Vista Buffer            3909343       2764547     70.72
------------------------------------------------------------
Shadow Ray Tests:       7041549   Succeeded:    2095158
--------------------------------------------------------------
Time For Trace:  0 hours  3 minutes  11.0 seconds (191 seconds)

Notice the Cone/Cylinder intersection tests..

area_light, area 32x1, points 32x2
----------------------------------------------------------
Box                     43843409      4878047     11.13
Cone/Cylinder              33295        18794     56.45
Plane                   55546322       971544      1.75
Bounding Box           285838244      3696599      1.29
Vista Buffer             3928127      2776387     70.68
----------------------------------------------------------
Shadow Ray Tests:       97865400   Succeeded:   4766193
----------------------------------------------------------
Time For Trace:  0 hours  2 minutes  46.0 seconds (166 seconds)


I guess the extra ray->shape intersection tests come from the lights being
inside the cylinder in the 32x1 points case. Could this be avoided some how?
I don't see why all the test should be done if the light_source is unioned
with a no_shadow object. Using looks_like gives also approximately the same
result as in the 32x1 case.

Ari-Matti

Post a reply to this message