I'm working on a scene with a table made of iso-plankes (just like those in
the isowood include file). With the beta 7 these isos render MUCH slower:
beta 6: 1 m 45 s
beta 7: 8 m 22 s.
These planks are simple f_rounded_box displaced with a wood pigment.
Christoph, can you confirm?

POV-Ray 3.5 beta 7 Windows ME Athlon
(Intel compile)

--
Jonathan.

Post a reply to this message

In article <3bdf24b3$1@news.povray.org> , "JRG" <jrg### [at] hotmailcom> wrote:

> I'm working on a scene with a table made of iso-plankes (just like those in
> the isowood include file). With the beta 7 these isos render MUCH slower:
> beta 6: 1 m 45 s
> beta 7: 8 m 22 s.
> These planks are simple f_rounded_box displaced with a wood pigment.

Providing a scene might be useful....

    Thorsten

Post a reply to this message

Right:
Here is the code without modifications:


#include "functions.inc"
#include "colors.inc"
//#include "woodmaps.inc"
#include "woods.inc"

#declare table_x=150;
#declare table_y=3;
#declare table_z=90;
#declare n=8;
#declare RS=seed(0);

#declare i=0;
#while (i<n)

#declare pig_wood=
pigment {
    wood
    scale 0.5
    turbulence 0.07
    rotate 90*y
    warp {
        black_hole
        <0,3/2,0>, 2
        strength 2
        falloff 2
        inverse
        repeat 2*<10,0,10>
        turbulence 0.5
    }
     rotate <rand(RS),rand(RS),rand(RS)>*2 translate
<rand(RS),rand(RS)*0,rand(RS)>*30


    }

#declare pig_func=
function { pigment {pig_wood color_map {[0 rgb 0][1 rgb 1]}}}


isosurface {
    function {
        f_rounded_box (x,y,z,0.5,table_x/2,table_y/2,table_z/2/n) +
pig_func(x,y,z).gray*0.08
    }
    accuracy 10^-3
    max_gradient 2
    evaluate 1,10,.99
    contained_by {box {-<table_x,table_y,table_z/n>/2,
<table_x,table_y,table_z/n>/2}}

    pigment {
        pig_wood
        color_map {M_Wood3A}
    }
    finish {ambient 0 diffuse 0.8 specular 0.1 roughness 0.02 brilliance
1.25}
    scale <1,1,0.99>
    translate (-table_z/n/2-table_z/n*i)*z+(-0.25+0.5*rand(RS))*y
    translate 50*z

}

#undef pig_func //without this one it crashes (in beta 6. I don't know about
beta 7 (which I have to reinstall))
#declare i=i+1;
#end


camera {
    location <0,20,-50>
    look_at 0
    rotate 10*y}

light_source {
    <150,150,-150>
    rgb 1.5
    fade_power 2
    fade_distance 300}

background {rgb 0.5}

Post a reply to this message

In article <3bdf2d82@news.povray.org> , "JRG" <jrg### [at] hotmailcom> wrote:

>  evaluate

I can confirm that isosurfaces that use "evaluate", and *only* isosurfaces
that use "evaluate" exhibit this speed problem in beta 7.  The workaround is
to use "evaluate" only if absolutely necessary.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: I can confirm that isosurfaces that use "evaluate", and *only* isosurfaces
: that use "evaluate" exhibit this speed problem in beta 7.  The workaround is
: to use "evaluate" only if absolutely necessary.

  Is this phenomenon temporary or has it came to stay?

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

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

> : The workaround is
> : to use "evaluate" only if absolutely necessary.
>
>   Is this phenomenon temporary or has it came to stay?

Workaround usually suggests something temmporary for me.  As far as details
are concerned, after looking a bit closer into the code for "evaluate" it
seems like it is almost redundant:  The parameters you specifc after the
"evaluate" keyword only had a function if no max_gradient was set.
Consequently this would lead to the odd behavior that if and only if the
default max_gradient (which is 1.1) was used, max_gradient itself would be
adjusted.  Unfortunately, due to a logic mistake I kept one of these
modifications of max_gradient also it should have been removed.  I think I
have a fix for this already*.


    Thorsten

