A Mandelbox distance estimate formula

[KRAFTWERK]

Cool Subblue, nice images!

J

[Buddhi]

Thanks for the DE tip Buddhi. I'm working on a Mandelbox version of my PixelBender script. So far it is actually noticeably slower than the Mandelbulb so I've still a way to go optimising it, but the results are pretty interesting so far!

Mandelbox is slower than Mandelbulb because it needs much more higher numbers of iterations. Average iteration count for most of Mandelbulbs is around 3-4 but for Mandelbox is around 15-40. I think the next reason of slower rendering with PixelBleder script is that the Mandelbox formula has many conditions and GPUs are not efficient with that kind of code.

[David Makin]

Hi all, I have now implimented Buddhi's method and after thorough testing found that unlike the IFS (Simple Sierps) in my formula Buddhi's method works best on the Mandelbox if the "log(cabs(z))" is included in the DE calculation i.e.

DE = log(magnitude(z))*magnitude(z)/dr

Where dr is the running derivative magnitude from the iteration as described by Buddhi in this thread (except with the initial dr=scale before/outside the iteration loop).

However the problems with the value go further than just issues with smaller scales, the DE value appears to vary considerably from one area of a Mandelbox to another, for instance on a Mandelbox with scale -1.7 I found that in one area the "solid" positions found for thresholds 1e-2, 1e-3 and 1e-4 where very consistent with the position found for 1e-8 but at another location on the same Mandelbox they were well out, by up to a factor of over 100 for the 1e-4 threshold as compared to the 1e-8, in fact in general for that particular render of the -1.7 Mandelbox I had to reduce the threshold by 100* compared to normal to get close renders.

Will update the released version of the formula shortly.

[JosLeys]

I find that using just DE=magnitude(z)/dr works without any problems and is very fast.
Taking DE = log(magnitude(z))*magnitude(z)/dr increases DE and requires a tempering factor <1 as otherwise it will overshoot in some areas.

[bib]

I like the first image above. Looks like bricks of Lego

[cKleinhuis]

i do hope you make it public soon subblue

[subblue]

Mandelbox is slower than Mandelbulb because it needs much more higher numbers of iterations. Average iteration count for most of Mandelbulbs is around 3-4 but for Mandelbox is around 15-40. I think the next reason of slower rendering with PixelBleder script is that the Mandelbox formula has many conditions and GPUs are not efficient with that kind of code.

I'm managing to get reasonable results with iteration counts of around 15-20, and interaction rates of 2-3 fps at 640x480, but you're right about GPUs not handling scripts with lots of conditional execution routes routes well.

i do hope you make it public soon subblue

There is something odd going on with the script at the moment causing complete GPU lockup forcing hard reboot - not a pleasant experience! I might have to look at a different implementation route before it's stable enough for release.

[knighty]

Hi,
It's possible to avoid coditionnals by using abs(), sign() and step() functions:
- The box folding may be done with:
      x = sign(x) * (1 - abs(abs(x) - 1));
      y = sign(y) * (1 - abs(abs(y) - 1));
      z = sign(z) * (1 - abs(abs(z) - 1));
- For the sphere folding:
      a = step(mr2 , r2);
      b = step(fr2 , r2);
      sscl = fr2 / mr2 * (1 - a) + a * (1 - b) * fr2 / r2 + b;
      x *= sscl;
      y *= sscl;
      z *= sscl;
      DEfactor *= sscl;

Of course you can take advantage of vectorial operations on the GPU  

