Wasn't it Thorsten Froehlich who wrote:
>In article <3bb0e726@news.povray.org> , "Marc-Hendrik Bremer" 
><Mar### [at] t-onlinede> wrote:
>
>> It reports something around 95.7 which is probably not too high with a
>> crackle-function in the Iso. But that max_gradient of 5 is too low in this
>> case. I don't know why dAWiDi thinks that the object is not complex enough
>> to go under 10 PPS.
>
>No, 95 sounds good for crackle.  So in summary the problem reported by
>"dAWiDi" <pov### [at] xxs-swpde> is a user error.  The suggested solution is
>to use an appropriate max_gradient and to read the documentation.

The symptoms don't sound anything remotely like the effects that
normally occur with an insufficient max_gradient.

There are max_gradient artefacts in the scene (tiny black holes near the
tips of the crackly bit) but they don't change significantly when the
render size is changed, and they certainly don't change at all between
the rendering of a partial scene and rendering the full scene.

I haven't yet tried rendering the full scene at 1024x768 AA, but I did
try ripping out some of the go-slow features of the scene to see if the
problem could be reproduced without the fog, the complicated sky pigment
and the reflective texture on the isosurface. The expected max_gradient
artefacts were visible, but nothing like the reported problem occurred.

The fact that changing max_gradient happens to fix it may well be
coincidental, in the same way that removing the sky, fog and reflection
happen to fix it.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

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

> : Warp, do you think you could write and add such a FAQ entry, please?
>
>   Of course I could.

Will you?


____________________________________________________
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 <e0Z### [at] econymdemoncouk> , Mike Williams 
<mik### [at] nospamplease>  wrote:

> The symptoms don't sound anything remotely like the effects that
> normally occur with an insufficient max_gradient.

There is nothing else in the intersection code that could cause this find of
effect only appear after a specific output size as the code could not care
less of the output size.  And the original user's guess that it is a "memory
leak" is plain nonsense because those don't have this kind effect.

However, max_gradient can have this kind effect on certain patterns, so it
is max_gradient, really!

    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:
: Will you?

  I did it already (you can look at at at
http://www.students.tut.fi/~warp/povVFAQ/languageVFAQ.html#isosurfacebug).

  I'll wait until closer to the final 3.5 in order to submit it to Chris
so that I don't burden him with continuous updates. (Or should I send it
anyways right now?)

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

Mike Williams schrieb ...
>The symptoms don't sound anything remotely like the effects that
>normally occur with an insufficient max_gradient.
>


You are right, not max_gradient was the problem, but accuracy was. I
decreased it by a factor of 100 (accuracy 0.000005) while leaving
max_gradient at 5 and the 640x480 render did not show any of the effects.
Neither did a 1024x768 one. It wasn't even very slow - some 125 pps on my
PII450 for the 1024x768 render.

Marc-Hendrik

PII450 128 MB Win 98 Pov3.5 beta 4

Post a reply to this message

Wasn't it Mike Williams who wrote:
>Wasn't it Thorsten Froehlich who wrote:
>>In article <3bb0e726@news.povray.org> , "Marc-Hendrik Bremer" 
>><Mar### [at] t-onlinede> wrote:
>>
>>> It reports something around 95.7 which is probably not too high with a
>>> crackle-function in the Iso. But that max_gradient of 5 is too low in this
>>> case. I don't know why dAWiDi thinks that the object is not complex enough
>>> to go under 10 PPS.
>>
>>No, 95 sounds good for crackle.  So in summary the problem reported by
>>"dAWiDi" <pov### [at] xxs-swpde> is a user error.  The suggested solution is
>>to use an appropriate max_gradient and to read the documentation.
>
>The symptoms don't sound anything remotely like the effects that
>normally occur with an insufficient max_gradient.
>
>There are max_gradient artefacts in the scene (tiny black holes near the
>tips of the crackly bit) but they don't change significantly when the
>render size is changed, and they certainly don't change at all between
>the rendering of a partial scene and rendering the full scene.
>
>I haven't yet tried rendering the full scene at 1024x768 AA, but I did
>try ripping out some of the go-slow features of the scene to see if the
>problem could be reproduced without the fog, the complicated sky pigment
>and the reflective texture on the isosurface. The expected max_gradient
>artefacts were visible, but nothing like the reported problem occurred.
>
>The fact that changing max_gradient happens to fix it may well be
>coincidental, in the same way that removing the sky, fog and reflection
>happen to fix it.

