> 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
>
>
>
It's not often that you see Julia fractals using something else than 
quaternions, and most of the time, they use sqr.

I don't think that fixing those bugs will break anything as the bugs 
where probably why the Julia fractal was underused.

Post a reply to this message