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

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