Christian
Forums Freshman
Posts: 11
|
|
« on: December 28, 2013, 02:23:11 AM » |
|
Watch your fractal zooms in real time! Finally a new and faster way to generate fractals called “The Fractal Algorithm”. Get your free copy today at www.zevendevelopment.com. Run it as a screen saver and impress your friends and coworkers! No GPU required! It's FREE!
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #1 on: December 28, 2013, 05:57:29 PM » |
|
Cool! Can you please explain the "fractal algorithm" you invented? The demonstration doesn't go so deep, does it use arbitrary precision? Edit: I found the explanation on your site. It is indeed interesting and could indeed be combined with psa
|
|
« Last Edit: December 28, 2013, 06:35:50 PM by Kalles Fraktaler »
|
Logged
|
|
|
|
Christian
Forums Freshman
Posts: 11
|
|
« Reply #2 on: December 28, 2013, 09:23:34 PM » |
|
The Fractal Algorithm does not use arbitrary precision, just CPU doubles, no floats either at this time. I'm currently looking at double doubles that breaks the coefficients up which will give 30 digit precision or more if supported in real time. Use of Huygen lines will give any fractal calculations up to x1000 speed improvements even at e100. The Mandelbrot is a fractal why not use another fractal to calculate it? The Fractal Algorithm was the first attempt at a true real time zoom of a fractal that could run on any dual core i5 CPU. Enjoy!
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #3 on: December 28, 2013, 09:52:20 PM » |
|
You should combine it with psa, to be able to create almost unlimited deep mandelbrot fractals faster than ever before! But with the huygen lines you wont be able to do smooth color transitions unfortunately, so I wont try it.
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #4 on: December 28, 2013, 11:06:18 PM » |
|
Use of Huygen lines will give any fractal calculations up to x1000 speed improvements even at e100.
But I doubt your method would improve the calculation a thousand times at depth around e100. You should try it on this location, Dinkydau's Tick-tock, at the size 640x360 with no antialiasing: Re = -1.479,946,223,325,078,880,202,580,653,442,563,833,590,828,874,828,533,272,328,919,467,504,501,428,041,551,458,102,123,157,715,213,651,035,545,943,542,078,167,348,953,885,787,341,902,612,509,986,72 Im = 0.000,901,397,329,020,353,980,197,791,866,197,173,566,251,566,818,045,102,411,067,630,386,488,692,287,189,049,145,621,584,436,026,934,218,763,527,577,290,631,809,454,796,618,110,767,424,580,322,79
Magnification: 2^471 6.0971651373359223269171820894398 E141
Fractal extreme, the fastest program using the pixel by pixel full precision method, render this in 326 seconds. My program in 4.5 seconds. Will your program render this in 0.326 or 0.0045 seconds?
|
|
« Last Edit: December 28, 2013, 11:57:17 PM by Kalles Fraktaler »
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #5 on: December 28, 2013, 11:29:11 PM » |
|
I don't think this is new but rather a variant of bifricating, it looks (sounds) like something I applied to fractal rendering on my Amiga back in the late 80s, found the code in a demo. Divide area in half, render 1 pixel border, test border pixels, if all == then fill area else if all != subdivide again until size < 4. On my 16Mhz 68000 it made an enormous improvement. This basically plots escape boundaries and did offer a speed increase by not calculating the areas that were surrounded with the same color.
Have you figured out how to apply to 3D or DE ?
edit: I found that with very detailed plots it was just as fast to calculate everything due to the overhead generated by testing the borders of every 4 pixel group on the screen.
|
|
« Last Edit: December 28, 2013, 11:48:18 PM by 3dickulus, Reason: clarity? »
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #6 on: December 29, 2013, 12:02:53 AM » |
|
I haven't got original files with timestamps to prove this as over the years most of my Amiga stuff has been lost or resides on 880k Amiga floppies but here is the Qt ported version of the algorithm I used... /* -------------------------------------------------------------------- */ /* Determine whether a rectangular area is surrounded by all the same */ /* color. If this case is true no point inside the area will get a */ /* different color and thus there is no need to do any calculations for */ /* points inside. */ /* -------------------------------------------------------------------- */ /* */ /* Test() is something like... */ /* */ /* -------------------------------------------------------------------+ */ /* -----------------------------------+-------------------------------- */ /* ----------------+--------------------------------------------------- */ /* -------+------------------------------------------------------------ */ /* ---+---------------------------------------------------------------- */ /* -+------------------------------------------------------------------ */ /* +------------------------------------------------------------------- */ /* */ /* faster than testing every pixel, has same results */ /* */
int QtfPainter::Test() // int xr1,int yr1,int xr2,int yr2 { int ti; int x = (int)(xr2-xr1)>>1; // half the width
for (ti = xr2; ti >= xr1; ti-- ) { if ( tbuffer.pixel(ti, yr1) != coltmp) return 0; // left top if ( tbuffer.pixel(ti, yr2) != coltmp) return 0; // left bottom x >>= 1; ti -= x; // minus 1/2 last width }
int y = (int)(yr2-yr1)>>1; // half the height
for (ti = yr2; ti > yr1; ti--) { if ( tbuffer.pixel(xr1, ti) != coltmp) return 0; // right top if ( tbuffer.pixel(xr2, ti) != coltmp) return 0; // right bottom y >>= 1; ti -= y; // minus 1/2 last height }
return 1; }
/* -------------------------------------------------------------------- */ /* Recursive evaluation scheme briefly it does this: */ /* Called with the corners of an already calculated rectangular frame */ /* it tests for identity of the color of all points on that frame. */ /* If yes, fine! Just fill the points inside the area with this color */ /* and return without further work. */ /* If not, the area is halved and the function calls itself once for */ /* each half until the size of the area degenerates to zero or the */ /* first termination criterium jumps in. */ /* -------------------------------------------------------------------- */
void QtfPainter::FRecurse() // int xr1,int yr1,int xr2,int yr2 { double help1, help2; int xneu, yneu, tmp; int i; double dx = (remax - remin) / tbuffer.width(); double dy = (immax - immin) / tbuffer.height();
if (xr2 - xr1 > 1 && yr2 - yr1 > 1 ) { //&& ! STOPONBUT) coltmp = tbuffer.pixel(xr1,yr1); if ( Test() ) { // QImage has no fillRect() so fill it like so for now for( int y=yr2-1; y > yr1; y-- ) { for(int x=xr2-1; x > xr1; x-- ) { tbuffer.setPixel(x,y,coltmp); } } } else { if (xr2 - xr1 > yr2 - yr1) { xneu = (xr1 + xr2) >> 1; help1 = remin + xneu * dx; help2 = (yr1 + 1) * dy + immin; for (i = yr1 + 1; i < yr2; i++) { fracfunc (help1, help2); tbuffer.setPixel(xneu,i,colors[coltmp].rgb()); help2 += dy; } tmp=xr2; xr2 = xneu; FRecurse (); xr2=tmp; // xr1, yr1, xneu, yr2 tmp=xr1; xr1 = xneu; FRecurse (); xr1=tmp; // xneu, yr1, xr2, yr2 } else { yneu = (yr1 + yr2) >> 1; help1 = immin + yneu * dy; help2 = (xr1 + 1) * dx + remin; for (i = xr1 + 1; i < xr2; i++) { fracfunc (help2, help1); tbuffer.setPixel(i,yneu,colors[coltmp].rgb()); help2 += dx; } tmp=yr2; yr2 = yneu; FRecurse (); yr2=tmp; // xr1, yr1, xr2, yneu tmp=yr1; yr1 = yneu; FRecurse (); yr1=tmp; // xr1, yneu, xr2, yr2 } } }
return; }
edit: timestamp on this version is Oct 18 2006 qtfpainter.cpp
|
|
« Last Edit: December 29, 2013, 12:10:03 AM by 3dickulus, Reason: timestamp »
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #7 on: December 29, 2013, 12:26:47 AM » |
|
Yes, unfortunately this is not a new invention, and also Wikipedia mentions it with the name "Border tracing / edge checking".
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #8 on: December 29, 2013, 12:48:58 AM » |
|
...and here's the "fracfunc" used with the above Qt port for anyone that wants to play with it /*************************************************************************** qtfmandel.cpp - description ------------------- begin : Wed Sep 5 2001 copyright : (C) 2001 by Dick. email : ****@netscape.net ***************************************************************************/
/*************************************************************************** * * * This program is free software; you can redistribute it and/or modify * * it under the terms of the GNU General Public License as published by * * the Free Software Foundation; either version 2 of the License, or * * (at your option) any later version. * * * ***************************************************************************/
#include "qtfpainter.h"
void QtfPainter::mandelfunc( double r, double i){
uint count = 0; double p = r; double q = i; double a;
do { if ( p * p + q * q > divergence ) break; a = p; p += q; p *= (a - q); q *= (a + a); p += r; q += i; } while (count++ < maxiter );
coltmp = (count >= maxiter) ? 0 : ( count % maxcol + 2 );
return; }
|
|
|
Logged
|
|
|
|
Christian
Forums Freshman
Posts: 11
|
|
« Reply #9 on: December 29, 2013, 01:15:53 AM » |
|
I am familiar with bifricating. Bifricating suffers from errors if the fractal image is disconnected. Take a look at the Julia Set "Ornament" and zoom into the areas were all the lines connect. You will find isolated pixels. Bifrication will incorrectly remove these.
Huygen lines can be applied to 3D and even DE as a root finding algorithm in concept, but I have not pursued these areas.
The Fractal Algorithm incorporates many techniques in order to deliver 30 fps fractal zooms in real time, and it's primary focus was to run on an average dual core i5 CPU.
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #10 on: December 29, 2013, 01:27:05 AM » |
|
when bifricating reaches 2x2 all pixels are calculated but it will miss something that happens to be surrounded by the same values and happens to lie off of a bifrication boundary.
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #11 on: December 29, 2013, 09:11:15 AM » |
|
I am not trying to beat you up or put down your work, I am just trying to understand what is new, different or better than previous methods... this is a quote from http://farside.ph.utexas.edu/teaching/302l/lectures/node150.html RE: Huygens' principle The first person to explain how wave theory can also account for the laws of geometric optics was Christiaan Huygens in 1670. At the time, of course, nobody took the slightest notice of him. His work was later rediscovered after the eventual triumph of wave theory.
Huygens had a very important insight into the nature of wave propagation which is nowadays called Huygens' principle. When applied to the propagation of light waves, this principle states that:
Every point on a wave-front may be considered a source of secondary spherical wavelets which spread out in the forward direction at the speed of light. The new wave-front is the tangential surface to all of these secondary wavelets.
According to Huygens' principle, a plane light wave propagates though free space at the speed of light, c. The light rays associated with this wave-front propagate in straight-lines, as shown in Fig. 85. It is also fairly straightforward to account for the laws of reflection and refraction using Huygens' principle.
Fig. 85 END QUOTE from the diagrams on your website it appears to be bifricating/boundary testing so I quote Kalles Fraktaler ... Can you please explain the "fractal algorithm" you invented? and how it uses "Huygen Lines" which I understand as the line representing the new wave front formed by secondary wavelets. If my assumptions here are incorrect then I welcome enlightenment.
|
|
|
Logged
|
|
|
|
Syntopia
|
|
« Reply #12 on: December 29, 2013, 11:23:17 AM » |
|
I think the OP is named 'Huygen', so there is probably no relation to the physicist Huygens :-)
@Christian: Can't you explain what these Huygen lines are? Then it would be easier to see whether this is something new. There are already fast Mandelbrot zoomers out there - for instance 'Frax' for iOS which lets you zoom in realtime on an iPad.
You program is certainly fast in the 'preview' mode. I get 30 fps, but this seems to be based on some sort of interpolation/rescaling between keyframes, which introduces visual artifacts (see e.g. the pixelation on the attached screenshot). When I go to edit mode and zoom interactively, the render time is higher (1-30 seconds for zooming in on complex locations). For proper time comparisons, it would be necessary with an option to calculate a single frame at the specified location - I don't think this is possible as of now?
Btw, the program crashes when exiting 8-bit colors mode on my machine (Windows 7). 32-bit works fine.
|
|
|
|
3dickulus
|
|
« Reply #13 on: December 29, 2013, 12:07:27 PM » |
|
ah, of course, thank you Syntopia, and "The Fractal Algorithm" is actually the name of a mandelbrot rendering program being marketed as product of zevendevelopment and not a new method based on bifurcating wavelets, my apologies to Christian for the bold assumption. "Christiaan Huygens" != "Christian Huygen" One can understand some confusion with statements like... "The Fractal Algorithm only needs to calculate 7.4% of the total resolution." from the website. not a good name for a program and Christian? attaching your name to bifurcating lines is a little bold me thinks, however, if you did invent the idea I will, from this day forth, always refer to these lines as "Huygen Lines"
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #14 on: December 29, 2013, 02:57:13 PM » |
|
Ok, so I fired up the IDE and dug into my old code, a bit hacked up and not a complete port to the latest and greatest but enough to let me render something. The images were created from the code posted above, original code circa 1988 ish and it's quite fast, haven't had any time to run real tests, requires proper porting. As I recall I spent some time observing the assembler output, I found that the compiler optimized better than I could. The C code for the "fracfunc" produced assembler that was about as good as it could be at the time and that is what led me to bifurcating for an order of magnitude speed increase. Mandel, Julia, hybrid MandJulia The old proggie had 28 fractal types collected from Scientific American magazines and other publications, maybe I'll revive it
|
|
« Last Edit: December 29, 2013, 04:56:58 PM by 3dickulus, Reason: pics »
|
Logged
|
|
|
|
|