I've now had time to explore the situation more fully. It turns out that
*some* partial renders do exhibit the problem, and I was therefore able
to reproduce the situation in renders that took only a couple of minutes
and experiment with changing aspects of the scene to see when the
problem went away.

Changing the following aspects of the scene had no effect on the
problem:

1.      Removing the fog

2.      Removing the global_settings

3.      Removing the sky_sphere

4.      Removing all but one of the light_sources

5.      Removing #include "textures.inc"

6.      Reducing the image size to 800x600

7.      Increasing the accuracy from 0.0005 to 0.0004

Changing the following aspects of the scene caused the scene to render
without the problem:

8.      Changing the texture of the isosurface from "Silver_Metal" to 
        {pigment {rgb 1}}
        * but adding {finish {reflection 0.25}} caused the problem to 
        recur.

9.      Rendering without anti aliassing

10.     Reducing the image size to 640x480 or less

11.     Increasing max_gradient from 5 to 6

12.     Decreasing max_gradient from 5 to 4

13.     Decreasing the accuracy from 0.0005 to 0.0006

14.     Increasing the accuracy from 0.0005 to 0.0001
        (compare this with point number 7!)

15.     Moving all the #declares outside the isosurface{} block

16.     Simplifying the isosurface function.

17.     Removing the three blank lines between the '//+sc...' and the
        '#include "colors.inc"' (!)

I also noticed that the problem always occurred when the render reached
37% completion. I never saw a render fail before 37%, and if it reached
38% without error it always went on to complete successfully. Once the
render reaches this point, the remaining 63% of the scene renders in
about a further 2 seconds. The lower 63% of the scene is equal to the
background colour.

The symptoms look absolutely nothing like the usual artefacts that you
get when you use an incorrect max_gradient.

Here's my simplified version of the scene which reproduces the problem,
and the command line settings that I used. The partial render,
exhibiting the problem, completes in 67 seconds on my machine, which
should make it easier to work with than the original version.

POV 3.5b4, W98se, AMD K6-2 500, 128Mb.


//+sc0.40 +ec0.42 +h600 +w800 +a0.3



#include "colors.inc"
camera {location <-4,4,-5>
        angle 60
        look_at <0,-.5,0>
        }
light_source {<-15,100,5> color rgb 0.7}

background{color rgb <0,0,1>}

#declare testfunki=function{pattern{crackle}}

object{isosurface{
#declare pattskali=3;
#declare Blob_threshold=0.1;
#declare Funki1=function{ y-1*(sin(x)*cos(z*x/5))}
#declare Funki2=function{ 
sqrt(x^2+(y-.6)^2+z^2)-1.5-.2*testfunki(x*pattskali,y*pattskali,z*pattsk
ali)}
function{(1+Blob_threshold)-Blob_threshold^Funki1(x,y,z)-Blob_threshold^
Funki2(x,y,z)}
contained_by{box{<-5,-1.01,-6>, <18,3,20>}}
max_gradient 5
threshold 0
accuracy 0.0005
}
texture{pigment {rgb 1} finish {reflection 0.25}}
}

Post a reply to this message

In article <1MkG+AAk### [at] econymdemoncouk> , Mike Williams 
<mik### [at] nospamplease>  wrote:

> 9.      Rendering without anti aliassing
>
> 10.     Reducing the image size to 640x480 or less
>
> 11.     Increasing max_gradient from 5 to 6
>
> 12.     Decreasing max_gradient from 5 to 4
>
> 13.     Decreasing the accuracy from 0.0005 to 0.0006
>
> 14.     Increasing the accuracy from 0.0005 to 0.0001
>         (compare this with point number 7!)

