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