Alain <kua### [at] videotronca> wrote:
> Le 15-06-28 03:58, clipka a écrit :
> > Overhauling the POV-Ray codebase, I've stumbled across something
> > surprising (to me) in the implementation of the fractal currently
> > implemented via the `HypercomplexFunctionFractalRules` type. Can someone
> > with a bit of "fractal fu" please help me and test this out?
> >
> > In SDL parlance, that should be any fractal using:
> >
> >      julia_fractal {
> >        ...
> >        hypercomplex FUNCTION
> >        ...
> >      }
> >
> > where FUNCTION is any of:
> >
> >      acos
> >      acosh
> >      asin
> >      asinh
> >      atan
> >      atanh
> >      cosh
> >      cos
> >      exp
> >      ln
> >      pwr(FLOAT,FLOAT)
> >      sin
> >      sinh
> >      tan
> >      tanh
> >
> > Please tell me whether you think the results are ok or bogus.
> >
>
> The oddity may explain the strange results I got a while back when
> testing those functions.
> I got missmatched dirrect image, shadows and reflection.
> Often, it looked as is I was looking at the inside surfaces.
> The self shadowing was often just plain wrong.
>
> I still have the images and code and may post them if asked.
>
>
> Alain

There are actually quite a few bugs, not only in the hypercomplex code, but the
quaternion code as well.  I've been going through the code myself, and, alas,
the Y / Z typo is just the beginning.  (I actually started this to implement the
rest of the functions for quaternions.  I didn't mean to get in so deep, but...
well, here I am.)  To wit (I think this is all of them):

* The last iteration is not checked against the bailout in any of the
julia_fractal codes (which is wrong), although the normal is computed off of the
last iteration (which is only sometimes right; see below)
* The normal is computed off of the last iteration, which is only correct if the
last iteration was the one that produced that portion of the surface (this falls
apart, for instance, with the reciprocal type)
* The distance estimator fails to include the bailout in its calculations (this
does not apply necessarily to quaternions)
* The distance estimator (as implemented) fails to assist until it estimates
that the distance remaining is less than 30 times the precision
* None of the normal calculations take into account the slicing
* The intersection code pretty much always will miss intersections that occur at
the edge of the fractal when leaving it and sometimes when entering it
* Hypercomplex cube is actually sqr
* There are oddities in the computation of acos and acosh due to branch cut
issues
* Discontinuities of the iterated function are not accounted for when computing
normals

And ...

* The normal calculations for pretty much all of the hypercomplex fractals
(excluding sqr and exp) are broken: the function value is used where the
derivative should be

To make matters somewhat worse, these bugs are all present in the code for
version 3.0, meaning that fixing things will affect scenes that far back.

To the best of my knowledge, though, the rest is correct (with the possible
exception of the distance estimators for the quaternions, which I am still
working on figuring out).


So, no, it's not just you.


A couple of fairly easy ways to verify some of the problems:

Render a hypercomplex sqr fractal.
Render again with cube instead of sqr.  (You get the *same* result as before.)
Render again, with pwr(2,0) instead.  (You *don't* get the same result.  Same
shape, but different shading.)

Render a hypercomplex sin fractal with max_iteration 1, parameter 0, and
standard slicing (i.e., t).  (You get a sphere of radius 4 with funky shading,
half of it missing in a random-looking fashion, and no back side.)


Anyways, I've actually been working on writing a corrected version to work with
the current git source, and am mostly done -- meaning that everything works fine
(so far), but more testing and documentation would be good, and another look at
optimization might be worthwhile.  If anyone would like to check my work, I
would be most appreciative.  (Also, if anyone knows what the best way would be
for me to contribute this for review / use / whatever, let me know.  I'm
thinking that a pull request on GitHub is probably the correct way, but I'm not
sure.)


Ben Small

Post a reply to this message