* Warp: Do a sync (get change 1235) to try it.


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> I can confirm that isosurfaces that use "evaluate", and *only* isosurfaces
> that use "evaluate" exhibit this speed problem in beta 7.  The workaround is
> to use "evaluate" only if absolutely necessary.
> 

That's really sad, i was just starting to use it intensively.  Apart from
being incredibly slow it also seems to produce wrong results.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3BDFBF72.F7D52C4F@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> That's really sad, i was just starting to use it intensively.

That is part of beta testing.  It is not really a serious problem, it is
just very slow...

> Apart from
> being incredibly slow it also seems to produce wrong results.

No, it only changes your max_gradient.  The reported found maximum gradient
value is still correct.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

JRG wrote:
> 
> I'm working on a scene with a table made of iso-plankes (just like those in
> the isowood include file). With the beta 7 these isos render MUCH slower:
> beta 6: 1 m 45 s
> beta 7: 8 m 22 s.
> These planks are simple f_rounded_box displaced with a wood pigment.
> Christoph, can you confirm?
> 

I can confirm that evaluate can be quite slow.  NTL, with the isowood
sample i tried, evaluate led to faster results for some reason.  Note that
it only worked with the MSVC compile, the intel version still crashes
(probably because of the function declaration problems)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3BDFC6D1.332E1CE6@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> (probably because of the function declaration problems)

No, those should be gone.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> No, it only changes your max_gradient.  The reported found maximum gradient
> value is still correct.

I'm not sure if i understand that right, the scene uses

evaluate 8, 1.2, 0.9

and no specified max_gradient

and produces different results with beta 6 and beta 7.  Is that what it's
supposed to do?

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Thorsten Froehlich wrote:
> 
> > (probably because of the function declaration problems)
> 
> No, those should be gone.
> 

But anyway it crashes during parsing, i will make further tests soon.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3BDFCA05.E3A43A0A@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> and produces different results with beta 6 and beta 7.  Is that what it's
> supposed to do?

Yes, because not specifying max_gradient always used to have some hard to
predict consequences (also users never noticed) going back as far as the
original isosurface code.  It would basically behave different depending on
max_gradient being specified or not, even if the specified max_gradient was
the same as the default.  You probably never noticed, but if max_gradient is
set (this goes for the original code as well), the values you specify after
eval(uate) did not change anything.

This has been corrected and it now works the same all the time except for
the above problem in beta 7.  However, I am still trying to determine other
side effects of the final change (not in beta 7).


    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: * Warp: Do a sync (get change 1235) to try it.

  Ok, I did it, and there clearly is a difference.
  I tested with this small example:

#include "functions.inc"

camera { location -z*5 look_at 0 angle 35 }
light_source { <100,200,-300>, 1 }

isosurface
{ function { x^2+y^2+z^2-(1-.2*f_noise3d(x*8,y*8,z*8)) }
  contained_by { sphere { 0,1 } }
  max_gradient 2
  evaluate 1,10,.99
  pigment { rgb x } finish { specular .5 }
}


  The older version (ie. beta7) rendered that in 1 min 30 seconds in this
computer. The report was a bit odd:

Warning: The maximum gradient found was 3.555, but max_gradient of
the isosurface was set to 310.201. Adjust max_gradient to
get a faster rendering of the isosurface.

  The newer version renders the example above in 13 seconds, which is a clear
improvement.

Warning: The maximum gradient found was 3.477, but max_gradient of the
isosurface was set to 2.000. The isosurface may contain holes!
Adjust max_gradient to get a proper rendering of the isosurface.

  The max_gradient value of 3.477 seems to be correct. When I set max_gradient
to that, the isosurface renders ok.

  It seems that now 'evaluate' doesn't actually change the max_gradient, but