Let me suggest a variation of Buddhi's DE that seems to give better results.
(Original pseudo-code by Buddhi.)
_________________________________________________
DEfactor = 1.0; (Edit: it's the initial value)

inside iteration loop:

fixedRadius = 1.0;
fR2 = fixedRadius * fixedRadius;
minRadius = 0.5;
mR2 = minRadius * minRadius;

if (x > 1.0)
x = 2.0 - x;
else if (x < -1.0) x = -2.0 - x;
if (y > 1.0)
y = 2.0 - y;
else if (y < -1.0) y = -2.0 - y;
if (z > 1.0)
z = 2.0 - z;
else if (z < -1.0) z = -2.0 - z;

r2 = x*x + y*y + z*z;

if (r2 < mR2)
{
   x = x * fR2 / mR2;
   y = y * fR2 / mR2;
   z = z * fR2 / mR2;
   DEfactor = DEfactor * fR2 / mR2;
}
else if (r2 < fR2)
{
   x = x * fR2 / r2;
   y = y * fR2 / r2;
   z = z * fR2 / r2;
   DEfactor *= fR2 / r2;
}

x = x * scale + cx;
y = y * scale + cy;
z = z * scale + cz;
DEfactor = DEfactor * abs(scale) + 1.0;

resultant estimated distance (after iteration loop):

distance = (sqrt(x*x+y*y+z*z)-abs(scale-1))/abs(DEfactor) - abs(scale)^(1-i);
_________________________________________________

(Off topic question: Have anyone tried smooth foldings? Just Wondering what it would give)

[Timeroot]

knighty,

Do using those functions save any time? I know that, in general, functions are kind of slow to be called. For most, I bet they're handled internally with conditionals as well - they would only save time if the processor is prepared to grab the sign bit for them. & what do you mean, "smooth folding"? Folding is necessarily a sharp, discontinuous operation; Tglad designed the formula to keep it from ripping already. If you want to express it with some analytic function, you mean, you could always use something with hyperbolas, like

y=sqrt(a+(x+1)^2)-sqrt(a+(x-1)^2)-x

for a something like 0.05. Would actually be fun to try playing around with the Mandelbox for different values of a, see what shapes you get.

[David Makin]

Do using those functions save any time? I know that, in general, functions are kind of slow to be called. For most, I bet they're handled internally with conditionals as well - they would only save time if the processor is prepared to grab the sign bit for them

Knighty posted the alternative coding to avoid conditionals because conditionals are not friendly when it comes to GPU implimentation - on the GPU the method he suggested should be considerably faster I think (I can't check myself as I still don't have an appropriate video card installed).

[knighty]

I've just done some tests on my crap GeForce 8400. It turns out that the "optimisations" I've suggested to Sublue are in fact slower  .

Some renderings :
On cpu:


On GPU:

[Hamilton]

Ok, my turn to try out buddhi's DE tip...   
As you may guess, I used my own monte carlo raytracing renderer to get the attached image (mandelbox with scale -1.75) featuring HDR Image Based Lighting, Cook-Torrance BRDF for surface shading and adaptive antialiasing.
Still have to improve a few things and implement additionnal BRDF/BSDF to simulate more materials...

[KRAFTWERK]

Very nice image mr Hamilton!

[knighty]

Wow! superbe!

[Rrrola]

I'm using knighty's formula with the following GPU optimizations (fR2 is fixed to one):

  // precomputed somewhere
  vec4 scalevec = vec4(SCALE, SCALE, SCALE, abs(SCALE)) / MR2;
  float C1 = abs(SCALE-1.0), C2 = pow(abs(SCALE), float(1-iters));

  // distance estimate
  vec4 p = vec4(position.xyz, 1.0), p0 = vec4(position.xyz, 1.0);  // p.w is knighty's DEfactor
  for (int i=0; i<iters; i++) {
    p.xyz = clamp(p.xyz, -1.0, 1.0) * 2.0 - p.xyz;  // box fold: min3, max3, mad3
    float r2 = dot(p.xyz, p.xyz);  // dp3
    p.xyzw *= clamp(max(MR2/r2, MR2), 0.0, 1.0);  // sphere fold: div1, max1.sat, mul4
    p.xyzw = p*scalevec + p0;  // mad4
  }
  return (length(p.xyz) - C1) / p.w - C2;

This is fast because min, max and mad(multiply-add) are fast no-branching operations and output saturation (clamping between 0 and 1) is free. Making iters a constant unrolls the loop for another speedup.

I've found that the formula also works when p0.xyz≠position (e.g. for julias or various transformations/foldings) as long as you keep p0.w=1.

Alternative box folds (may be faster on some architectures):

    p.xyz = clamp(p.xyz *0.5+0.5, 0.0, 1.0) *4.0-2.0 - p.xyz;  // mad.sat, mad, add

    p.xyz = abs(1.0+p.xyz) - p.xyz - abs(1.0-p.xyz);  // add, add, abs.add, abs.add