Hello,

  is any way how to not use max_trace_level when object has ior=1? It 
can be very useful for scenes where you have for example 200 bitmap 
trees on polygons at one side of road and some glass things. When you 
set max_trace_level too low, you will get errors at polygons with trees. 
When you set max_trace_level to neccesasry value for trees (200, in this 
   case and worst camera setttings), the glass will render 
unneccessarilly slow.

   I think, that there is no reason why use max_trace_level for objects 
with ior=1 and no reflection, because there is no way how to reach 
infinite depth of raytracing, as in the case of glass box with ior != 1.

Regads

Vaclav

Post a reply to this message

Vaclav Cermak <dis### [at] itamcascz> wrote:
>    I think, that there is no reason why use max_trace_level for objects 
> with ior=1 and no reflection, because there is no way how to reach 
> infinite depth of raytracing, as in the case of glass box with ior != 1.

  Each surface hit and consequent new ray will cause a recursive call.
You don't need an infinite amount of recursions for the program to run
out of stack space: Just put some thousands of transparent surfaces in
a row and trace a ray through them.

  One solution is to use adc_bailout to limit the recursion depth in
glass (supposing the glass filters the rays even a bit).

-- 
#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:
> 
>   Each surface hit and consequent new ray will cause a recursive call.
> You don't need an infinite amount of recursions for the program to run
> out of stack space: Just put some thousands of transparent surfaces in
> a row and trace a ray through them.

This can be solved by separate max_trace_level for surfaces with ior=1 
and no reflection. Also, but this is not so trivial change to POV code, 
for such a surfaces there is no need to shoot another ray (but another 
way how to deal with scene bounding is needed in this case, all 
intersections of objects with ray are neccessary here, not only first 
one). It can be also a speedup, I think.

> 
>   One solution is to use adc_bailout to limit the recursion depth in
> glass (supposing the glass filters the rays even a bit).
> 

Yes, this is good idea how to solve it without chnaging POV code.

Post a reply to this message

In article <40ab68da@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Each surface hit and consequent new ray will cause a recursive call.
> You don't need an infinite amount of recursions for the program to run
> out of stack space: Just put some thousands of transparent surfaces in
> a row and trace a ray through them.

Note that this isn't strictly necessary...those intersections have 
already been done...when there isn't any refraction, it is possible to 
step through transparent layers in sequence. However, POV just finds the 
"best" intersection and starts over again. This might make a nice 
optimization for media containers or other uses of transparent 
non-refracting objects, like lens flares...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> Note that this isn't strictly necessary...those intersections have 
> already been done...

  Wouldn't this kind of optimization mean that POV-Ray would have to keep
all the intersections of a ray and the scene in memory?
  Does it do that already? If yes, I don't understand why. POV-Ray only
uses the closest intersection so why would it need to keep in memory
all the intersections?
  If no, then how would this kind of optimization affect memory consumption
and speed? After all, a ray can intersect the scene in thousand and
thousands of places...

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

In article <40b1f367@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Does it do that already? If yes, I don't understand why. POV-Ray only
> uses the closest intersection so why would it need to keep in memory
> all the intersections?

No, it doesn't keep all the intersections...that's the point: it 
currently throws them away when they could still be useful.


>   If no, then how would this kind of optimization affect memory consumption
> and speed? After all, a ray can intersect the scene in thousand and
> thousands of places...

Leading to a few thousand intersections, which really isn't that much 
memory. And that's if you don't limit the length of the list.
As for speed...the list can be built in logarithmic time. Repeatedly 
doing the intersection tests increases in quadratic time. For 10 
surfaces, the last surface is tested 10 times, the one before it 9 
times, the one before that 8...if they are all stored in a list, they 
are all tested once. And note that the list only has to go up to the 
first refracting or opaque intersection, any intersections past that can 
be thrown away immediately.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

If you need all the intersections, wouldn't that slow down rendering
of meshes?
  If I'm not mistaken, POV-Ray searches for the closest intersection
with a mesh in a smart way (using the octree subdivision of the mesh),
skipping most of the intersection tests (even for those triangles which
the ray would intersect if there weren't triangles in front of them).
  If you need all the intersections, POV-Ray could not skip testing
those triangles it already knows are behind the closest found.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <40b24060@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   If you need all the intersections, wouldn't that slow down rendering
> of meshes?

No. You only need all the intersections if the mesh is transparent and 
non-refracting, otherwise, just grab the first intersection, and if it 
comes before the last intersection in the list, use it to terminate the 
list. And in the case where all intersections are needed, finding all 
intersections at once will still be faster than finding the first 
intersection multiple times.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message