Well, crackle uses random numbers for some things internally.  The function
is basically unsuitable for an isosurface because the root finder will have
lots and lots of problems with it simply because of the nature of the
crackle function.

Changes in resolution will *change* the intersection points and thus the
calculation of the function value, even if it is off only by a single
changed bit in the coordinate, the resulting function will be different.
The reason behind this is that crackle makes a great pattern but a terrible
function for isosurfaces!

> 15.     Moving all the #declares outside the isosurface{} block

Depending on what you do, this can also change the floating-point function
and thus changes the accuracy due to floating-point arithmetic.

> 16.     Simplifying the isosurface function.

Yes, because simplifying the function changes the accuracy due to
floating-point arithmetic.

> 17.     Removing the three blank lines between the '//+sc...' and the
>         '#include "colors.inc"' (!)

This does not make any sense at all :-(  If this would make a difference,
there would be a bug in the tokenizer that would be so serious that hardly
any scene would work at all!!!  Obviously this is not the case...


    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 schrieb in Nachricht <3bb22d1a$1@news.povray.org>...
>> 17.     Removing the three blank lines between the '//+sc...' and the
>>         '#include "colors.inc"' (!)
>
>This does not make any sense at all :-(  If this would make a difference,
>there would be a bug in the tokenizer that would be so serious that hardly
>any scene would work at all!!!  Obviously this is not the case...
>


I can confirm that those three lines make a difference. Don't know why, but
without them, the selected part renders fine, with them there is lots of
background blue.

Marc-Hendrik

Post a reply to this message

Wasn't it Thorsten Froehlich who wrote:

>Well, crackle uses random numbers for some things internally.  The function
>is basically unsuitable for an isosurface because the root finder will have
>lots and lots of problems with it simply because of the nature of the
>crackle function.
>
>Changes in resolution will *change* the intersection points and thus the
>calculation of the function value, even if it is off only by a single
>changed bit in the coordinate, the resulting function will be different.
>The reason behind this is that crackle makes a great pattern but a terrible
>function for isosurfaces!

I was beginning to develop a theory along those lines. Something like:-

  There's some magic number. When the root finder happens to see that  
  number during its calculations it dies and ignores the whole of the 
  rest of the surface. Slight changes in things like max_gradient, 
  accuracy cause the intersection point to change slightly and the magic 
  number doesn't happen. The magic number doesn't occur on the "actual"
  isosurface itself, but only in a reflection, The magic number doesn't
  occur in the centre of a pixel, but only on one of the extra off-
  centre rays used for antialiassing.

  I'd have guessed that there's some variable that the solver was 
  setting, indicating that it had given up trying to find a solution, 
  that it was failing to reset when it starts the next pixel, and it 
  therefore doesn't try to solve the isosurface in any other pixel of 
  the scene.
  
It almost makes sense. However, if that were the case, then I'd expect
to see the root solver die on any partial image render that included the
offending pixel. This is not the case. It wasn't easy to find any
partial render that exhibited the problem. The smaller partials that
I've tried, including the area around where it starts to go wrong, don't
exhibit the problem.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

In article <O+WoS### [at] econymdemoncouk> , Mike Williams 
<mik### [at] nospamplease>  wrote:

> It almost makes sense. However, if that were the case, then I'd expect
> to see the root solver die on any partial image render that included the
> offending pixel. This is not the case. It wasn't easy to find any
> partial render that exhibited the problem. The smaller partials that
> I've tried, including the area around where it starts to go wrong, don't
> exhibit the problem.

The random number stuff inside POV-Ray can really be complicated sometimes.
I do know that the way you render something can have an effect on the result
with the "more" random patterns.  As I never looked into any part of that
code I do not know what in particular happens for each and every request to
evaluate a pattern at a specific point.  You have to see the random numbers
simply as a stream on numbers.  Every time you start a render you start at a
particular position in the stream (which may or may not be the same, I don't
know).  So, as for every different starting point a different number of
random numbers is requested, the effect changes its position and so on.

Anyway, I am really not the right person to explain how and why patterns
work the way they do...


    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