> High!
>
> clipka wrote:
>> To me these images look like you definitely have /some/ kind of
>> precision problem there. Looks to me like POV-Ray doesn't get enough
>> "potential difference" for normals computation. Maybe making the
>> isosurface function "sharper" might help somehow (if you know what I
>> mean).
>
> Normals? The texture of the isosurface doesn't contain any normal
> statement... and what do you mean with "sharper"? Adding more
> ruggedness, steeper ridges?

Obviously, with isosurfaces POV-Ray needs to have /some/ way of 
determining which direction the surface is facing at any intersection 
point it finds (the so-called "[unpertubed] surface normal vector").

To do this, AFAIK POV-Ray samples the function value of a few other 
points nearby, and from the difference in the function value computes 
the normal vector.

Now imagine what happens if the nearby points return values like:

  0.00000000000[01235]
  0.00000000000[42260]
  0.00000000001[73450]
-0.00000000000[03345]

(assuming your threshold is 0.0), with the digits in square brackets 
being lost due to rounding issues or some such.

With the function values of the nearby points varying only between 0, 
1e-11 and -1e-11, you can probably imagine that the normals computed 
from these values will be confined to a very small set of directions (I 
guess mainly parallel to the coordinate axes or tilted by 45 degrees), 
and subject to a lot of random noise.

If this should be the cause of your artifacts, it might help to modify 
the functions so that the function values increase in absolute 
magnitude, e.g.:

  0.00000000001[235]
  0.00000000042[260]
  0.00000000073[450]
-0.00000000003[345]

Then again, maybe the rounding happens somewhere else in the function. 
In that case you might need to get a clear picture of where exactly you 
lose precision in there.

(The most "precision-eating" operations in floating-point math are sums 
(or differences) of values with very different orders of magnitude.)

Post a reply to this message