just calculates the correct one and reports it. The example above renders
equally whether or not the 'evaluate' is there.
  This behaviour seems logical to me.

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

Warp <war### [at] tagpovrayorg> wrote:
:   It seems that now 'evaluate' doesn't actually change the max_gradient, but
: just calculates the correct one and reports it. The example above renders
: equally whether or not the 'evaluate' is there.
:   This behaviour seems logical to me.

  By the way, what is really good about this new behaviour is that now you
can leave the 'evaluate' after you have fixed the 'max_gradient' to the
proper value and it will not affect the render (eg. by slowing it).

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

On 31 Oct 2001 10:25:46 -0500, Warp <war### [at] tagpovrayorg> wrote:
>  By the way, what is really good about this new behaviour is that now you
> can leave the 'evaluate' after you have fixed the 'max_gradient' to the
> proper value and it will not affect the render (eg. by slowing it).

does it mean correct 'max_gradient' is known/calculated
before render ????? then can be message about bad value of it
displayed before render instead after ? or is it just well optimized
algorithm ?

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

Thorsten Froehlich wrote:
> 
> Yes, because not specifying max_gradient always used to have some hard to
> predict consequences (also users never noticed) going back as far as the
> original isosurface code.

This seems to be exactly the case when using 'evaluate' can be faster than
a specified max_gradient.  See also R. Suzuki's recent post concerning
this:

news://news.povray.org/3bd7f6e8%241%40news.povray.org  

I hope this possibility is not removed with the new changes.

> It would basically behave different depending on
> max_gradient being specified or not, even if the specified max_gradient was
> the same as the default.  You probably never noticed, but if max_gradient is
> set (this goes for the original code as well), the values you specify after
> eval(uate) did not change anything.
> 
> This has been corrected and it now works the same all the time except for
> the above problem in beta 7.  However, I am still trying to determine other
> side effects of the final change (not in beta 7).
> 

So there is no difference between specifying max_gradient 1.1 or not now,
even if you use 'evaluate'?

Then one thing wonders me: what's the difference between the first
parameter of 'evaluate' and the max_gradient value if both are specified?

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

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

> :   It seems that now 'evaluate' doesn't actually change the max_gradient, but
> : just calculates the correct one and reports it. The example above renders
> : equally whether or not the 'evaluate' is there.
> :   This behaviour seems logical to me.
>
>   By the way, what is really good about this new behaviour is that now you
> can leave the 'evaluate' after you have fixed the 'max_gradient' to the
> proper value and it will not affect the render (eg. by slowing it).

(This is only relevant for Warp as he has access to code newer than beta 7)

Actually it doesn't matter if you have evaluate in there at all now. As far
as reporting the found maximum gradient is concerned, it now uses some
estimation* as to what can be considered a significant difference and only
(but always) reports the suggested maximum gradient.

The only additional (computational) cost is one floating-point subtraction,
multiplication, division and absolute value in each step of the recursive
root finding process.   It might be that this is still a lot so there might
be need for further changes, or it might turn out that the time impact of
this change is so small that it won't matter too much.

Of course the benefit of removing the need for evaluate all together is that
POV-Ray will now always issue a warning if there is a problem, which in turn
should also reduce problems found by new users who forgot to use evaluate.
While the holes won't go away magically, the warning after rendering will be
a good hint if something is wrong.


    Thorsten


* Absolute differences of +-10 or relative difference of +-10% but not less
than +-0.5 absolute difference will cause the warning.

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <d960ut4onfjvmq63jku0rgsuh4g7umob8k@4ax.com> , W„odzimierz ABX 
Skiba <abx### [at] babilonorg>  wrote:

>>  By the way, what is really good about this new behaviour is that now you
>> can leave the 'evaluate' after you have fixed the 'max_gradient' to the
>> proper value and it will not affect the render (eg. by slowing it).
>
> does it mean correct 'max_gradient' is known/calculated
> before render ????? then can be message about bad value of it
> displayed before render instead after ? or is it just well optimized
> algorithm ?

