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

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