![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Mon, 12 Nov 2001 20:48:44 +0100, Thorsten Froehlich wrote:
> In article <slr### [at] fwi com> , Ron Parker
><ron### [at] povray org> wrote:
>
>> Nope, a Win32 stack has a "reserve" size and a "commit" size. The loader
>> allocates address space for the "reserve" size, but it only actually maps
>> memory for the "commit" size. It then marks the page just below the
>> commit as Not Present and waits for it to fault. When it faults, the OS
>> maps another page into the address space
>
> But it cannot shrink the stack this way. So once you have a stack that is
> i.e. 100 MB you have to restart the application. I think the same problem
> exists under Unix. Unless, of course, you have a system function to shrink
> the stack "manually".
Threads.
Each thread has its own stack allocation. Kill the render thread and
restart it, and the stack allocation starts over at the "commit" size again.
--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Ken" <tyl### [at] pacbell net> wrote in message
news:3BEF1927.DABD73B5@pacbell.net...
>
>
>
> The following quote comes straight from the POV-Ray v2.2 docs so it is
> obvious that this limitation has been known for many years now -
>
> "Note: Raising max_trace_level will use more memory and time and it could
> cause the program to crash with a stack overflow error. Values for
> max_trace_level are not restricted, so it can be set to any number as long
> as you have the time and memory."
>
I'm not denying it hasn't been there for a long time... it's just that this is
the first time I've run into it being a problem. Like I said, I probably read
it a long time ago.
Michael
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Fabien Mosen <fab### [at] skynet be> wrote:
: Out of curiosity, what would you do, render-wise, with a limit of
: 30 000 ??? (or, if you want, even 300).
Perhaps not 30000, but 300 and more could be necessary to render lots of
semi-transparent objects (eg. lens flares, "sprites" which form things like
flames, clouds, etc).
If people would never need a max_trace_level higher than about 300, then
they wouldn't have found this limit.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Perhaps not 30000, but 300 and more could be necessary to render lots of
> semi-transparent objects (eg. lens flares, "sprites" which form things
like
> flames, clouds, etc).
Please write a (reasonable) POV-Ray scene where you can see the difference
between 50 and 80 levels.
(reasonable means : not a serie of 100 transparent planes)
Fabien.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
fabien <fab### [at] skynet be> wrote:
: Please write a (reasonable) POV-Ray scene where you can see the difference
: between 50 and 80 levels.
There is a visible difference between 50, 100 and 500 recursions in this
scene. Of course I could have came up with a scene where the difference is
more _important_, but I didn't have time for anything fancier.
global_settings { max_trace_level 500 }
camera { location <-1,2.5,-10> look_at y angle 35 }
light_source { <1000,2000,-1500>, 1 }
plane { y,0 pigment { rgb <1,.8,.4> } }
#declare GrassPatch =
box
{ <-50,0,0><50,2,.1>
pigment
{ spherical color_map
{ [0 rgbt <0,0,0,1>][.1 rgb y]
}
scale <.02, 1.95, .02>
translate x*.1
warp { repeat x*.2 }
warp { turbulence x*.1 }
}
}
#declare S = seed(0);
#declare Ind = 0;
#while(Ind < 1000)
object { GrassPatch translate <-2+4*rand(S),0,-5+Ind> }
#declare Ind = Ind + 1;
#end
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |