Logo by Mahmut - Contribute your own Logo!
News: Check out the originating "3d Mandelbulb" thread here
 
*
Welcome, Guest. Please login or register. April 28, 2017, 11:46:05 PM


Login with username, password and session length



Pages: 1 [2] 3   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: A Mandelbox distance estimate formula  (Read 25073 times)
0 Members and 1 Guest are viewing this topic.
KRAFTWERK
Global Moderator
Fractal Senior
******
Posts: 1427


Virtual Surreality


WWW
« Reply #15 on: April 01, 2010, 11:27:25 AM »

Cool Subblue, nice images!

J
Logged

Buddhi
Fractal Iambus
***
Posts: 853



WWW
« Reply #16 on: April 01, 2010, 12:14:21 PM »

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.
Logged

David Makin
Global Moderator
Fractal Senior
******
Posts: 2283



Makin' Magic Fractals
WWW
« Reply #17 on: April 01, 2010, 01:34:07 PM »

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.
Logged

The meaning and purpose of life is to give life purpose and meaning.

http://www.fractalgallery.co.uk/
"Makin' Magic Music" on Jango
JosLeys
Strange Attractor
***
Posts: 256


WWW
« Reply #18 on: April 01, 2010, 04:10:47 PM »

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.
Logged
bib
Global Moderator
Fractal Senior
******
Posts: 2070


At the borders...


100008697663777 @bib993
WWW
« Reply #19 on: April 01, 2010, 09:12:05 PM »

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

Between order and disorder reigns a delicious moment. (Paul ValÚry)
cKleinhuis
Administrator
Fractal Senior
*******
Posts: 7027


formerly known as 'Trifox'


WWW
« Reply #20 on: April 01, 2010, 10:31:03 PM »

i do hope you make it public soon subblue cheesy
Logged

---

divide and conquer - iterate and rule - chaos is No random!
subblue
Conqueror
*******
Posts: 116



WWW
« Reply #21 on: April 02, 2010, 10:34:59 PM »

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.

Quote from: Trifox
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.
Logged

www.subblue.com - a blog exploring mathematical and generative graphics
knighty
Fractal Iambus
***
Posts: 814


« Reply #22 on: April 04, 2010, 12:07:32 AM »

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   smiley

Let me suggest a variation of Buddhi's DE that seems to give better results. cheesy
(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)
« Last Edit: April 07, 2010, 11:18:50 PM by knighty » Logged
Timeroot
Fractal Fertilizer
*****
Posts: 362


The pwnge.


WWW
« Reply #23 on: April 04, 2010, 03:46:52 AM »

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.
Logged

Someday, man will understand primary theory; how every aspect of our universe has come about. Then we will describe all of physics, build a complete understanding of genetic engineering, catalog all planets, and find intelligent life. And then we'll just puzzle over fractals for eternity.
David Makin
Global Moderator
Fractal Senior
******
Posts: 2283



Makin' Magic Fractals
WWW
« Reply #24 on: April 04, 2010, 04:15:13 AM »


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).
Logged

The meaning and purpose of life is to give life purpose and meaning.

http://www.fractalgallery.co.uk/
"Makin' Magic Music" on Jango
knighty
Fractal Iambus
***
Posts: 814


« Reply #25 on: April 04, 2010, 09:52:17 PM »

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  cry.

Some renderings embarrass:
On cpu:


On GPU:
« Last Edit: April 04, 2010, 10:48:22 PM by knighty » Logged
Hamilton
Alien
***
Posts: 22


« Reply #26 on: May 12, 2010, 12:51:59 PM »

Ok, my turn to try out buddhi's DE tip...   wink
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...


* sample2010_05_11.jpg (251.53 KB, 800x600 - viewed 1264 times.)
Logged
KRAFTWERK
Global Moderator
Fractal Senior
******
Posts: 1427


Virtual Surreality


WWW
« Reply #27 on: May 12, 2010, 01:28:16 PM »

Very nice image mr Hamilton!
Logged

knighty
Fractal Iambus
***
Posts: 814


« Reply #28 on: May 12, 2010, 10:12:50 PM »

Wow! superbe!
Logged
Rrrola
Alien
***
Posts: 23


« Reply #29 on: September 10, 2010, 04:29:42 AM »

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
Logged
Pages: 1 [2] 3   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Mandelbox distance estimation problem 3D Fractal Generation « 1 2 » barkeg 23 6841 Last post August 27, 2011, 12:28:36 PM
by barkeg
Convert a Distance Estimate to a Mesh General Discussion eiffie 9 4313 Last post October 11, 2011, 05:22:34 PM
by eiffie
Need help with distance estimation formula for the Phoenix fractal Programming top-quark 6 338 Last post April 26, 2014, 12:00:41 AM
by top-quark
Using the Jacobian to estimate distance Programming TruthSerum 7 1353 Last post July 06, 2014, 02:39:12 AM
by David Makin
spotty interior distance estimate for Julia sets Mandelbrot & Julia Set claude 5 917 Last post February 21, 2015, 05:50:58 PM
by Adam Majewski

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.623 seconds with 28 queries. (Pretty URLs adds 0.018s, 2q)