No, the gradient is calculated while going through the root finding process,
which is used to find intersections.  So finding a good max gradient before
is not (yet) possible.

However, I have been thinking about a "new" evaluate that attempts to guess
a good initial max gradient by shooting a few random rays into the object.
It would basically called "evaluate" again with one parameter specified that
would be the number of rays to shoot (or something close to that).  There
are of course some problems with such an approach (and I am aware of them),
but it would at least improve development speed as full tracing of the
isosurface would no longer be necessary.  Anyway, this change might not be
suitable for 3.5 this late -- it would do more than the current changes
which are fixing long standing problems and inconsistencies...


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3BE02432.BB253085@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> This seems to be exactly the case when using 'evaluate' can be faster than
> a specified max_gradient.  See also R. Suzuki's recent post concerning
> this:
>
> news://news.povray.org/3bd7f6e8%241%40news.povray.org
>
> I hope this possibility is not removed with the new changes.

It is because it was never documented anywhere so I assumed it was an
inconsistent behavior in the code.  Nothing keeping me from adding it again,
of course.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3BE02432.BB253085@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> So there is no difference between specifying max_gradient 1.1 or not now,
> even if you use 'evaluate'?

Yes, but ignore the beta 7 implementation details as they are not complete
yet.  The main idea was to get some feedback on the changes, but of course I
didn't take into account the problem that was left in there.

What is happening is that the "adaptive max_gradient technique" as Mr.
Suzuki calls it, is now always used partially.  Unfortunately this causes
the max_gradient to grow and thus cause the slowdown people report with
evaluate.

> Then one thing wonders me: what's the difference between the first
> parameter of 'evaluate' and the max_gradient value if both are specified?

I have a good idea how the code works, but not what the individual values of
evaluate will exactly do to what surface, if that is what you are asking.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> It is because it was never documented anywhere so I assumed it was an
> inconsistent behavior in the code.  Nothing keeping me from adding it again,
> of course.
> 

Great,

in fact it is documented in one sentence in the isosurface SDL part:

"When using only the evaluate keyword without max_gradient, POV-Ray will
try 
to estimate a default max_gradient."

I could write some more things concerning 'evaluate' in the isosurface
tutorial as soon as the code for it is somehow 'definitive', in fact i
never liked that part as it is now, but i did not feel competent enough to
write something better.

Would that be a good idea?

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3BE02D4D.137B24B5@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> in fact it is documented in one sentence in the isosurface SDL part:
>
> "When using only the evaluate keyword without max_gradient, POV-Ray will
> try
> to estimate a default max_gradient."
>
> I could write some more things concerning 'evaluate' in the isosurface
> tutorial as soon as the code for it is somehow 'definitive', in fact i
> never liked that part as it is now, but i did not feel competent enough to
> write something better.
>
> Would that be a good idea?

Yes, especially because I had always been working on the code assuming there
would be two behaviors.  The one with evaluate and the one without.  Well,
it really turned out to be 2.5 different behaviors.  One was no evaluate and
some max_gradient (or the default one), the second was evaluate with
max_gradient which would simply print the gradient found but ignore the
evaluate parameters, and the last but not least max_gradient being adapted
by the evaluate parameters.  I read the documentation for isosurfaces more
than once, but I never noticed that particular difference until I looked
very closely into the code...


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> Yes, but ignore the beta 7 implementation details as they are not complete
> yet.  The main idea was to get some feedback on the changes, but of course I
> didn't take into account the problem that was left in there.

Ok, that's clear.

> What is happening is that the "adaptive max_gradient technique" as Mr.
> Suzuki calls it, is now always used partially.  Unfortunately this causes
> the max_gradient to grow and thus cause the slowdown people report with
> evaluate.

I think that's what you can influence with the second and third parameter
of 'evaluate', i was just starting to explore it.

> > Then one thing wonders me: what's the difference between the first
> > parameter of 'evaluate' and the max_gradient value if both are specified?
> 
> I have a good idea how the code works, but not what the individual values of
> evaluate will exactly do to what surface, if that is what you are asking.
> 

