| 
|  |  |  
|  |  |  |  |  |  |  |  |  |  |  
|  |  |  |  |  |  |  |  |  |  |  
|  |  | Alright, I've got some really neat looking clouds using the stacked planes
method, but it only looks good at lower resolutions. So when I increase the
resolution, I increase the number of layers. However, when I get to the
point of over 100 or so layers, POV-Ray says: Too many nested refraction
objects. I assume this has something to do with stack overflows from the
recursion?
Is there anyway around this? If I decrease the max_trace_level, I get black
sillouts of the disc object, but if I don't have enough disks, you can see
the individual layers. Any ideas?
 Post a reply to this message
 |  |  |  |  |  |  |  |  
|  |  |  |  |  |  |  |  |  |  |  
|  |  | "Chris Becker" <cmb### [at] rit edu> wrote in message
news:3c82ea1f$1@news.povray.org...
> point of over 100 or so layers, POV-Ray says: Too many nested refraction
> objects. I assume this has something to do with stack overflows from the
> recursion?
>
> Is there anyway around this? If I decrease the max_trace_level, I get
black
> sillouts of the disc object, but if I don't have enough disks, you can see
> the individual layers. Any ideas?
There is a work-around.  Use very thin cylinders (however infinitely thin is
impossible).  It seems to be a limitation with infinite objects of which
disc and plane are two such things.
I don't know the reason for it or if there's a setting that will circumvent
this error.
bob h Post a reply to this message
 |  |  |  |  |  |  |  |  
|  |  |  |  |  |  |  |  |  |  |  
|  |  | In article <3c82ea1f$1@news.povray.org>,
 "Chris Becker" <cmb### [at] rit edu> wrote:
> Alright, I've got some really neat looking clouds using the stacked planes
> method, but it only looks good at lower resolutions. So when I increase the
> resolution, I increase the number of layers. However, when I get to the
> point of over 100 or so layers, POV-Ray says: Too many nested refraction
> objects. I assume this has something to do with stack overflows from the
> recursion?
Planes only have one surface, so POV never exits a layer, and it sees 
all the layers as being nested. Use an object which the ray will 
eventually exit, like a box. The box will simulate two planes, halving 
the number of objects used for the clouds, and will be better bounded 
than planes.
-- 
Christopher James Huff <chr### [at] mac  com>
POV-Ray TAG e-mail: chr### [at] tag  povray  org
TAG web site: http://tag.povray.org/ Post a reply to this message
 |  |  |  |  |  |  |  |  
|  |  |  |  |  |  |  |  |  |  |  
|  |  | Wow, it was that simple, it worked better than great!
Thanks a bunch!
"Chris Becker" <cmb### [at] rit edu> wrote in message
news:3c82ea1f$1@news.povray.org...
> Alright, I've got some really neat looking clouds using the stacked planes
> method, but it only looks good at lower resolutions. So when I increase
the
> resolution, I increase the number of layers. However, when I get to the
> point of over 100 or so layers, POV-Ray says: Too many nested refraction
> objects. I assume this has something to do with stack overflows from the
> recursion?
>
> Is there anyway around this? If I decrease the max_trace_level, I get
black
> sillouts of the disc object, but if I don't have enough disks, you can see
> the individual layers. Any ideas?
>
> Post a reply to this message
 |  |  |  |  |  |  |  |  
|  |  |  |  |  |  |  |  |  |  |  
|  |  | > 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] hotmail com> 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] hotmail com> 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
 |  |  |  |  |  |  |  |  
|  |  |  |  |  |  |  |  |  |