Evalute 1,10,0.99 leads to strange results and slow renderings (I got 400
max_gradient ?!)
Shouldn't  1,1,0.99 be a good starting point? (1,10,0.99 is suggested by the
doc).

Sorry if this sounds like a silly question: what should isosurface speed
performances be campared to MegaPov's? I'm asking this because Warp's torus
(see image posted in p-b-i) takes more to render in POV 3.5.

Also (for Ingo) if you search for 'evaluate' in the index you are directed
to the right page but not to the very right spot.

Povray for windows v3.5b windowsme amdathlon 1000 256 megs

--
Jonathan

Post a reply to this message

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

> Evalute 1,10,0.99 leads to strange results and slow renderings (I got 400
> max_gradient ?!)

Well, if it suggests a gradient of 400 then your function probably has a
fairly big max_gradient.  it is normal that rendering is sow with evaluate,
so once you set the max_gradient and remove evaluate it should be much
faster.  Also note that not always the first found max_gradient by evaluate
will be the real maximum (also it should give good results without holes in
most cases) and it is possible that a bigger max_gradient is reported in
later renders.

> Shouldn't  1,1,0.99 be a good starting point? (1,10,0.99 is suggested by the
> doc).

For the "average" function yes, but not for all functions.

> Sorry if this sounds like a silly question: what should isosurface speed
> performances be campared to MegaPov's? I'm asking this because Warp's torus
> (see image posted in p-b-i) takes more to render in POV 3.5.

It depends on the complexity and some other factors.  More complex functions
will be much faster while very simple functions will be a bit slower because
of more overhead (that in turn allow faster complex isosurfaces).  Also,
functions that don't call other user defined function will be faster than
those that call lots of other user defined function.  Further, note that
function complexity limits are practically non-existing in POV-Ray 3.5
compared to the really simple functions that could be done with MegaPOV.


    Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: Well, if it suggests a gradient of 400 then your function probably has a
: fairly big max_gradient.

  It think there's something odd in the evaluating. I tried with that torus
and got some strange results.
  If I do not specify any max_gradient, in MegaPov 'eval' gives 2.514 as the
max_gradient, but in POV3.5 'evaluate 1,10,.99' gives 533! However, rendering
with the former gives a correct result even in POV3.5, so the 533 is obviously
wrong.
  If I, however, specify some max_gradient (eg 2.41) then evaluate in POV3.5 
gives 2.308, which makes more sense. MegaPov gives also a different
value, in this case 2.312, but still reasonable (although I don't understand
why it gives a different value).

  I can post the scene if you want to test.

-- 
#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 news:3b9a9a27@news.povray.org Warp wrote:

>   If I, however, specify some max_gradient (eg 2.41) then evaluate
>   in POV3.5 gives 2.308, which makes more sense.

Not completely sure, I think during pre-beta testing it was mentioned 
that while using evaluate, a value for max_gradient is also required. 
If this can be confirmed, I'll put it in the docs.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

>   It think there's something odd in the evaluating. I tried with that torus
> and got some strange results.

>   If I, however, specify some max_gradient (eg 2.41) then evaluate in POV3.5
> gives 2.308, which makes more sense. MegaPov gives also a different
> value, in this case 2.312, but still reasonable (although I don't understand
> why it gives a different value).

See  6.5.4.5.3 Maximum Gradient

You should *always* use max_gradient: even for the initial render with
evaluate. If you don't, POV3.5 will *estimate* a starting value which
might be way too high or too low, causing slowdowns and/or inaccuracies.
Use a max_gradient 5 or so to start, together with evaluate 1, 10, 0.99:
this will almost always give a reasonable result.
Then adjust max_gradient and the range of evaluate: a bit less than
found max gradient, a bit more than found max gradient, 0.99
You can even leave evaluate on, since it doesn't slow down the render
(hardly noticable anyway), as long as the max_gradient is accurate and
the evaluate range reasonably accurate.


-- 
e-mail:sme### [at] skynetbe

http://users.skynet.be/smellenbergh

Post a reply to this message

Wasn't it JRG who wrote:
>Evalute 1,10,0.99 leads to strange results and slow renderings (I got 400
>max_gradient ?!)
>Shouldn't  1,1,0.99 be a good starting point? (1,10,0.99 is suggested by the
>doc).

The MegaPOV "eval" defaults to 1,1.2,0.99 and that seemed to work pretty
well in the majority of cases.

In 3.5b1 you can sometimes get a reasonable compromise by specifying
*both* a max_gradient and an evaluate. By setting a low max_gradient and
a high evaluate you can sometimes get a grotty copy of the image to
render reasonably quickly and still give good evaluate information in
the messages pane.

>Sorry if this sounds like a silly question: what should isosurface speed
>performances be campared to MegaPov's? I'm asking this because Warp's torus
>(see image posted in p-b-i) takes more to render in POV 3.5.

Most of the time 3.5b1 is a little faster, but occasionally, for some
parametric isosurfaces, 3.5b1 is *phenomenally* slower.

I'm in the process of rewriting my Isosurface Tutorial scenes using the
3.5b1 syntax, and I've had to perform a considerable amount of
optimisation to render the Steiner Cross Cup in order to get the
rendering time under two hours for a 320x240 image without
antialiassing. 

At the current stage of tweaking, POV 3.5b1 takes 1h 36m 44s and MegaPOV
takes 1m 8s. That's a speed difference of 8500%. 3.5b1 is still showing
a few holes, so I guess it needs a slightly higher max_gradient and will
take even longer to render. (Evaluate isn't available for parametric
isosurfaces, and I don't know how to defferentiate the Steiner Cross
Cup, so I'm having to find a reasonable max_gradient by trial and
error.)

POV 3.5b1, Win 98se, AMD K6-2 500, 128Mb.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

On Sun, 9 Sep 2001 12:52:46 +0100, Mike Williams wrote:
>Most of the time 3.5b1 is a little faster, but occasionally, for some
>parametric isosurfaces, 3.5b1 is *phenomenally* slower.

Actually, it's probably phenomenally slower for most parametrics.  I would
be happy to correspond with you as to the details of why, if you think you
might have some suggestions that would help improve things.  We're lucky
it's even working at all in 3.5b1.

>a few holes, so I guess it needs a slightly higher max_gradient and will
>take even longer to render. (Evaluate isn't available for parametric
>isosurfaces, and I don't know how to defferentiate the Steiner Cross
>Cup, so I'm having to find a reasonable max_gradient by trial and
>error.)

Actually, what is called "max_gradient" for parametrics is the maximum of
the six partial derivatives dx/du, dy/du, dz/du, dx/dv, dy/dv, dz/dv.  
That might be easier to compute.  However, there is a bug in the current
implementation of parametric that leads to holes even if max_gradient is
big enough.  Making accuracy smaller helps with that, but also slows 
things down.

-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message