Yes, as i understand it, it's a starting value for the estimation
process.  So the following view should be correct:

- with only max_gradient, Povray 'blindly' renders the isosurface.

- with max_gradient specified and using 'evaluate' the max_gradient stays
fixed for the render, but Povray suggests a new value (like Warp described
in the other thread)

- without max_gradient, Povray uses an 'adaptive max_gradient technique'
or 'estimation technique' and uses the first parameter from 'evaluate' as
a starting value.

I think this is also what is essentially written in the isosurface SDL
docs (written by René Smellenbergh IIRC) but very short and condensed, so
i will try to work out something for the tutorial (referring to your other
post)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3BE03202.1171E1E3@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> - with only max_gradient, Povray 'blindly' renders the isosurface.
>
> - with max_gradient specified and using 'evaluate' the max_gradient stays
> fixed for the render, but Povray suggests a new value (like Warp described
> in the other thread)
>
> - without max_gradient, Povray uses an 'adaptive max_gradient technique'
> or 'estimation technique' and uses the first parameter from 'evaluate' as
> a starting value.
>
> I think this is also what is essentially written in the isosurface SDL
> docs

The new way will (probably) merge 1 and 2.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: Actually it doesn't matter if you have evaluate in there at all now. As far
: as reporting the found maximum gradient is concerned, it now uses some
: estimation* as to what can be considered a significant difference and only
: (but always) reports the suggested maximum gradient.

  So the evaluate keyword is currently obsolete (and actually not used
for everything)?
  If it doesn't slow the rendering of the isosurface by any considerable
amount then I think that it's a very good approach.

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

Hi,
I am sorry for the delay in responding to these messages because I
am somewhat busy due to other works.

>It is because it was never documented anywhere so I assumed
>it was an inconsistent behavior in the code.

I have sent an old paper, which describes the algorism of isosurface
root finding and the dynamic (or adaptive) maximum gradient
estimation method, to you (Thorsten)  by e-mail a few months ago.

I have not written the description on my web because the paper
has not been published.  But maybe it's time to open it.
It is very simple as following.

**** Dynamic maximum gradient estimation *****
max_gradient G_max
"eval(uate) P0, P1, P2"
where
  P0 is the minimum max_gradient value in the estimation process,
  P1 should be more than 1 (over-estimation parameter), and
  P2 should be less than 1 (attenuation parameter).

The max_gradient, G_max, is re-calculated for each ray as following
        If (G_max< G*P1)
             then   G_max = G*P1*P1
             else if (G_max>P0) then G_max = G_max*P2,

where G is the calculated maximum gradient of one ray.

If the gradient changes smoothly in the whole region, we can lower
the above parameters.  As a result, we can accelerate the rendering
speed. But if there are large discontinuities in the 'gradient',
it may not work for low values.
----------

This method has two purposes, one is evaluation of max_gradient,
and the other is acceleration of the rendering speed using the "else if"
part.
That part is removed (or P2=1) in beta 7, isn't it?

R. Suzuki

Post a reply to this message

In article <3be10cf9@news.povray.org> , "R. Suzuki" <r-s### [at] aistgojp> 
wrote:

> I have sent an old paper, which describes the algorism of isosurface
> root finding and the dynamic (or adaptive) maximum gradient
> estimation method, to you (Thorsten)  by e-mail a few months ago.

Yes, I know that it talks about a dynamic method, but I didn't understand
that it was only supposed to work if no "max_gradient" was set and when
looking at the code it rather looked like a bug than a feature...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3be10cf9@news.povray.org> , "R. Suzuki" <r-s### [at] aistgojp> 
wrote:

> That part is removed (or P2=1) in beta 7, isn't it?

Yes and no.  A part is missing, but not all of it.  The part in ...Find_Root
is disabled, but the part in ...Find_Root_R is always on when evaluate is
used.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message