END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

Here is a 4D version of Twinbee's formula for squaring a 3D hypercomplex number:

Twinbee's original formula can be expressed in the form of rotational matrices applied to the square of the radius (real value):
{x,y,z}² = Rz(2*theta)*Ry(2*phi)*{r²,0,0}
where Ry and Rz are rotational matrices about the y and z axis, respectively, and:
r=sqrt(x²+y²+z²)
theta=atan2(y,x)
phi=atan2(sqrt(x²+y²),z)

This can be expanded to give:
{x,y,z}² = r²*{cos(2*phi)*cos(2*theta), cos(2*phi)*sin(2*theta), sin(2*phi)}

This simplifies to:
{x,y,z}² = {(x²-y²)*a, 2*x*y*a, -2*z*sqrt(x²+y²)}
where a=1-z²/(x²+y²)

In 4D, rotation is about a plane so now there are 6 possible rotational matrices to choose from: Rxy, Ryz, Rxz, Rxw, Ryw, Rzw. Following this train of thought, I came up with the following 4D analog to Twinbee's formula by applying three consecutive 4D rotations:
{x,y,z,w}² = Rxy(2*theta)*Rxz(2*phi)*Rxw(2*psi)*{r²,0,0,0}
where
r=sqrt(x²+y²+z²+w²)
theta=atan2(y,x)
phi=atan2(sqrt(x²+y²),z)
psi=atan2(sqrt(x²+y²+z²),z)

This can be expanded to give:
{x,y,z,w}² = r²*{cos(2*psi)*cos(2*phi)*cos(2*theta), cos(2*psi)*cos(2*phi)*sin(2*theta), -cos(2*psi)*sin(2*phi), sin(2*psi)}

This formula reduces to Daniel's squaring function when w = 0 and reduces to the standard complex squaring function when w = z = 0.

For faster calculations, this formula can be simplified to:
{x,y,z,w}² = {(x²-y²)*b, 2*x*y*b, -2*r2*z*a, 2*r3*w}
where
r2=sqrt(x²+y²)
r3=sqrt(x²+y²+z²)
a=1-w²/r3²
b=a*(1-z²/r2²)

Using this formula, I rendered 3D slices of this 4D Mandelbrot fractal at w = 0, z = 0, y = 0, x = 0:

Hello Bugman
I'm very very impressed when I look at your renders. You are very good in 3D fractal rendering and I think we have to learn from you :-). I looked at you website http://bugman123.com and I see that you have big collection of fractals also 3D and very interesting physics simulations. I'm waiting for some animations with hypercomplex fractals made by you.

heya paul, good to see you on the forums

sorry for nitpicking, but the "foggy" rendering method employed here isn't really participating media in the technical sense of the word (it is not approximating the physics of light transport); having said that, it does look really cool, and has the distinct advantage of being waaaay faster!

about the BVH, that's just my interpretation of how Hart's method works - it implicitly creates a BVH using the IFS transformations during traversal.

looking forward to more cool renders guys! 

Hi, that's basically the problem I found as well - using the derivative just doesn't work for that particular hypercomplex method, but it works for these:

http://home.comcast.net/~cmdaven/hyprcplx.htm

> Could you describe what you mean?

To use deltas I iterate at two points on the ray at each step, the current point and the current point plus a little bit, I then basically use the smooth iteration value from each of those iterations to calculate the distance estimate on which my next step distance is based.
If the smooth iteration count at the point is s0 and the smooth iteration count at the point plus a very small step along the ray (here 1e-10) is s1 then I use either

                    estimate = (s0+maxiter)/(maxiter+((1.0e10*maxiter)*abs(s1-s0)))
            or
                    estimate = 1.0/(1.0+((1.0e10)*abs(s1-s0)))

I also have another version that's based on quadratics but that requires another iteration for each step (either at current point-a bit or at current point + 2*a bit).

The main problem with these methods is that when a ray just misses the "solid" then the calculated estimate just after passing the solid gets much too large, the solution I found was that for each ray before you adjust your estimate (from the above) to give a step distance check the estimate against a current minimum for this ray at this iteration depth and if the previously stored step minimum for the iteration depth is less than the new value then use the previous value, otherwise store the new value as the minimum for this iteration depth.

I've still got the odd bug in the algorithm - sometimes it ends up in an infinite loop stepping zero, a situation that's not that easy to debug in UF (it's easy to fix with a fudge but I want to find out what's causing the problem).
Also I still haven't decided which of the two methods above is the better, though I've just about ruled out the quadratic method (mainly for speed reasons).

Actually I have released a colouring formula to the UF formula database that basically uses the second method I gave in my other reply - the colouring is a class colouring "MMF Directional Distance Estimator" in mmf.ulb. It just ray-traces in 2D.

Hi, I just made the odd slight change to my algorithm - the problem was with something I hadn't mentioned that's not really relevant - it was an optimisation attempt that obviously failed

Anyway I just retested rendering a quaternion using the 3 delta methods I mentioned previously (i.e. including the quadratic one) against using standard quaternionic DE.
I adjusted the "minimum distance" values in each case so the visual results were as close as possible and got the following timings:

Standard DE: 14.6s
Quadratic: 39.5s
Newton 1: 25.5s
Newton 2: 26.2s

The visual result for the delta methods was best for the Newton 2 method (I say Newton as they are based loosely on using Newton's formula) and as that's almost as fast as Newton 1 it's the method I will impliment in publicly released formulas.

Actually Newton 2 is the simpler method, i.e. using:

         estimate = 1.0/(1.0+((1.0e10)*abs(s1-s0)))

where 1e10 is 1/1e-10 where 1e-10 is the "bit extra" along the ray, s0 is the smooth iteration at the current point and s1 is the smooth iteration at the current point plus the bit extra. It's actually basically the method I used in the 2D directional distance estimator colouring.

Note that in the 3D version I actually convert the estimate to a step distance by dividing the estimate by (2.5*@scale) where @scale is a user parameter allowing a user to control the accuracy/render speed - a value of 1.0 was used in the testing, this gives pretty accurate result fairly quickly but using @scale values up to about 4 will improve results though obviously at the cost of longer render times.

Wow, how awesome is that?! For all those frames one would think you're using a 40-core from the future. And in your own raytracer too. Did you use global illumination?

respects budhi!