 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] ritedu> 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] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
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] ritedu> 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] 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
|
|
| |
| |
|
|
|
|
| |
|
|
